LostFocus event with Scrollbar gadget

[kiwidave]

Hi,

I have come across behaviour which I would classify as a bug. In simple terms, if I have a string or editor gadget (there may be others, but these are two examples I am sure of) on a window with a scrollbar, if I move between the string and editor gadgets the LostFocus event on these is fired perfectly. However, if I am on either the string or editor boxes, then click on the scrollbar, then there is no firing of the LostFocus event at all. This of course makes it impossible to use LostFocus to manipulate entered data in conjunction with the scrollbar gadget.

The topic in which I posed this question is "Event handling with scrollbar" (http://forum.purebasic.com/english/view ... 13&t=58720), along with a nice example of the problem in action posted by the ever-helpful TI-994A.

Thank you.

[netmaestro]

I don't think it's a bug as clicking/moving the scrollbar doesn't (and shouldn't) change the currently focused gadget. If you go from an editor or string to a scrollbar the active gadget is still the same. Focus is not lost, hence no LostFocus event. Remember, a scrollbar is a kind of 'helper' control, not another 'top-level' gadget that you're moving to like a button etc.

[kiwidave]

I don't think it's a bug as clicking/moving the scrollbar doesn't (and shouldn't) change the currently focused gadget. If you go from an editor or string to a scrollbar the active gadget is still the same. Focus is not lost, hence no LostFocus event. Remember, a scrollbar is a kind of 'helper' control, not another 'top-level' gadget that you're moving to like a button etc.

I can certainly appreciate that viewpoint, but from a practical perspective I'm afraid that I don't agree with it. Take the example I am coding. I have three data entry fields: "Name", "Position" and "Email". I am wanting the user to enter text into these fields, with multiple rows, say four rows to enter on, but the entire list could be any number of rows. So we have a grid, with the headings in the three columns, and four rows deep. The scroll bar is used to scroll up and down the list with the four rows on the form being a 'window' into this list. Now, when the user enters some text in one of these fields, upon exiting the field, the LostFocus event will write the value (entered text) into an array, so when the list is scrolled, the value in the array can be placed in the correct field. However, if the user enters some text, then immediately clicks on the scrollbar, there is no LostFocus event fired, and the scrollbar event then refreshes the display with the freshly entered text missing as it never got saved to the array. In this situation the scrollbar is indeed operating as a "Top Level" gadget. I would also go so far as to say that all gadgets that process interactive events are "Top Level" as I'm sure that this example could equally apply to, say, a Slider control and others.

Yes, there is a workaround using the Changed event, but this leads to unnecessary system overhead where processing occurs for every single character that is typed in a field. Therefore we have the situation where we either say that the scrollbar should allow the LostFocus event on a gadget to be triggered, or alternatively we have to say that the LostFocus event has no value under a number of circumstances.

[Danilo]

If you go from an editor or string to a scrollbar the active gadget is still the same. Focus is not lost, hence no LostFocus event. Remember, a scrollbar is a kind of 'helper' control, not another 'top-level' gadget that you're moving to like a button etc.

Same behavior on Mac OS X. EditorGadget still has focus while scrolling a ScrollbarGadget.