winapi - In Delphi 2010, the Click event processed despite the corresponding button being disabled -
consider following piece of code executed within onclick event of given button:
procedure tform1.button1click(sender: tobject); begin button1.enabled := false; //line 1 application.processmessages; //line 2 sleep(3000); //line 3 button1.enabled := true; //line 4 release; //line 5 end;
in delphi 2010, if after clicking button manage perform yet click on while execution busy in line 3, subsequent click event apparently stored in queue of commands, when release(line 5) procedure called, application attempt process it. consequently click event triggered once again. second time around, button component has been destroyed, hence "access violation" error get's raised.
the whole concept of acknowledging second click system when respective button disabled not seem sound. explanations shady behavior?
the system behaving designed, aware code going against sound design principles. use of sleep
, processmessages
in input event handler both frowned upon.
the reason program behaves way follows:
- the user generates input message clicking mouse.
- this input event placed in input queue appropriate thread.
- that thread not servicing input queue (it sleeping) , input message, mouse down, mouse combo, sits there.
- the thread wakes , enables button.
- the button
onclick
handler returns , application's message loop continues. - in due course mouse down , mouse messages processed (before
cm_release
message) , buttononclick
handler runs again. - the button
onclick
handler callsprocessmessages
handlescm_release
, kills form. - boom!
the whole concept of acknowledging second click system when respective button disabled not seem sound.
the key point enabled state of button checked when input message processed , not when input message generated. has way because input messages extremely low level things, , it's application can interpret them things button clicks.
there plenty of ways fix code, i'm loathe suggest because code illustration. sound solutions involve removal of calls sleep
, `processmessages.
Comments
Post a Comment