This is odd...

Doubleclicking a control generates three events in this order:

WMLMButtonUp
WMLMButtonDblClk
WMLMButtonUp

This causes me grief because if I use setfocus during the dblclk event, the next buttonup event will set the focus to NO control, despite the fact that I'm not setting focus within the event handler. What then happens is that if you hit tab after a doubleclick on the TCheckbook control, the program crashes saying that you can't focus an invisible control. The crash is generated by the TControl.Tabhandler or something like that... not by my code directly.

I've added a workaround to detect if I'm getting the duplicate buttonup message immediately following the doubleclick, and set a focus within that event to the control I want.

-Tony

Mattias Gaertner wrote

Can you send a backtrace?

Well here's two things. Attached is a sample project demonstrating the lack of setfocus working in a dblclick event.

I can't reproduce the crash except in CheckBook Tracker, so it may have something to do with the runtime creation of the components or some such. But, I took out my fix code and recreated the crash and here's the crash with a backtrace:

{{{ I double-click the TCheckbook and get this, which is correct, but it never focuses the CmbWithdrawPayTo which I try to do in the ondblclick handler }}}

TCheckBook.WMLMButtonUp::MESSAGE
TFrmMain::CheckSelected
TFrmMain::CheckSelected::DONE
TCheckBook.WMLMButtonDblClk::MESSAGE
TFrmMain.EditWithdrawAmountCHANGE Called
TFrmMain.EditWithdrawAmountCHANGE Called
EditWithdrawal::Setting focus to checkbook
EditWithdrawal::Setting focus to CmbWithdrawPayTo
EditWithdrawal::Done
TCheckBook.WMLMButtonUp::MESSAGE
TFrmMain::CheckSelected
TFrmMain::CheckSelected::DONE

{{{ next I hit tab and this happens... }}}

ERROR in LCL: Cannot focus a disabled or invisible window Creating gdb catchable error:

Program received signal SIGFPE, Arithmetic exception. $0814a6c9 in RAISEGDBEXCEPTION (MSG=$8347c66) at lclproc.pas:415 415 lclproc.pas: No such file or directory.
in lclproc.pas
Current language: auto; currently pascal

(gdb) backtrace full
#0 $0814a6c9 in RAISEGDBEXCEPTION (MSG=$8347c66) at lclproc.pas:415 No locals.
#1 $081186af in TCUSTOMFORM__SETACTIVECONTROL (AWINCONTROL=$84daf34, this=$84d59b4) at customform.inc:889
No locals.
#2 $08117578 in TCUSTOMFORM__FOCUSCONTROL (WINCONTROL=$84daf34, this=$84d59b4)
at customform.inc:137
WASACTIVE = true
#3 $0812443c in TWINCONTROL__SETFOCUS (this=$84daf34) at wincontrol.inc:1715
FORM = (^TCUSTOMFORM) $84d59b4
#4 $08127b3c in TCONTROL__PERFORMTAB (FORWARDTAB=true, this=$85062f4) at control.inc:814
I = 9
LIST = (^TLIST) $86bcdf4
FIRSTFOCUS = (^TCONTROL) $84daf34
OLDFOCUS = (^TCONTROL) $0
NEWFOCUS = (^TCONTROL) $84daf34
TOPLEVEL = (^TWINCONTROL) $84d59b4
PERFORMTAB = true (8)
RESULT = true (8)
#5 $0805d32a in GTKKEYUPDOWN (WIDGET=$8ba6bc8, EVENT=$8b668e8, DATA=$85062f4)
at gtkcallback.inc:642
MSG = {MSG = 258, CHARCODE = 9, UNUSED = 0, KEYDATA = 0, RESULT = 0} CODE = 9
KEYCODE = 65535
FLAGS = 0
TOGGLE = false
EXTENDED = false
SYSKEY = false
SHIFTSTATE = []
EVENTSTOPPED = true
TOPLEVEL = (PGTKWIDGET) $8b513a8
GTKKEYUPDOWN = true
RESULT = true
#6 $400c7618 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0 No symbol table info available.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gz00037.gz
Type: application/octet-stream
Size: 1948 bytes
Desc: "dblclicktest.tgz"
Url : http://localhost/pipermail/lazarus/attachments/20030923/0ff7b2e7/gz00037.obj

SetFocus is a known issue. Setting the focus in events does not work with the gtk, because some gtk widgets set focus themselves.

I can't reproduce the crash except in CheckBook Tracker, so it may have something to do with the runtime creation of the components or some such. But, I took out my fix code and recreated the crash and here's the crash with a backtrace:

I think, I need some more information. Can you point me to the current version of cbt and tell me how to reproduce the crash?

Mattias

I don't know, what control you mean, but that's probably done by the gtk.

Can you send a backtrace?

I've added a workaround to detect if I'm getting the duplicate buttonup message immediately following the doubleclick, and set a focus within that event to the control I want.

I hope focussing will work better in the gtk2.

Mattias

It happens on drag operations. The gtk list box has no treshold and so there is always a drag. I don't know, why the last item is selected. The gtk-interface does not select. Maybe something the gtk-interface does, resets the gtk drag operation.

Mattias

Yes, that sounds like what's happening. I've noticed that the problem is much more likely to occur if the mouse isn't perfectly still when clicked... so perhaps this is prematurely initiating a drag.

Is there a workaround for this? It's not a killer problem but it sure can be

I've been trying to run down an event related issue that sounds similar. Single clicking on items in a listbox frequently causes the focus and returned itemindex to jump around erratically. When it happens, the itemindex returned is the last item of the list with the focus somewhere close to the last item.

-Tom