Overriding CodeSiteManager.Enabled

Post questions here regarding the CodeSite Express edition

Overriding CodeSiteManager.Enabled

Postby JonRobertson » Wed Mar 27, 2013 1:43 pm

I completely understand the benefit of CodeSiteManager.Enabled and I am thrilled that it does what it does. That said, this next request may be confusing:

Is there a way for an instance of TCodeSiteLogger to send a message even when CodeSiteManager.Enabled = False?

I have a service that I'm adding extensive CodeSite logging. This logging can be turned on or off dynamically while the service is running. Logging will be off most of the time and only turned on when troubleshooting an issue.

The service also writes all unhandled exceptions to the event viewer (using my code, not TService or CodeSite). But I don't want to write the entire stack trace to the event log.

I'd like to have a TCodeSiteLogger instance that is used exclusively to write exceptions via CodeSiteEx.TcsxErrorTrapControl. All exceptions would be written to a single CodeSite log file.

General purpose logging would go to a file that is named based on the time the logging started, and this log would include all TCodeSiteLogger instances, and would also include the exceptions inline with the other log messages.

This approach would still capture critical stack traces for exceptions even when general logging is disabled.

As far as I can tell, this prevents me from using CodeSiteManager.Enabled to turn on/off the logging. If I could "instruct" a single TCodeSiteLogging instance to log anyway (ignore CodeSiteManager), that would be great.

I'm considering this workaround, although I'm not happy with it because it will probably allow other logging to occur from other threads, as there could be hundreds of threads executing when the exception occurs:
Code: Select all
  bWasEnabled := CodeSiteManager.Enabled;
  try
    if not bWasEnabled then
      CodeSiteManager.Enabled := True;

    CS.SendError(lsErrStrings.Text);

  finally
    if not bWasEnabled then
      CodeSiteManager.Enabled := False;
  end;
JonRobertson
 
Posts: 28
Joined:
Thu Sep 15, 2011 12:08 am

Re: Overriding CodeSiteManager.Enabled

Postby JonRobertson » Wed Mar 27, 2013 2:26 pm

After writing all that out, it occurred to me this could probably be solved using the OnSendMsg event in Studio. I could simply set Handled based on the "logging on or off" flag and leave CodeSiteManager.Enabled always True. The CodeSite instance I use for exception logging wouldn't have an OnSendMsg implemented and would always send the message.

I've got a small list of reasons we should upgrade to Studio. This is just one more for that list.

How much overhead would it add to have a CodeSiteManager.OnSendMsg, perhaps with an additional parameter of TCodeSiteLogger providing a reference to the "owning" instance? If TCodeSiteLogger.OnSendMsg was not implemented or did not set Handled := True, then CodeSiteManager.OnSendMsg would be called. That would allow implementing a single message handler for all messages, rather than a separate one for each logger instance. (I guess the order of which one is called first could be debated. It would not matter in my scenario because I wouldn't implement the event on the logger.)
JonRobertson
 
Posts: 28
Joined:
Thu Sep 15, 2011 12:08 am

Re: Overriding CodeSiteManager.Enabled

Postby Raize Support » Wed Mar 27, 2013 11:28 pm

Hi Jon,

First of all, I would not recommend toggling the CodeSiteManager.Enabled property as you suggested in your original message. That would indeed have the potential to affect other threads.

Going back to your original issues, you would probably have better luck managing the enabled states of the loggers separately rather than using the "global" CodeSiteManager.Enabled property. This gives you the most flexibility, but there is a certain amount of complexity with it.

In regards to adding a CodeSiteManager.OnSendMsg event handler, I'm not convinced that this would actually provide any real value. Sure it would allow you to right one event handler, but you could write one event handler and just have all your logger instances point to it. However, the biggest problem with the CodeSiteManager.OnSendMsg approach is all the extra synchronization code that would need to be added to the send process. This would impact performance.

I still think managing the individual loggers enabled states as needed would be the best approach.

Ray
Raize Software Support
Raize Software
http://www.raize.com
Raize Support
 
Posts: 622
Joined:
Fri Mar 25, 2011 9:04 pm


Return to Express Edition

Who is online

Users browsing this forum: No registered users and 2 guests

cron