![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Binaries » View Thread |
Messages 11 to 18 of 18 total |
![]() |
Fri, May 27 2022 2:11 PM | Permanent Link |
Heiko Knuettel | Roy
You beat me to it :-D thanks, mate Just need to find out if the progressbar.update just updates the progressbar, or gives the application breathing room so it can answer to the Windows "are you alive" call . |
Sat, May 28 2022 2:36 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Heiko
>Just need to find out if the progressbar.update just updates the progressbar, or gives the application breathing room so it can answer to the Windows "are you alive" call . Just updates the progress bar - it effectively, from my reading of the OLH, bypasses windows messaging. As I said I don't know just what causes Windows to decide an application is frozen. I have the procedure below which cleans out the message queue which may do the job but you have to be careful where its put otherwise nothing will happen in your application. procedure EatAllMessages; var Msg: TMsg; begin while PeekMessage(Msg, 0, 0, 0, PM_REMOVE or PM_NOYIELD) do ; end; Roy |
Sat, May 28 2022 10:49 AM | Permanent Link |
Raul ![]() | On 5/25/2022 11:10 AM, Heiko Knuettel wrote:
> Hi! > > Since I'm still experiencing this error I tried to boil down my CS application to a demo project. > > Interestingly this error only happens in this scenario when I have the application.processmessages in the onProgress event. I do that because it's the easiest way to keep the application responsive during long queries. I'm little late to the party here but this is interesting re-entrancy issue and looks like an EDB limitation. OnProgress event is called by an active executing query instance and calling application.ProcessMessages causes windows messages to be pumped which then causes your timer event to fire (since timer is just a WM_TIMER message in queue) which now starts a 2nd active query instance using same session and DB. Error message indicate that session manager cannot be locked which i suspect means that session can only have one executing operation on it at any point in time. Sessions are per thread and EDB in general is blocking so normally you would not run into this. I don't think there is an easy way to detect this today (in your larger application) so if you want to call application.ProcessMessages in onprogress you would need to ensure things like timers and mouse/keyboard input does not trigger EDB operations - using a global flag of some kind would work but you'd need to set it /clear it all the time Raul |
Sat, May 28 2022 11:05 AM | Permanent Link |
Raul ![]() | On 5/28/2022 2:36 AM, Roy Lambert wrote:
> Just updates the progress bar - it effectively, from my reading of the OLH, bypasses windows messaging. As I said I don't know just what causes Windows to decide an application is frozen. I have the procedure below which cleans out the message queue which may do the job but you have to be careful where its put otherwise nothing will happen in your application. > Yes - update calls Win32 API UpdateWindow (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-updatewindow) so it's just windowcontrol update AFAIK window manager monitors application message queue and if it is not being serviced every approx 5 seconds (i.e. messages older than that in queue) it considers app frozen and creates the "ghost" window so user can do basic interactions (but they are not interacting with your app window). Raul |
Sat, May 28 2022 12:04 PM | Permanent Link |
Heiko Knuettel | Thanks for all the input guys!
Currently I'm using the timer for some background stuff, like checking for new user messages etc. If I understand correctly, if I used a separate session for that (and maybe move all that stuff into a thread instead of a timer) I should be good? Will try that on Monday... |
Sat, May 28 2022 7:55 PM | Permanent Link |
Raul ![]() | On 5/28/2022 12:04 PM, Heiko Knuettel wrote:
> Thanks for all the input guys! > > Currently I'm using the timer for some background stuff, like checking for new user messages etc. > > If I understand correctly, if I used a separate session for that (and maybe move all that stuff into a thread instead of a timer) I should be good? > Yes - I would expect using a separate session for timer based processing should solve the problem as long as you ensure that only 1 query executes on any given session at a time You should not even need to even move the logic to separate thread in that case - you can of course but that is larger (though better) redesign. Only other thing is that if your app uses temporary tables then those are per session. Raul |
Sun, May 29 2022 2:14 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Raul
>AFAIK window manager monitors application message queue and if it is not >being serviced every approx 5 seconds (i.e. messages older than that in >queue) it considers app frozen and creates the "ghost" window so user >can do basic interactions (but they are not interacting with your app >window). Thanks for that. I couldn't find the right search term to find anything out. It means that eating all the messages should work then. Roy |
Tue, May 31 2022 10:58 AM | Permanent Link |
Raul ![]() | On 5/29/2022 2:14 AM, Roy Lambert wrote:
> > Thanks for that. I couldn't find the right search term to find anything out. It means that eating all the messages should work then. > Yes but it's bit of a nuclear option and IMHO only works for relatively simple apps. You'd be eating all messages including any of your own (in case of a multi-thread app and app that uses this for some async processing) Raul |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |