I know that we use to think that bugs that concern us are the most important.
I’ve tried for long no to think in this direction, but I must admit that sometimes it is very difficult to stay impassible.
That’s how I feel about case #33681. I’ve documented it with a video. But although I hoped it would be solved in release 2014r2, my hopes vanished.
I can not understand how Xojo engineers can work with this bug in Windows.
(Supposing that there is any engineer working on a real PC, not virtual. If there is, please tell me how you do it without driving crazy.)
It’s totally unacceptable that when you press the green arrow (Run), you get a message saying that some methods don’t exist.
And not only names are changed, also parameters.
THIS IS A VERY IMPORTANT BUG. And not because it concerns me, it concerns all Windows users.
I hope and wish that Xojo doesn’t take it differently because concerns ONLY Windows users.
Thank you for your interest.
The problem is very easy (I suppose that the solution is not )
When you right click on a method’s name you get the “Go to Methodname”.
If you click there you go to the method.
If the method is in a Window (if it is in a Module, no problem) the name of the method is selected at the inspector (why???)
If you move the mouse wheel the name of the method changes (and accordingly the parameters) and remains. Although you don’t press enter or anything like this.
If you don’t notice this change >>>> CHAOS in your program!
Thank you for your interest.
The problem is very easy (I suppose that the solution is not )
When you right click on a method’s name you get the “Go to Methodname”.
If you click there you go to the method.
If the method is in a Window (if it is in a Module, no problem) the name of the method is selected at the inspector (why???)
If you move the mouse wheel the name of the method changes (and accordingly the parameters) and remains. Although you don’t press enter or anything like this.
If you don’t notice this change >>>> CHAOS in your program![/quote]
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.
Should’nt be the focus in the text area, instead of the combo box? If the focus is on the text area (development code) than the mouse scrol has the expected behaviour.
I also experience this occasionally, but not often enough to figure out what was causing it. Thank you Ramon for figuring out what causes this nerve wracking behavior.
[quote=108358:@Greg O’Lone]Ah. Now we’re getting somewhere.
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]
But in any case, the Method Name should revert to original if one presses ESC Key within the ComboBox. Plus, it sould not change the Parameters just by Scrolling with the MouseWheel within the ComboBox (or revert those changes also if we press the ESC Key), please.
That’s true only if you notice it at the very moment.
But if you edit the program in different methods, you can get several methods with name changed.
And ESC doesn’t revert to the original name. You have to use menu Edit|Unod Declaration Change.
I can not reproduce now the change of parameters. So I can not be sure how it happened. May be it was my paranoia.
A solution could be to limit the combobox response to the mouse wheel only when the mouse is over this combo, or even better disable it for this specific instance of the combobox.
(only for the windows IDE)
A huge bug that makes development a pain and has existed and been in feedback since 2011. When two apps are being developed (1 web app and 1 desktop app), you must run the desktop app before running the web app. If a web app is already running, the desktop GUI will fail to appear. This is a pain when you’re creating web services that interact with desktop apps (ie instant messenger). Especially when the webapp works perfect and you need to tweek the desktop app. It was known this was a mutex issue then. The mutex issue has now migrated over to compiled applications. If an application is compiled into an exe with an icon, then you open 2 instances of the exe, the second application will have a question mark as an icon.
OpenGL also crashes desktop application. (Add openglsurface to an application [even with no code] and attempt to run the application. If compiled it will build but the exe will crash).
This occurs in real and virtual PC’s. It’s not unique to real PC’s.
Personally, on Windows, I don’t touch the mouse wheel when the method name has focus.
The truly odd thing is that we have code in the mouse wheel event to make it so the mouse wheel on Windows does not, or should not, cause the combobox to scroll. It’s obviously not working as intended.
FWIW when you select a method from the list you are not selecting JUST the name - you are selecting one of the possible methods that any of the supers declare to implement so you’re actually selecting a full signature - name parameters and return type
This is true even in the old IDE.
This is quite the coincidence as I was just caught by this exact problem this morning in 14r2. I agree with Torsten’s comment that the focus should be in the textfield, not the combo box. That was alleviate this.
[quote=108451:@Norman Palardy]Personally, on Windows, I don’t touch the mouse wheel when the method name has focus.
[/quote]
Unfortunately, some of us use very sensitive mice and the scroll wheel is very “touchy”. All I need to do is brush mine (HP mouse) and a scroll event occurs.
)