It seems that me couldn't catch this problem because stepped debugging breaks the form modality sequence. With changing BP placement to traverse this sequece w/o stepping, it's found that the focus loss happened when disabling the below widget, before calling window.setfocusedwidget(nil):
twidget(twidget(this).fparentwidget).fname = 'gbMonths' twidget(twidget(this).fparentwidget).fwidgetstate = [WS_VISIBLE, WS_ACTIVE..WS_ENTERED, WS_MOUSEINCLIENT..WS_OPAQUE, WS_ISVISIBLE] twidget(this).fname = 'dbbeM01' (belongs to groupbox 'gbMonths') twidget(this).fwidgetstate = [WS_VISIBLE..WS_ENTERED, WS_FOCUSED, WS_ISWIDGET..WS_OPAQUE, WS_ISVISIBLE] twidget(twindow(twidget(this).fwindow).ffocusedwidget).fname = 'dbbeM01' -------------- procedure twidget.enabledchanged; var int1: integer; bo1: boolean; begin bo1:= isenabled; // = FALSE if not bo1 then begin if focused then begin window.setfocusedwidget(nil); // <<<< HERE end; end; if fframe <> nil then begin if bo1 or not (frl_nodisable in fframe.flocalprops) then begin fframe.setdisabled(not bo1); end; end; for int1:= 0 to widgetcount - 1 do begin widgets[int1].enabledchanged; end; statechanged; end; ---------------------- Don't we have an wrong (to widget of same form) detection of form focus change here ? ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
