Hi all,

I want to add (abstract) logging functionality to TCustomApplication. I see three options:

One:
Add a public TEventLog property to TCustomApplication. Then deratives of TCustumApplication can return a TEventLog or a derivate of it. I can leave the TEventLog property nil for TCustomApplication, or let it return an instance TEventLog. That way you can adda log-message as follows:

Application.Eventlog.Log(EtInfo);

Two:
Add an abstract (or maybe better, an empty) procedure to TCustomApplication, procedure Log(AType: TEventType; Message: string); virtual; (abstract);
I can leave out the AType parameter, but I think it's useful for all cases. Classes derived from TCustomApplication can implement their own handling.

Three:
Same as two, but also add a real implementation using TEventLog. So that by default everything is logged to the system log, or when the user wants to to a file.

I think option two is the best one. Then I can use the TEventLog for daemon and web applications. But I'm really interested in the opinion of the Lazarus and MseIDE people. Although I think that MseIDE doesn't use the TCustomApplication?

Joost.

Don't add the eventlog unit to customapplication, because eventlog has a dependency on the C library, and custapp does not need that.

But it would be good if the 2 implementations use the same TEventType type for easy re-routing, so that would need to be moved 'up' somewhere.

Michael.

Joost van der Sluis wrote

I think option two is the best one. Then I can use the TEventLog for daemon and web applications. But I'm really interested in the opinion of the Lazarus and MseIDE people.

What is the advantage to integrate log facility into tcustomapplication instead to have log procedures and a log manager as a singleton in a separate unit?
I think there should be as less as possible dependencies in tcustomapplication, so probably option two is the best.

Although I think that MseIDE doesn't use the TCustomApplication?

Correct, Michael Schnell is currently porting MSEgui tnoguiapplication to Lazarus.

Martin

Martin Schreiber wrote

Correct, Michael Schnell is currently porting MSEgui tnoguiapplication to Lazarus.

The Lazarus port implements tnoguiapplication as class of tmseapplication and tmseapplication in this implementation is a class of TCustomApplication from the FPC RTL.

-Michael

P.S::
The mseaplication class (as well the mseide application version as my port) implements "postevent()" and thus might be seen as a provider for an event log. But TCustomApplication does not seem to be able to log events, as it does not seem see them.

-Michael

Good question.

I had to think about it again why I wanted this. And it is because I want to have a 'global' logging system available. But the application has to implement it.

ie: I want to be able to log something in some fcl-units, without knowing what kind of application there's running.
So that all applications can implement their own logging-system.

But that's also possible with a new global instance of some class which can be overridden (and set) by applications. But that's a lot of work, so I think adding it to the TCustomApplication is a good idea. (?)

Joost.

I second that. It's just a hook, after all.

Michael.

Joost van der Sluis wrote

And it is because I want to have a 'global' logging system available. But the application has to implement it.

Of course the logging functions would need to be thread-safe !

IMHO it would be nice if TCustomapplication would have a hook for the event-queue, so that different event queue implementations (like TApplication <using the GUI system's event queue> and the (upcoming) TNoGUIApplication <implementing an event queue in FPC code> ) can be done as a plugin.

In combination with the said logging functions, optionally enabling a global log of the queue events and exception events would be really nice to have !

-Michael

I don't see a point in an event queue, since TCustomApplication is also meant for non-event-driven (or queueing) applications; What's more event queues can take wildly different forms in terms of implementation, so it's hard to create a catch-all hook for that.

Michael.

Michael Schnell wrote

Of course the logging functions would need to be thread-safe !

This is another issue I wanted to raise about TEventLog.

* Is it thread safe? At first glance I can't see that it is.
* When loging to file, no cached loging is used, so this will seriously slow down your application. If you debug something like the Visitor pattern, you generate a huge about of log entries.

tiOPF solves both of these, so we could steal ideas from there and implement it inside TEventLog.

Regards,
- Graeme -

It's only not safe when writing to a file.

* When loging to file, no cached loging is used, so this will seriously slow down your application. If you debug something like the Visitor pattern, you generate a huge about of log entries.

This can be remedied easily.

Michael.

Michael Van Canneyt wrote

I don't see a point in an event queue, since TCustomApplication is also meant for non-event-driven (or queueing) applications;

Of course. I only vote for a hook. If it is not used it's just a non-event-driven application (command line tool or nonpersistent CGI).

What's more event queues can take wildly different forms in terms of implementation, so it's hard to create a catch-all hook for that.

I do see this, and this is exactly why I think such a hook would be great (even if not that easily done). Having a standard type (class) for all events (similar to the exception type), would allow for a much more standardized management of the events. According to the topic of this thread a central logging of the events for debugging would be enabled, For the future I dream of enabling event-driven (queuing) threads, that each instantiate it's own event queue using an extension of the "nogiu" paradigm, I am working on, withing a GUI or NoGUI application. Imagine an extension of this to inter-thread-event firing, allowing for "parallel" loops....

-Michael

Graeme Geldenhuys wrote

This is another issue I wanted to raise about TEventLog.

Is the name TEventLog set ?

IMHO this is not a good name, as TEvent is a class already provided (at least in Delphi/Lazarus) and moreover an "Event" in ObjectPascal already has a dual meaning (a classical Callback from an object and a synchronized "interrupt" generated by an asynchronous trigger (such as timer or mouse click), managed by an "EventQueue".

So please don't introduce a forth meaning of "Event".

-Michael

Yes.

The name stems from the Windows 'Event Viewer' system logging facility. The class exists since 8 years, so we're not going to change that.

Michael.

Despite the name TEventLog, it has nothing to do with events. It's a logging facility. I agree that the name is confusing, but it has historical roots.

Michael.

Michael Van Canneyt wrote

I agree that the name is confusing, but it has historical roots.

Thus I vote for changing it.

-Michael

Michael Schnell wrote

On 02/17/2010 09:57 AM, Michael Van Canneyt wrote: > I agree that the name is confusing, but it has historical roots. Thus I vote for changing it.

Fork the fpc packages directory. Then you can make your vote count.

Vincent

Michael Van Canneyt wrote

The class exists since 8 years, so we're not going to change that.

I understand :(

-Michael