I maintain an xplatform macOS/Windows desktop app that’s making use of my own helper classes, built around ShellMBS inside which my helpers are running and communicating.
Everything works nicely, and on macOS no problems at all.
The Windows part shows some weird behaviour I cannot explain:
There is a setup window for creating/modifying the helpers. It has a normal cancel button. Which cannot be clicked on Windows, but will react to ESC. It can be clicked normally on macOS. There is no control lying above it, and Windows will show a reaction when the mouse cursor hovers above it, but no Pressed event when clicked.
And then, unlike macOS, it can happen that repeatedly opening/closing the edit window will sometimes cause Windows to show the spinning cursor, after which the app will crash without further notice and without any exception handling firing. Nothing in DebugView, and if run in debug mode, the remote connection from Mac will still exist after I kill the remains of the app in Windows Task Manager.
Any ideas what might be causing one or both of the issues?
Or an idea how to debug something that creates no Xojo-catchable exception?
What is the class of this control?
Can you reach it with the keyboard (TAB YEY), if yes, it responds to the enter key when focused?
Are you using the UnhandledException Event of the Application ? If not, put something like this in there
If error <> Nil Then
Var type As String = Introspection.GetType(error).Name
MessageBox(type + EndOfLine + EndOfLine + Join(error.Stack, EndOfLine))
End If
This might be a issue where DoEvents is needed. DoEvents is really important on Windows. DoEvents often causes issues on other operating systems, so maybe put DoEvents in-between an #if targetwindows command.
Windows run every program in a tight loop at the operating system level. DoEvents allow refreshing of all programs and devices, such as the mouse, buttons, etc.
When I program games on Windows, I make a custom DoEvents in declares to allow the operating system to update.
Edit: I usually only use one DoEvents per program. It is usually after alot of redrawing or some type of GUI update.
Yes. But that does not change anything.
Things are even getting weirder: When I open the (modal, non-implicit) Edit Window in Edit mode (which means I make the built-in helper copy the settings from a helper in main window), the Cancel Button behaves normally.
When I open it to create a new task, CancelButton will react in the mentioned way.
The erratic crashes stay the same. On Windows, not on macOS.
Thanks for the hint, but no. Edit window is modal, and it can interact with main window. But it does not open any new window.
First of all, a huge thanks to all of you dropping in here! I am a bit overwhelmed by the number of suggestions.
A few answers so far:
It closes when I hit the cross, and when I hit ESC like before.
In edit mode, the respective “worker” is stopped before edit window is opened.
Edit Window itself is closed when the internal helper has quit.
Main window has platform pragmas, but not edit window. Basically on macOs main window has a unified title and builds a Dock menu, Windows gets a slightly different size and a tray icon.
Yes. I tried it as sheet and modal window.
Yes. It even reacts to mouse hover correctly.
No. Not when I simply click it.
Maybe I should’ve a few more explanations. The app is no secret, it‘s even a free software for customers of my client. Its purpose is to watch user-specified folders for new files, check them for eligibility (can be file name extension and/or a RegEx match in their filename) and upload them to a server.
Much more bothering than the unclickable button are the random crashes which will keep the tasks running in background (and keep the remote debugger connection to the IDE, although I cannot break into the debugger anymore, until the remnants are killed with Task Manager)
I guess I’ll have to refactor the window thoroughly. Sigh. It was of course the first window I started with and used it a 1000 times for testing. But I cannot say exactly when the problems started.
Guess we’ve all been at a similar stage from time to time …
Not really. In both modes Cancelbutton is disabled on startup and gets enabled when the task has initialized. Difference is that in new mode task is not fully set up, in edit mode it copies the JSON setup data from the original task. Does not make any difference if I keep CancelButton enabled from the beginning.
Xojo version is 2022r1.1
And yes, I tested builds on my Windows VM as well. No difference.
So if you drop in another button that enables the cancel button and click it does that make the button work (comment out the code that enables it elsewhere)?
I’ll try to refactor a few things. First I need to give that **** Magic Mouse a new charge. And try to find some concentration. It‘s getting really hot here in my office already; weather forecast tells me the next days will be bad for work.
Thanks a lot again! I’ll return after refactoring.
