Planning ahead for threads and more interactivity in rev apps

[Jim Ault]

My workaround for this is to have a 'shell helper' app.
In the past I have used simple text files to be the flags and hold variables
to be passed, as well as UDP messaging between apps on the same computer.

Another solution was to make an ftp agent app that would auto-up/download
text files between networks, but this does not seem to be what you are
asking.

Basically my approach to multi-threading is a separate app and let the
operating system do the threading.  Extra benefit may be that the 'send'
could be more reliable timing if you use a shell command (cron), but this
may be outside of your goals.

This means the visible interface would trigger changes in the shell-helper
app running hidden.  The helper app would always check the text file for
changes before doing the next ping.

Hope this helps

Jim Ault
Las Vegas


On 11/8/07 7:55 AM, "xavier.bury at clearstream.com"
<xavier.bury at clearstream.com> wrote:

> Hi everyone,
> 
> 
> 
> In order to make an application more responsive, im thinking of
> 
> implementing a kind of threading so that the application can still run
> 
> while the GUI remains responsive. The application in question is a domain
> 
> scanner and it scans some hundreds of servers which takes quite a while
> 
> given the number of servers, their locations or type (phys. or virtual). I
> 
> dont need this to go faster mind you but i dont want to go slower
> 
> either... 
> 
> 
> 
> All i need is to be able to browse tabs and eventually change a setting or
> 
> another.
> 
> 
> 
> Problem is that mouse interception is not really working because of the
> 
> intermittent shell calls and any mouseclick seems to get lost. Unless i
> 
> want to click for 1-4 minutes and wait with the mousedown which i dont
> 
> really fancy for anyone to suffer.
> 
> 
> 
> Using "send" is also not a good idea because i use shell commands that may
> 
> take different times to finish - some servers are vmware slow or are
> 
> located in places like dubai or Prague may not respond too quickly...
> 
> Problem with the send command is that if you ask it to send something in 5
> 
> seconds and there is a process already running, the send will definitely
> 
> not run in 5 seconds... And worse, it may prevent intercepting your
> 
> mouseclick.
> 
> 
> 
> I was thinking of a script that runs the shell, waits if mouseclick or
> 
> something like that... But last thing i want is to make this complex code
> 
> more complex... And im not sure the mouseclick will not be lost while the
> 
> script runs. 
> 
> 
> 
> Something "interactive" is what I am looking for...
> 
> 
> 
> Last but not least, i can't (or dont want to) manage more than 1 shell
> 
> running at a time using a quick batch runner - meaning i'll have to manage
> 
> interleaving and limiting processing load. The server has other functions
> 
> and i can't monopolize the processors... Although this seems like my best
> 
> solution.
> 
> 
> 
> Im just planning ahead this feature so all your ideas are welcome! Im sure
> 
> many of us revvers are looking for a script like this at some point for
> 
> applications that take time to process...
> 
> 
> 
> Thanks in advance
> 
> Xavier
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Clearstream Services S.A.
> 
> 42 Avenue JF Kennedy, L-1855 Luxembourg
> 
> Société anonyme is organised with limited liability
> 
> in the Grand Duchy of Luxembourg R.C.S. Luxembourg B 60911.
> 
> 
> 
> 
> 
> -----------------------------------------
> 
> Visit us at http://www.clearstream.com
> 
> 
> 
> IMPORTANT MESSAGE
> 
> 
> 
> Internet communications are not secure and therefore Clearstream
> International does not accept legal responsibility for the contents
> of this message.
> 
> 
> 
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended solely for the addressee. If you
> are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance
> on it, is prohibited and may be unlawful. Any views expressed in
> this e-mail are those of the individual sender, except where the
> sender specifically states them to be the views of Clearstream
> International or of any of its affiliates or subsidiaries.
> 
> 
> 
> Legally required information for business correspondence/
> 
> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
> 
> http://deutsche-boerse.com/letterhead
> 
> 
> 
> END OF DISCLAIMER
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution