Advice on multi-threading
in [Visual Objects]
|
From: Nick Friend on 12 Apr 2010 18:38 In adapting our application to use replication and ADS, we have a process fired off periodically by a timer, which checks to see that all the remote connections and replication queues are functioning correctly. Ideally I'd like this to run as a separate thread, so that it doesn't interrupt the normal work in the app - some clients could have 15 or 20 remote systems and periodically the system will be accessing web- services to check on the status of all of them, so it could potentially be taking 1 or 2 minutes to complete. However it also constantly updates a status window on the main app shell, so the user can see what the status of the system is. Looking through the notes on multi-threading, the main no-no seems to be any access to the GUI. I suppose one solution would be to update the status window with a "Checking status" message, then go into the separate thread, and then update the status window when the thread exits. But that makes the status window rather static and uninformative. Any suggestions or advice? TIA Nick
From: Ginny Caughey on 12 Apr 2010 19:00 Use PostMessage from the worker thread to the GUI form's handle. You are correct you should never update the GUI thread directly from another thread. (There is an example in my old Serial class.) But why not use a separate app entirely run as a scheduled task? And why do you feel you need to tell the user that you've synced? It seems to me the user should only care if there is some error condition that prevents normal syncing. -- Ginny Caughey www.wasteworks.com "Nick Friend" <nicktekhne(a)googlemail.com> wrote in message news:119b467b-6508-4efb-b240-5bb41cd28fd4(a)g11g2000yqe.googlegroups.com... > In adapting our application to use replication and ADS, we have a > process fired off periodically by a timer, which checks to see that > all the remote connections and replication queues are functioning > correctly. > > Ideally I'd like this to run as a separate thread, so that it doesn't > interrupt the normal work in the app - some clients could have 15 or > 20 remote systems and periodically the system will be accessing web- > services to check on the status of all of them, so it could > potentially be taking 1 or 2 minutes to complete. However it also > constantly updates a status window on the main app shell, so the user > can see what the status of the system is. > > Looking through the notes on multi-threading, the main no-no seems to > be any access to the GUI. I suppose one solution would be to update > the status window with a "Checking status" message, then go into the > separate thread, and then update the status window when the thread > exits. But that makes the status window rather static and > uninformative. > > Any suggestions or advice? > > TIA > > Nick
From: Willie Moore on 12 Apr 2010 23:04 I am with Ginny on this one. A separate app that can be scheduled is far easier to code and maintain than adding the multi-threading to your main app. When I wrote MLM software, we always had a back office machine that ran a scheduled task every 3 minutes to handle anything in the que. Regards, Willie "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message news:4bc3a57d$0$10944$c3e8da3(a)news.astraweb.com: > Use PostMessage from the worker thread to the GUI form's handle. You are > correct you should never update the GUI thread directly from another thread. > (There is an example in my old Serial class.) > > But why not use a separate app entirely run as a scheduled task? And why do > you feel you need to tell the user that you've synced? It seems to me the > user should only care if there is some error condition that prevents normal > syncing. > > -- > > Ginny Caughey > www.wasteworks.com > > > > > "Nick Friend" <nicktekhne(a)googlemail.com> wrote in message > news:119b467b-6508-4efb-b240-5bb41cd28fd4(a)g11g2000yqe.googlegroups.com... > > > In adapting our application to use replication and ADS, we have a > > process fired off periodically by a timer, which checks to see that > > all the remote connections and replication queues are functioning > > correctly. > > > > Ideally I'd like this to run as a separate thread, so that it doesn't > > interrupt the normal work in the app - some clients could have 15 or > > 20 remote systems and periodically the system will be accessing web- > > services to check on the status of all of them, so it could > > potentially be taking 1 or 2 minutes to complete. However it also > > constantly updates a status window on the main app shell, so the user > > can see what the status of the system is. > > > > Looking through the notes on multi-threading, the main no-no seems to > > be any access to the GUI. I suppose one solution would be to update > > the status window with a "Checking status" message, then go into the > > separate thread, and then update the status window when the thread > > exits. But that makes the status window rather static and > > uninformative. > > > > Any suggestions or advice? > > > > TIA > > > > Nick __________ Information from ESET NOD32 Antivirus, version of virus signature database 5023 (20100412) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
|
Pages: 1 Prev: Eval/ForEach Next: Error when passing negative number as parameter to MSSQL stored procedure |