When i use the logger with vc++ 2005.i got an unkown software excpetion.
while compiling i get only these warnings
..\ready_for_use\LoggerWrapper.cpp(31) : warning C4996: '_vsnprintf' was declared deprecated
C:\Program Files\Microsoft Visual Studio 8\VC\include\stdio.h(339) : see declaration of '_vsnprintf'
Message: 'This function or variable may be unsafe. Consider using _vsnprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
..\ready_for_use\LoggerWrapper.cpp(64) : warning C4244: 'argument' : conversion from 'time_t' to 'long', possible loss of data
I've been able to resolve some of the compiler and linker errors. However im bumping against the following issue which i could't figure out.
.\LoggerAddIn.odl(19) : warning MIDL2015 : failed to load tlb in importlib: : devshl.dll
.\LoggerAddIn.odl(20) : warning MIDL2015 : failed to load tlb in importlib: : ide\devdbg.pkg
.\LoggerAddIn.odl(54) : error MIDL2337 : unsatisfied forward declaration : IApplicationEvents [ Coclass 'ApplicationEvents' ]
I've been searching on the internet. The only thing i found is that the difference between 2003 and 2005 is the absence of these files in 2005(devshl.dll). I couldn't find any solution for this problem . Maybe u can help?
This logging system was made before knowing anything about 2003 and 2005 IDEs. So I didn't made any testing on them. Now, I'm so sorry to admit it, it's a little bit obsolete. I'll dig into the problem and solve it for you if you really need it, but I think log4xxx system it's much more stable, tested, and offers much more features than this system. the xxx part is replaceble by J,c++,net,etc. So you have now log4J (the logger I've tried to mimic with this system), log4C++, log4net (VB# and c#). log4xxx was available only for java when I've developed this system for c++ developers.
Here is the home page of log4xxxx. I'm sure you will choose it!!!
They also have great examples of using it and tons of documentation. Plus a few forums....
So, bottom line.... if you have some work based on it, I'll will make it work for you 100%. If you want to begin a new project and need a logging system, I strongly recomand you log4xxx. (they now have support for php.... looooool ) )
When calling a function in a static library or DLL that takes a wchar_t type (note that BSTR and LPWSTR resolve to wchar_t*), you may get an LNK2001 unresolved external symbol error.
This error is caused by the /Zc:wchar_t compiler option, which is set to on by default in new MFC projects. This option causes the compiler to treat wchar_t as a native type. Before Visual C++ .NET, wchar_t was treated as an unsigned short.
If the main project and library do not use the same setting for /Zc:wchar_t, this will cause a mismatch of function signatures. To avoid this problem, rebuild the library with the /Zc:wchar_t compiler option, or turn it off in the main project using the Treat wchar_t as Built-in Type setting on the Language property page in the Property Pages dialog box.
I don't have a lot of experience with out of proc COM servers - are you doing anything to prevent the server from shutting down if there are still handlers in the handlers array?
I'm thinking that one client could create a handler (say a file log) and others could use it, but that only works if the server is prevented from shutting down when the handler array has entries in it. If you are preventing shutdown, can you point me to the code that does this? If not, do you think it would be easy to add code that prevents the server from going away if the handlers array is not empty?
Tha logger was designed to shutdown automatically after the last client application exited. In fact I didn't add any code for doing this. This is the normal behaviour of a COM object: delete itself from the memory if nobody is using it. But if you want to keep the logger running you can start it manually before the application. This way it will run after the application exited.
Adding code to tell the logger to keep running if it was spawned from an application it is a interesting feature. Where to add this code? I realy don't know but I will investigate as soon as possible.
First let me say THANKS for this amazing logger, it makes life so much easier!
Now a question regarding the logger manager. I use VS6 and I write a code with MFC (Dialog based application that runs a C++ code for testing Genetic algorithms ... something for school).
Anyway: after the application exits, the Manager is still up and cannot be turned off or closed unless I do it violently from the task manager.
I know that COM should unregister and die when it is not use... so why oh why is it still on?
i use windows XP home addition SP 3
And I intend to make even more simpler! In the near future, I want to make the logger much more robust and cleaner.
Major changes will be:
--SPEEEEEEEEEEEEEEEEEEEEEEEEEEED!!! (will use pipes and direct disk serialization)
--The new logger will be designed from functionality towards user interface. This version, unfortunately, is designed starting from user interface and than functionality. I was too eager to see it working.
--Not a single log message will be lost! (have some great ideas about speed up things with some binary trees and direct disk serialization - (some *.vxd programming). You will see... ). You will be able to create a special partition on HDD where the log messages will be stored in case you have a large amount of data that needs to be logged. Of course, this is NOT a MUST. You will be able to serialize the data into plain files based on the current file system.
I am currently playing around with the logger and i really like it.
But I have one problem. When I use the defines e.g. SEVERE_LOG many times (5 times or more) in one function I get a crash when this function is called.
Here is the error that is shown:
First-chance exception in Project.exe: 0xC00000FD: Stack Overflow.
If I dont use the defines everthing is fine. Looks like a compiler error for me is there qany way to avoid this problem?
For every message you try to log an instance of CFormatedString class is created. Along with it, 65536 bytes of memory are allocated on the stack of your current thread. THIS IS A BUG!!! I will currect it in the new version. It will be much more stable and faster (3000-4000 messages/second on a 350MHz Intel).
But if you are in a hurry you can use one of the following solutions:
1. Try to lower the MAX_MESSAGELENGTH define(ex: 32768)
2. Dynamically allocate the m_buffer (using new in the constructor and delete in the destructor of the class)
I had to change the loggerwrapper's "CoInitializeEx(NULL, COINIT_MULTITHREADED);" to "CoInitialize(NULL);" to avoid conflicts with my CDaoRecordSet (which uses CoInitialize(NULL). I am using Visual C++ 6.0 and Microsoft Access Access 97.
I'm wondering how (or when) the loggerNameCol in the Database is used. It hasn't been filled in for me.;P