Re: [Lazarus] Active NoGui LCL Widget Type
On 07/10/2014 09:58 PM, Sven Barth wrote: You should not need to use the thread manager. All functions (except the semaphore ones which are only implemented for cthreads) should be available by RTL functions. So don't use GetThreadManager if you don't need to. For a primary test I did e.g.: if GetThreadManager(CurrentThreadManager) then begin CurrentBasicEventCreateHandler:=CurrentThreadManager.BasicEventCreate; end; if Assigned(CurrentBasicEventCreateHandler) then begin CurrentBasicEventCreateHandler(EventPointer, False, False, 'TestEvent'); /nonsense call to a BasicEventCreateHandler function end; Could you show me how to do an arch/OS independent call to the function that at runtime is pointed to by CurrentBasicEventCreateHandler. Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Active NoGui LCL Widget Type
In order not to steel yet another Thread topic I answer in a new thread On 06/27/2014 11:35 AM, Mattias Gaertner wrote in Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?: handling the waiting and waking for both Queues simultaneously. This (waiting and waking regarding the additional queue) needs arch depending code (as done in the GUI based Widget Types). That's not arch dependent, but library dependent. In case of nogui there is no library, so you have the full control. I just re-checked and found that in thread.inc the waiting and waking is done by calls to callback variables such as rtleventWaitFor and rtleventSetEvent. When initializing, these variables are filled with the appropriate OS-depending function pointers by code in the file systhrd.inc located in the OS-appropriate folder. I understand that the rtlevent... stuff and the method to append an event to the TThread queue is private to TThread and hence I can't use this for TTimer and TApplication.QueueAsyncCall, Hence my only option (other than constructing an additional queue including an additional OS-depending waiting and waking mechanism) is using the timeout of CheckSynchronize (e.g. for TTimer), and TThread.Queue (e.g. for TApplication.QueueAsyncCall). And this is what technically already seems to work rather nicely. With that it will only work officially with the next release of the fpc rtl (no problem for me, but maybe preventing a decent patch to the official svn). What can't be done without a modification in the fpc RTL is that this way TApplication.QueueAsyncCall will not be Queued when called from the main thread (no problem for me, but maybe preventing a decent patch to the official svn). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Active NoGui LCL Widget Type
Am 10.07.2014 13:34 schrieb Michael Schnell mschn...@lumino.de: In order not to steel yet another Thread topic I answer in a new thread On 06/27/2014 11:35 AM, Mattias Gaertner wrote in Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?: handling the waiting and waking for both Queues simultaneously. This (waiting and waking regarding the additional queue) needs arch depending code (as done in the GUI based Widget Types). That's not arch dependent, but library dependent. In case of nogui there is no library, so you have the full control. I just re-checked and found that in thread.inc the waiting and waking is done by calls to callback variables such as rtleventWaitFor and rtleventSetEvent. When initializing, these variables are filled with the appropriate OS-depending function pointers by code in the file systhrd.inc located in the OS-appropriate folder. I understand that the rtlevent... stuff and the method to append an event to the TThread queue is private to TThread and hence I can't use this for TTimer and TApplication.QueueAsyncCall, Hence my only option (other than constructing an additional queue including an additional OS-depending waiting and waking mechanism) is using the timeout of CheckSynchronize (e.g. for TTimer), and TThread.Queue (e.g. for TApplication.QueueAsyncCall). The TThreadManager.RTLEvent* procvars are available through analogous named RTLEvent* functions... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Active NoGui LCL Widget Type
On 07/10/2014 02:49 PM, Sven Barth wrote: The TThreadManager.RTLEvent* procvars are available through analogous named RTLEvent* functions... Thanks a lot for the pointer. I'll take a look ASAP. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Active NoGui LCL Widget Type
On 07/10/2014 02:49 PM, Sven Barth wrote: The TThreadManager.RTLEvent* procvars are available through analogous named RTLEvent* functions... OK. I found the global function GetThreadManager and via it's result I seemingly can use the TThread Queue. Maybe it's possible to avoid using TThread.Queue (and the said problems) by this. Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Active NoGui LCL Widget Type
On 10.07.2014 16:36, Michael Schnell wrote: On 07/10/2014 02:49 PM, Sven Barth wrote: The TThreadManager.RTLEvent* procvars are available through analogous named RTLEvent* functions... OK. I found the global function GetThreadManager and via it's result I seemingly can use the TThread Queue. Maybe it's possible to avoid using TThread.Queue (and the said problems) by this. You should not need to use the thread manager. All functions (except the semaphore ones which are only implemented for cthreads) should be available by RTL functions. So don't use GetThreadManager if you don't need to. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
