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 .

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

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

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

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...

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

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

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