[Gambas-user] ComboBox not editable + Combopbox_Change Event

[B Bruen]

On Fri, 30 May 2014 21:13:01 +0200
Fabien Bodard <gambas.fr at ...626...> wrote:

> Le 30 mai 2014 16:39, "abbat81" <abbat.81 at ...787...> a écrit :
> >
> > I need those 2 properties:
> >
> > 1) ComboBox not editable
> > 2) Combopbox_Change Event
> >
> > in one control.
> >
> > ReadOnly locks Event and default property allows to edit ComboBox.Text.
> 
> ???????
> 
> >
> > Thanks
> > 

Hmmmm. I too have noticed a few things.

1) ComboBox "ReadOnly" property really only -- enforces that the dropdown feature of the control must be used --
Essentially, that means only items in the dropdown list can be selected. If ReadOnly is true, then typing in the combobox text area just invokes the "search" feature. So, if the list contains "Apples","Berries" and "Figs" then typing "F" will set the current item to the "Figs" entry in the list. BUT, as someone recently said, this only happens with QT4. With either of the GTK GUIs the search function is not invoked.
If ReadOnly is false, then under QT4 you can enter anything in the textbox BUT this will not set the "inner cursor". So even if the text entered is an item in the list, the cursor does not move to that item. To invoke the search feature, you must have the dropdown list visible .
Under GTK GUIs the search feature still does not occur, whether or not the list is visible.

2) So if you need to set a combobox to a "real" ReadOnly state, you need to disable the control, i.e. set MyCombo.Enabled=False. (Also it probably helps the user if you also set MyCombo.NoTabFocus to True as well.  But the obvious question is why would you want a combobox to be "seriously" readonly.  The answer is, there are situations where given the value of some other control then the value of the combobox control should be fixed, in other words even though it remains looking like a combobox it acts like a read-only textbox.  This is currently "hard" to implement (without writing a custom control) but I believe that that is what abatts first request is.

3) As to his second point, this is salient. I believe what he (and I) would like is an event that signals that the Current property of a combobox has occurred. Currently (AFAIK) the only way to do this is by trapping KeyDown or KeyUp events in the combobox and writing a whole heap of code to "do it yourself". For example (under QT4), let's say that the user hits the "F" key using the above list. The inner cursor _has_ changed, but there is no way to detect this until something invokes the "Activated" event, such as the user hits Tab or clicks on another control in the UI (and there are problems with this, believe me). However, I can see problems with trying to trap the first "hit" in the search feature, say the list contains "Peas" and "Peaches". When the user hits "P" then, since there are more than one possible selections in the list, then the requested event should not be signalled. Similarly, with subsequent key presses on  "e" and "a" the event should not be signalled. What "should" happen is that, on the "P" press the dropdown list should appear and the interim selection should be positioned on "Peaches" (assuming that the combobox list Sorted property is true), Again while the "ea" key sequence is entered, the interim selection should not change. When the user finally presses the "s" key then we have a resolved selection, i.e. there is only one possible selection in the list that matches the "search string". Then the changed event should be signalled.  Of course, given that the search feature only works in QT4 then this whole point does not apply to the other GUIs.

4) Strangely, call it serendipity or whatever, I have been fighting with all the recently posted combobox "issues" for the last 2 moths or so. One thing that I have noticed is that the combobox source code seems be implemented in gambas3 quite differently from the other "common" controls. It seems to me to be somewhere inside the interpreter "libs" directory rather than in either gb.gui/gb.qt4/etc or even in the recent gui components.  I don't know if that is pertinent but it sure "looks" (to me) to be a rather different kettle of fish to other common controls. Perhaps there is a reason. I don't know.

5) "ReadOnly locks Event and default property allows to edit ComboBox.Text.\n???????" Hmm, yes, but. "default property allows to edit Combox" I read as "if ReadOnly is false, which is the default value, it renders the combobox as a pseudo-enhanced-textbox where the user can either enter whatever value they desire or select a "known" value from the dropdown list (after first activating it).  Some of us expect that a "default" combobox should render a "constrained-text-based-selector-with-advanced-searching-feature", and only if the developer should wish to allow the user to enter an entirely "new" answer to the prompt should it allow unconstrained text entry. Other views may differ, so lets talk about it.
As to "ReadOnly locks Event" I too am in the same position as Fabien, abbat could you please explain further?

5) Finally, and this may not be "on topic" so let me know if I should create a new thread.  Recent changes seem to have affected how focus transitions are handled by the interpreter/control components. Setting the "NoTabFocus" property of a control no longer seems to work as it did prior to rev 6290.  No, this is really a different topic.  So unless anyone has some quick comment I'll not try to steal abbat's thread.

regards
-- 
B Bruen <bbruen at ...2308...>