I’ve gotten bit by this one, also, so I’ve added it to my Top Cases.
When I use the “Go to” menu item to switch to a method I do so to edit the code, not the method’s name. That is where my attention is and I expect the focus to be there. Having the method name get the focus, and the resulting possible disastrous name changing effect, is a really bad user experience when it goes unnoticed and many changes later you try to run the app and it won’t compile. And if you’re like me and frequently save before running, you’d better hope you have a backup of the project.
Sounds like a good idea, though the problem for me is, I always expect (as has been suggested it ought to be) that when I execute “Go to…,” the focus will be in the code editor, not the method name Combobox.
As far as my experience goes, it happens whenever the method is on any class object, not just a window.
[quote=108358:@Greg O’Lone]So the problem is that the Method name field is a combo box, and that is so we can show a list of methods which you are allowed to override. Then on top of this the method name is selected when you go there. Got it.
That’s going to be a tough one to crack because technically it’s doing exactly what the field was designed to do… changing to the next selection when you scroll the mousewheel.[/quote]
What about returning True in the ComboBox MouseWheel when TargetWin32 ?
I think that the better solution is to put the focus in the Code Editor. I would guess that the chances of executing “Go to…” for purposes of wanting to change the method name are vanishingly small. At least in my case, 99.99% of the time I use that function, it is either to examine the code, or to edit it. In either case, having focus in the code editor is far preferable to having it in the combobox, especially since it’s proved to be a time bomb for at least a number of us.
I don’t think I have ever experienced this bug in my entire experience of using Xojo/Real Studio. I have always used Windows so maybe some of the engineers at Xojo do not experience this bug.
To be precise, I don’t think it’s a bug - just a really, really, REALLY annoying, but as-designed behavior. The design is that the “Got To …” functionality displays the method in question and sets the focus on the method name field. Since that control is a Combobox, on Windows, it is expected (even desirable) behavior for a move of the scroll wheel to change the method name to something in the list.
The problem for me, and apparently at least some others, is that this is not the behavior I intuitively expect.
(Combobox controls on the Mac do not normally respond to scroll wheel changes, so it doesn’t affect the Mac IDE.)
Since today is my day “off” I spent part of it looking into this
We do return true in the scroll wheel event so there’ something odd there - it SHOULD be ignored already
The focus should be in the code editor but isn’t - that I can do something about
So there seems to be two “bugs”
the scroll wheel is supposed to be ignored but isn’t (this is relevant since constants 7 other items that do NOT have code could still be affected by Goto Location that cannot put the focus IN a code editor
when the focus CAN be put in a code editor it should be
Sounds about right to those involved here ?
See <https://xojo.com/issue/34358>
Which is related to but still not the cause or fix for Ramons initial problem
If you put the focus in the combo box we sill should be ignoring the scroll wheel but we’re not for some reason (that I have not discerned yet) It should only change if you click & actually select an item.
[quote=108594:@Norman Palardy]So there seems to be two “bugs”
the scroll wheel is supposed to be ignored but isn’t (this is relevant since constants 7 other items that do NOT have code could still be affected by Goto Location that cannot put the focus IN a code editor
when the focus CAN be put in a code editor it should be
Sounds about right to those involved here ?
[/quote]
That will definitely improve a lot of the issues described in this thread
The focus issue I checked in a change for a later version.
The scroll wheel I still need to look at separately as it should already be ignored but isn’t.
[quote=108714:@Norman Palardy]The focus issue I checked in a change for a later version.
The scroll wheel I still need to look at separately as it should already be ignored but isn’t.[/quote]
Norman, a few quick tests indicate the following (on Windows):
if a combobox gets the focus, the scroll wheel is active. Returning True in the mousewheel event is ignored (or perhaps the event isn’t firing.
Once the combobox is clicked in, the scroll wheel is ignored if the event returns true.
The test was to create a combobox with a few entries and a pushbutton that does a Combobox1.SetFocus. Without moving the mouse to the combobox, moving the mouse wheel scrolls the combobox list regardless of returning True in the MouseWheel event.
From my duplication of Dale’s test, it appears that having Focus and being Activated are two different states for a Combobox. Maybe the Edit status is a point to look at?
[quote=108749:@Norman Palardy]I kid you not when I say there is literally the following code in the Combobox MouseWheel event
#if TargetWin32
return true #endif
yet we still get other events changing the text - there IS something else going on in the IDE and we’re looking into it[/quote]
A quick test under Windows shows that the MouseWheel event is not triggered until the menu of the ComboBox is pulled. So in effect when the ComboBox just gets the focus and the text is selected as in a TextField, it goes through all the menu options with the wheel, but the corresponding event does not fire. Here goes the return True
I do not see how you can then suppress the content change when the mouse wheel is moved…
I don’t know if this helps but a PopupMenu does the same thing as the ComboBox (see my above test but with a PopupMenu). This is logical since a ComboBox inherits from the PopupMenu class. With the PopupMenu, the MouseWheel event does not fire unless the menu has been clicked on, but the menu scrolls as long as it has the focus.
Since both of these controls inherit from the RectControl it must be adjudged that they are operating properly, if a bit confusingly. Still, to me it indicates that the original problem is not with the ComboBox but with the assignment of the focus after the ‘method goto’ function. Setting the cursor focus to the code area will eliminate the problem without breaking anything else (hopefully).
there are definitely 2 issues - related and they both contribute to the problem as I noted
fixing one (that the code doesn’t have focus) lessens but doesn’t eliminate the problem since if you click the combo box you can then just scroll & the name will change.
And we really did put code in there to make it NOT do this - we did kind of think this would be a problem.
But there is a bug in the combo box that is subverting our efforts.
I think william has already looked into it and maybe even identified the culprit - I haven’t looked at the case recently
I just want to chime in here with a small video showing that there are some things fighting over the combobox: http://screencast.com/t/AqEeiiws
Note: I am using a Logitech Anywhere MX mouse, the one with the “free-wheeling” mouse-while that spins like h*ll when you flick it. Flickering only appears when it is in the free-wheel setting (toggeled by physically pressing the scroll-wheel). With the wheel in “old-style” mode (with notches), no flickering happens and I don’t change the name by accident.
Too much input in the event-handlers causing some spill?
I am not using the Logitech mouse drivers as they cause similar problems in Outlook 2013. Running Win 7 SP1 64-bit.
