[Lazarus] Share a port through lazarus-ccr

[Luiz Americo Pereira Camara]

Graeme Geldenhuys escreveu:
> On Mon, Mar 30, 2009 at 6:43 PM, Luiz Americo Pereira Camara
>   
>> It also provides several helper methods to control with fine granularity
>> what messages to send. Some of then can be seen at
>>     
>
> That's what we do in tiOPF as well. We have various 'log severities'
> defined. At compile time or runtime (via Visual Logger window) you can
> change log severities to see more or less information come through.
>   

In Multilog, additionally to the log severity that's another variable: 
the classes. The class is user defined up to 32 (in fact each class is 
defined by a byte value). Each message is attached to one or more 
classes. You can control what will send by ActiveClasses and DefaultClasses.

Say you have two messages.

Logger.Send('XXX');
Logger.Send([1], 'YYY');

If you set ActiveClasses to [1,2] and DefaultClasses to [0] only 'YYY' 
is sent
If you set ActiveClasses to [1,2] and DefaultClasses to [1] 'XXX' and 
'YYY' is sent
If you set ActiveClasses to [0,2] and DefaultClasses to [0] only 'XXX' 
is sent

This is useful in events where you want to avoid messages triggered by 
system events.
As an example, you want to know what happens to in paint routines when 
you do some action in a control.
Set the log messages with a 'paint' class inside that routines.
Around the action routine do

ActiveClasses := [paint]
do some action
ActiveClasses := []

You can also play with the DefaultClasses.
This will prevent to log when the paint routine is called by the system 
(focus change etc)


I  have planned to add another layer to filter that will allow to filter 
by thread, by type of message and also buffer in memory before sending 
to the channel.

>> As example, it's possible to restrict to send only the messages that are
>> called below a method/function call stack.
>>     
>
> Can you explain this a bit more... Including the call stack.
> Currently my major obsticle in event programming is debugging the call
> stack. I often do the following as a quick fix...
>
>   

When EnterMethod/ExitMethod is used, multilog keeps a track of the 
callstack. You can use CalledBy method to know if you are inside that 
stack. Also the text file and the messages tree are built using that 
info, so you can see the stack structure.

Also there's SendCallStack method that shows the fpc provided callstack. 
MaxStackCount controls the size of the stack

There's room to improvements: automatically detect if you are inside a 
method in the stack without the need to call Enter/ExitMethod, hook 
Lazarus IDE/GDB to automatically insert the log calls without need to 
change the source file.
> procedure TMyform.SomeCall;
> begin
>   Log('>> TMyForm.SomeCall');
>   { some code here}
>   Log('<< TMyForm.SomeCall');
> end;
>
> I have improved on this slightly by using Interfaces. Create a
> interface variable that on creations writes the ">> ...' line and when
> the variable goes out of scope and gets destroyed, writes the '<< ...'
> line automatically.
>
> eg:
> procedure TMyform.SomeCall;
> var
>   logger: ILogger;
> begin
>   logger := gLog.GetLogger('TMyForm.SomeCall');
>   { some code here}
> end;
>
> But as you can see, it's not much of an improvement, because I now
> need a local variable. :-(
>
> A constant view of the callstack (say the last 20 calls) would be
> pretty awesome. Anybody know if this is possible with GDB or MultiLog
> etc?
>
>   

See above.

Luiz