Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 11 to 20 of 23 total |
Need Help with Threads -- Trying to update VCL component |
Mon, Jul 24 2006 1:23 PM | Permanent Link |
Sean McCall | That assumes that the users would actually read what was on
the screen Roy Lambert wrote: > Sean > > > About the only thing that I can see that will work for you in all the scenarios you describe (eg the main thread of the app processing stuff that won't let messages through) is to write directly to screen memory (if that's even possible these days) and all I have to say to that is "rather you than me"! > > Personally if there's stuff clogging up the foreground to that degree I'd prefer to just put up a message "go and have a nice cup of coffee and chill out for 10" <vbg> > > > > Roy Lambert > |
Mon, Jul 24 2006 1:55 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Sean
>That assumes that the users would actually read what was on >the screen Good one - and your reason for a progress indicator was........ |
Mon, Jul 24 2006 3:23 PM | Permanent Link |
Sean McCall | For some reason they don't read but they do react to a
progress bar moving. If I really had my way I could get the keyboard to shock them when they did something stupid... Roy Lambert wrote: > Sean > > >>That assumes that the users would actually read what was on >>the screen > > > Good one - and your reason for a progress indicator was........ > |
Mon, Jul 24 2006 5:25 PM | Permanent Link |
Bernd Kuhlmann | Sean,
i posted a simple demo to the binary newsgroup. The progressbar is updated no matter what you do in the thread until the thread is finished. Additionally the thread updates the button if one loop has been completed to give some "real" feedback to the user. Bernd Kuhlmann |
Tue, Jul 25 2006 2:11 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Bernd
That's pretty much the same as I posted. The problem is Sean wants the progress indicator to continue even if the MAIN thread is sleeping or doing something very intense eg running a procedure from a 3rd party DLL where he has no influence over it. Roy Lambert |
Tue, Jul 25 2006 3:42 AM | Permanent Link |
"Frans van Daalen" | "Sean McCall" <NoSpam@nowhere.com> wrote in message news:BA0B2A97-7B20-4D53-A47D-AC74EA130C12@news.elevatesoft.com... > Roy, > > Thanks for taking the time to put that together, but your demo just > demonstrates what I need. You should notice that when you click button2 > that the progress bar stops moving and then catches up when the sleep loop > completes. This is because no messages are being processed while > "sleeping". What I want is for the progress bar to keep steadily moving > while button2's event handler is sleeping. If you change the sleep time to > 25 seconds (make it 2500 ms or change the loop to 100) you will notice > that the demo appears to lock up. I want to find some way to give a visual > cue that it is not locked up in cases where I don't have access to the > code that is causing the delay. > Just create the progress form in a small independend program/exe and send the thread progress messages to that program. That IMHO is to only way if the main program is extremly busy. |
Tue, Jul 25 2006 9:18 AM | Permanent Link |
Sean McCall | Bernd,
Thanks for taking the time to try this. Your method works fine if the time consuming task is taking place within the secondary thread. My problem is what to do when time consuming tasks are taking place within the main thread and I don't have an opportunity to force the application to process messages. Add a Sleep(10000) at the end of the Button1Click event and you'll see what I mean. The TTimer component relies on the main thread actively processing messages. Sean Bernd Kuhlmann wrote: > Sean, > > i posted a simple demo to the binary newsgroup. > The progressbar is updated no matter what you do in the thread until the > thread is finished. Additionally the thread updates the button if one loop > has been completed to give some "real" feedback to the user. > > > Bernd Kuhlmann |
Tue, Jul 25 2006 9:20 AM | Permanent Link |
Sean McCall | Could have saved some typing if I read all the messages
before responding to Bernd. Roy has it right. Sean Roy Lambert wrote: > Bernd > > > That's pretty much the same as I posted. The problem is Sean wants the progress indicator to continue even if the MAIN thread is sleeping or doing something very intense eg running a procedure from a 3rd party DLL where he has no influence over it. > > Roy Lambert > |
Tue, Jul 25 2006 2:24 PM | Permanent Link |
"Darren Davis" | "Sean McCall" <NoSpam@nowhere.com> wrote in message
news:4E010836-FDF1-47DB-B5E2-492024EFEBA1@news.elevatesoft.com... > For some reason they don't read but they do react to a progress bar > moving. If I really had my way I could get the keyboard to shock them when > they did something stupid... If all you want is a progress bar then the TProgressBar won't work for you in this instance - if you want to be really naughty you can force a refresh on the PegtopProgressBar (www.pegtop.net) from a seperate thread - although personally I couldn't condone such behaviour procedure TTestThread.Execute; var nLoop : Integer; begin for nLoop:=1 to 100 do begin Form1.PegTopProgressBar1.Position:=nLoop; Form1.PegTopProgressBar1.Refresh; Sleep(20); end; end; procedure TForm1.Button1Click(Sender: TObject); begin With TTestThread.Create(False) do try WaitForSingleObject(Handle,INFINITE); finally Free; end; end; D. |
Tue, Jul 25 2006 3:34 PM | Permanent Link |
Sean McCall | Darren,
Sounds like this might be what I need. Couldn't find the PegtopProgressBar on the site. Could you give me a hint on where to find it? BTW, are you the author? Sean Darren Davis wrote: > "Sean McCall" <NoSpam@nowhere.com> wrote in message > news:4E010836-FDF1-47DB-B5E2-492024EFEBA1@news.elevatesoft.com... > >>For some reason they don't read but they do react to a progress bar >>moving. If I really had my way I could get the keyboard to shock them when >>they did something stupid... > > > If all you want is a progress bar then the TProgressBar won't work for you > in this instance - if you want to be really naughty you can force a refresh > on the PegtopProgressBar (www.pegtop.net) from a seperate thread - although > personally I couldn't condone such behaviour > > procedure TTestThread.Execute; > var > nLoop : Integer; > begin > for nLoop:=1 to 100 do > begin > Form1.PegTopProgressBar1.Position:=nLoop; > Form1.PegTopProgressBar1.Refresh; > Sleep(20); > end; > end; > > procedure TForm1.Button1Click(Sender: TObject); > begin > With TTestThread.Create(False) do > try > WaitForSingleObject(Handle,INFINITE); > finally > Free; > end; > end; > > D. > > |
« Previous Page | Page 2 of 3 | Next Page » |
Jump to Page: 1 2 3 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |