Hi all,

In fpc 2.5.1 I've introduced the global CustomApplication variable in the custapp unit. The idea is that when this variable is set when a application-object is initialized, this variable is set so that you can access the CustomApplication-object without knowing in which unit it is defined.

We've discussed this before.

I want to know if the current implementation is usefull for the existing application-frameworks like Lazarus and MSEIde. If that's so I'll maybe merge it to fpc 2.3.1.

Joost.

MSEide has its own implementation of
tcustomapplication/tapplication/tguiapplication with a similar approach.

Martin

IIRC, the TApplication instance needs to take care of the message queue that schedules events for TTimer the Delphi "procedure ... message" construct etc.

With GUI application the message queue is managed by means of the appropriate GUI Framework, such as the Windows or GTK API-

MSE provides creating a "nogui" application that handles the message queue without complex external stuff but in Linux uses "sem_wait()" to wait in case of an empty message queue and signals for posing events. (I don't know how they do this in Windows).

I feel that this would be a very appropriate extension to the native FPC RTL, so that IDE frameworks can standardize on this.

-Michael

MSEgui sem_wait() is platform independent. Because on Windows terminate and timer events must be caught also, msgwaitformultipleobjects() will be used.

Martin

Yes, offcourse. But the idea is to unify this. So that you can access the CustomApplication without knowing if you are using Lazarus or MDEide. So can you set the global CustomApplication variable in MSEIde, so it's also accessible for other units?

Joost

Joost van der Sluis wrote

YBut the idea is to unify this.

This is what I meant, too.

I feel that MSEIDE/MSEGUI is quite advanced regarding the (flexibility of) the TApplication implementation, and thus, who wants to modify/enhance the implementation of the "Application" thingy in FPC (RTL) itself, should take a look at MSEIDE/MSEGUI and ask Martin tor some suggestions.

-Michael

MSEgui has functions which return a singleton of the application instance. msegui.application function returns a tguiapplication, msenogui.application function a tnoguiapplication, both inherit from MSEgui tcustomapplication which is independent from FPC TCustomApplication, MSEgui application object implementation is incompatible to FPC I fear.

Martin

Ok, that's clear. In that case this global variable is useless for MSEgui.

But why don't you use fpc's TCustomApplication? Can we improve it so that you could use it?

Joost

Joost van der Sluis wrote

But why don't you use fpc's TCustomApplication? Can we improve it so that you could use it?

I need functionality from tmsecomponent which is difficult to achieve if I would inherit from FPC TCustomApplication, although not impossible. Another Problem is Delphi compatibility, I'll have a look.

Thanks, Martin

Martin Schreiber wrote

I'll have a look.

Great !

I'd appreciate having a common TApplication paradigm with FPC from which both MSEGUI and Lazarus (and whatever) can inherit from and that supports all GUI frameworks and non-GUI stuff and remote WEB-interface.

-Michael

It exists and is implemented in custapp since years for exactly this reason.

Michael.

Fine,
But then the OP's should already have what he needs needs ...

Do in fact Lazarus and MSEGUI use this in the way it is intended ?

A request now might be that the FPC RTL offers a non-gui implementation of a message queue that works directly on the system API of the supported OSes to allow for events like those that are thrown by things like TTimer and TThread.synchronize or to be captured by a construct like "procedure ... message". Here MSEGUI on Linux implements something based on Signals. (On Windows it supposedly is based on Windows Messages.)

I feel that something like would be worth being provided in the more "general" FPC distribution.

-Michael

In our previous episode, Michael Schnell said:

That's an attempt on emulating something that is not really portable.

There are a handful of signal and thousands of possible windows messages. Moreover, windows messages contain state about the owner.

Lazarus certainly does.

Feel free to contibute a descendent of TCustomApplication that adds a message queue. Personally, I don't see the need, but I can imagine that someone does.

I say a descendent of TCustomApplication because I don't think it belongs in TCustomApplication itself, because not all applications need a message queue.

Michael.

Of course this is true for the original Delphi "procedure ... message", which would need to be replaced by some portable (inter-thread) messaging mechanism. IIRC, this is already available on Lazarus and/or MSEGUI,

But for TThread-synchronize and TTimer the implementation dependent details are hidden in the appropriate TApplication code, anyway, so no portability problem here.

-Michael

In our previous episode, Michael Schnell said:

Well, the point is if it really is compatible. And the other consideration is that such system should eat resources that are scarce (like SIGUSR and SIGUSR2)

Michael Van Canneyt wrote

Feel free to contibute a descendent of TCustomApplication that adds a message queue.

I don't suppose this can decently and portable and tested for all available archs and OSes be done in just a few hours :)

It (a non-gui depending TApplication that works without any GUI binding) seems to be available with MSEGUI. So it would be viable to ask Martin to provide it.

Personally, I don't see the need, but I can imagine that someone does.

I definitely will use it some day. I am already planing this (embedded) project since long.

I would use the MSE1-GUI sources if I start the project, but it I just can use the RTL for that purpose, some complexity would be avoided.

I say a descendent of TCustomApplication because I don't think it belongs in TCustomApplication itself, because not all applications need a message queue.

I of course do agree. I don't remember if MSEGUI does it this way, but I feel it would be the most straight forward implementation method.

-Michael

Marco van de Voort wrote

Well, the point is if it really is compatible. And the other consideration is that such system should eat resources that are scarce (like SIGUSR and SIGUSR2)

I never worked with signals up to now.

Martin once told me that the MSEGUI implementation of the message queue does use signals. Maybe there are other primitives in Linux that are not that scarce Do you think, (e.g.) System V message queues would be more appropriate ?

-Michael

In our previous episode, Michael Schnell said:

Afaik, at the time when I was researching this (mass async messagehandling), this was discounted because FreeBSD didn't support them (*)

I then gave up emulating the windows messaging concept because while you might be able to emulate a few cases, you could not reliably implement it crossplatform (cross-unix actually).

(*) it did support them, but it was turned off in default kernels, and the
status was not exactly known, so for all practical purposes they weren't.

But maybe you could do some research on the subject.

In our previous episode, Marco van de Voort said:

(sysv queues)

But maybe you could do some research on the subject.

it is marked as experimental in 7.0. So maybe in a few years one could use this.

Marco van de Voort wrote

I then gave up emulating the windows messaging concept

In fact what I am thinking of is emulating the GTK messaging concept that is used by TApplication when hooking into that (ore some other) GUI system.

-Michael

Marco van de Voort wrote

But maybe you could do some research on the subject.

I am planning to try the MSEGUI implementation. AFAIK, Martin claims that it does work well.

-Michael

Michael Schnell wrote

Martin once told me that the MSEGUI implementation of the message queue does use signals.

???
The MSEgui *timer* system on Linux works with SIGALRM. The eventqueue is implemented on all platforms, with and without GUI as an internal teventlist which holds instance pointers of tevent class. The X and win32 events are packed into a appropriate tevent descendent and feed into the queue. It is possible to loop tevent's to X or win32 event queue if the receiving order must be synchronized with system events.

Martin

GREAT !

This seems to be platform and GUI system independent and thus is exactly how I think it should be done.

I feel it would be a very desirable enhancement to the FPC RTL if this would be moved there and any GUI-based "TApplication"(such as coming with MSEGUI and Lazarus) and any non-GUI-based "TApplication" (such es "embedded" stuff and remote GUIs such as HTTP based "Bowser-GUI" implementations) would be built on top of this.

-Michael

Martin Schrieffer wrote

The eventqueue is implemented on all platforms, with and without GUI as an internal teventlist which holds instance pointers of tevent class.

Important additional Question:

How is a work alike to Delphi's "procedure .... message" construct done, which can be used to signal a state change from a thread towards the main thread ?

( Very low pitched additional question:
Does this mechanism allow for installing multiple such event queues in order to allow for some thread to each have its own event queue ? (A dream of mine since years :) )
)

Michael Schnell wrote

Important additional Question:

Martin:

Any comment on this ?

Thanks,
-Michael

Martin,

Any additional comment on Michael Van Canneyt's suggestion

"Feel free to contribute a descendant of TCustomApplication that adds a message queue."

which I tried to gently pass over toward you ? :)

-Michael