Core - Provide an option to override the Tracing class behavior

Hello DX,
Thank you for making this change, it works beautifully and now we can use the advanced features of our logging system!
I have a few minor changes requests for the Tracing class:
#1 Could you make the GetDateTimeStamp method virtual? I know there’s an event, but since now we can create our derived type, it makes sense to have it ‘self-contained’.
#2 Could you make sectionDelim and subSectionDelim public so we can ‘Remove’ them from logged text entries?
#3 Could you make the GetSeparator method virtual? Again this is to help control the output to the logging system.
Again thanks for the quick addition of the CreateCustomTracer event!
Alex

Last one I promise!

#4 Please make ValueToString(object value) public.

This makes sense because the objectValue is often structured to be formatted by that method. I copied it for now, but I would prefer to reuse your code.

Thanks!

Alex

Hello Alexandre,

Thanks a lot for your feedback.
We will do our best to investigate your requests as soon as possible. But, I cannot promise any exact time frame for the implementation now. Please add this thread to your Favorites to be automatically notified of our progress.

We have made the following changes with the Tracing class:
- the GetDateTimeStamp method is now virtual;
- the SectionDelim and SubSectionDelim fields are protected now;
- the GetSeparator method is now virtual;
- the ValueToString(object value) method is public now.

Again you are the best! Thanks for the quick implementation.

You are always welcome!

Hello DX,

I'm testing the new 16.1 beta and I'm really happy with the new features so far! The changed you made above are working perfectly. Again thanks a lot.

It seems I forgot one other little change to the Tracing class. If you could make the LogSeparator(string comment) method virtual, it would be really useful. This method adds a new line and a 'line' of = characters that changes depending on the comment length.

Thanks,

Alex

Hello Alexandre,

I have reviewed the LogSeparator method.
In our opinion, it should not be marked as virtual. Instead, the separator string building should be moved from this method to some virtual method.
Please review the LogSubSeparator method structure. If I understand your intention correctly, the LogSeparator method should have the same structure as the LogSubSeparator method. If so, we will place the separator string building into a virtual method (similar to GetSeparator used within LogSubSeparator).

Hi Aleks,

I totally agree that the separator string building should be in a separate virtual method like the other ones. This would definitely be the best option and produce the most consistent API.

I honestly did not ask for the better option, because I figured I was becoming a little annoying with all the change requests on this class. So I asked for the easiest possible change.

Thanks!

Alex