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
___
fpc-devel maillist - fpc-devel@
Michael Schnell wrote:
> Important additional Question:
Martin:
Any comment on this ?
Thanks,
-Michael
___
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
Martin Schreiber wrote:
> 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 tev
On Thursday 15 October 2009 13:58:53 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
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
___
fpc-devel maillist - [email protected]
http://lists
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
___
fpc-de
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.
___
fpc-devel maillist - [email protected]
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)
>
> I never worked with signals up to now.
>
> Martin once told me that the MSEG
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 qu
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 withou
In our previous episode, Michael Schnell said:
> 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-synchron
Marco van de Voort wrote:
> 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.
>
Of course this is true for the original Delphi "procedur
On Thu, 15 Oct 2009, Michael Schnell wrote:
Michael Van Canneyt wrote:
It exists and is implemented in custapp since years for exactly this
reason.
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 ?
In our previous episode, Michael Schnell said:
> 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
Michael Van Canneyt wrote:
>
>
> It exists and is implemented in custapp since years for exactly this
> reason.
>
>
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
On Wed, 14 Oct 2009, Michael Schnell wrote:
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
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
On Tuesday 13 October 2009 13:54:59 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 impo
On Tue, 2009-10-13 at 13:38 +0200, Martin Schreiber wrote:
> On Monday 12 October 2009 17:09:42 Joost van der Sluis wrote:
>
> > > MSEide has its own implementation of
> > > tcustomapplication/tapplication/tguiapplication with a similar approach.
> >
> > Yes, offcourse. But the idea is to unify th
On Monday 12 October 2009 17:09:42 Joost van der Sluis wrote:
> > MSEide has its own implementation of
> > tcustomapplication/tapplication/tguiapplication with a similar approach.
>
> Yes, offcourse. But the idea is to unify this. So that you can access
> the CustomApplication without knowing if y
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) it
On Fri, 2009-10-09 at 11:42 +0200, Martin Schreiber wrote:
> On Thursday 08 October 2009 17:36:44 Joost van der Sluis wrote:
> >
> > 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 f
On Friday 09 October 2009 12:33:51 Michael Schnell wrote:
> 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
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 cre
On Thursday 08 October 2009 17:36:44 Joost van der Sluis wrote:
>
> 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.
>
MSEide has its own implementation of
tcustomapplication
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.
27 matches
Mail list logo
