Hi Krzysztof,
Yeah I mean it sounds like a dirty hack, and seems like it might not be
reliable, plus theoretically starting processes is a much "heavier"
solution. However, from a practical point of view, I have found that it
works perfectly, and cross-platform to boot. In windows, you can just have
the EXE you want to launch in the same folder with the main program, in Mac
OS, you can put it in the application bundle.
It's even better if you are using a feature that multiple applications might
want to use, or where you might want to change the implementation of. For
example, my Map Viewer demo launches a helper deamon (erm, I'm sorry,
"Agent" in Mac OS terms) program in the background which connects to Core
Location - but there is also a different daemon that connects to PlaceEngine
instead to get the location engine. The implementations are totally
different, (and PlaceEngine will freeze your app because it uses long
running local HTTP calls), but separating it out makes it easy to mix/match,
and eliminates and worries about thread-safety, etc.
On the other hand, you probably don't want your program starting 100
processes, as it adds complexity and adds one more thing to break. The GUI
+ Deamon/Server design pattern is fairly common on normal Unix systems,
though, and that's because it works well.
-- Noah
2011/5/12 Krzysztof <dib...@wp.pl>
> Trick with another process sounds good. Thanks :)
>
>
> 2011/5/12 Noah Silva <shir...@galapagossoftware.com>
>
>> Hi Krzysztof,
>>
>> I can think of several solutions:
>> 1. Don't call application.processmessages, but something else which only
>> updates the GUI display (I have seen this mentioned somewhere, but I don't
>> remember the name of the call now).
>> 2. If you want to allow more than GUI updating, but want to prevent, f.e.
>> closing the window, then you can track the status of the IMAP thread, and
>> disallow certain things based upon that. For example the OnCloseWindow or
>> similar event can prevent the window close if IMAP is busy.
>> 3. When you say the IMAP is running "on the control" - is this a GUI
>> component version of the IMAP? If so, you should put it in a DataModule
>> instead of on the form to solve this problem.
>> 4. You could take the extreme approach as I sometimes do, and just put it
>> in another *process* which you launch in the background and communicate with
>> via the IPC components :) This has the added benefit of automatic queuing.
>>
>>
>> Anyway what I have wanted to see, and still haven't, is a simple example
>> for setting/using the OnHeartBeat option from (non GUI) THTTPSend in code.
>> (Yes, I know it's probably trivial, but examples help everyone).
>>
>> Thank you,
>> Noah Silva
>>
>> 2011/5/12 Krzysztof <dib...@wp.pl>
>>
>>> Hi,
>>>
>>> When I wanted solve problem with THTTPSend freezing, I always use threads
>>> which works perfect. But HTTP is stateless protocol so this was good
>>> solution, but how to solve problem with TIMAPSend which must have connection
>>> with imap server? I know that exists OnHeartBeat callback event, but I have
>>> bad memories with solutions of this kind. In OnHeartBeat event I call
>>> Application.ProcessMessages or Application.HandleMessages for GUI
>>> refreshing. I get some strange errors sometimes, for example: user try to
>>> close control (tabsheet or form) where imap is running, he click 2 or 3
>>> times but imap is busy and then my application crash (I supose HeartBeat
>>> call ProcessMessages which try to destroy this same control again). Anyone
>>> know some tricks for HeartBeat?
>>>
>>> Regards
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Achieve unprecedented app performance and reliability
>>> What every C/C++ and Fortran developer should know.
>>> Learn how Intel has extended the reach of its next-generation tools
>>> to help boost performance applications - inlcuding clusters.
>>> http://p.sf.net/sfu/intel-dev2devmay
>>> _______________________________________________
>>> synalist-public mailing list
>>> synalist-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/synalist-public
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> synalist-public mailing list
>> synalist-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/synalist-public
>>
>>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> synalist-public mailing list
> synalist-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/synalist-public
>
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
