My app uses tabs (buttons) to switch between different activities. One may wish to close a tab, and there are several ways to do that, including a main menu item which has cmd/ctrl-w as its shortcut.
Now on macOS/Linux, all these ways, including the shortcut, work as expected, but on Win-10, all work except the ctrl-w shortcut. If I use that one, then the app goes into a loop and may well get a StackOverflow exception (but not always). Even the debugger gets hosed and stepping through, I reach this statement:
MainWindow.MainPagePanel.SelectedPanelIndex = 1
at which the debugger gives up and goes blank.
All these various ways of closing a tab boil down to a call to the same method. It seems to me, therefore, that as the only difference is that a possibly common shortcut causes the problem, I wondered if it had any special extra meaning in WIndows (such as “Close the app’s window” or similar). Checking the main menu there is only the one instance of that shorrtcut, and I couldn’t see anything obvious in the Windows Settings.
I googled for “ctrl+W” on Windows 10, and I found out what you said, by default closes a Tab, the application0lication, etc. Unless the shortcut is redefined in an application, which is the case for Office 365 applications.
Is there an application in the background, like a screen capture utility or keyboard extender, that would redefine this shortcut ? Instead of stepping in te debugger, did you try to trace your application ?
You could try with setting the shortcut to ctrl-shift-W or no shortcut at all and attempt to reproduce the bug (try ctrl-w when there’s no shortcut at all (if it also hangs, you know it’s a special shortcut from Windows), or try ctrl-shift-w which shouldn’t fail if ctrl-w is the only problematic shortcut).
Using another letter than w (such as j) does not alter the behaviour
The shortcut actually works on WIndows except where the tab represents a panel on the PagePanel which has an HTMLViewer on it, and the focus is inside that viewer. If the focus is inside one of the other controls on that panel, then the shortcut works as expected.
The HTMLViewer contains the Quill editor, which is 12k lines of opaque javascript. I have to see if I can make anything of that.
Sometimes I wonder why I bother trying to make this stuff work on all Desktop platforms. There’s macOS, where it all works, and then a pair of weak sisters. Frustrating really. And then there’s 2024r1, where my app falls to bits on Linux.
I wonder if an HTMLViewer works the same as a Web Browser, which could explain (partly ?) the behaviour. Have you tried with a HTMLViewer that does not contain the Quill editor ? You could rule it out, or not.
I did try to replace the quill editor with some simple html that included a construct so I could have an input field, and then let that have focus before trying ctrl-w. Not succeeding in having that simple html appear, yet. There is a lot of interaction between the HTMLViewer and the Xojo side, so I’m not yet quite sure what is happening. ctrl-w works with my “empty” HTMLViewer, however.
Here, the handler is empty but I can (and have) put some js in there to alter the document.title and have picked that up on the Xojo side as expected under macOS/Linux. I’ll do some more testing.
Looking through the quill source for .binding does show it’s already binding some characters such as ctrl-z and so on for its own purposes.
Seems the way to go, but you should really use executeInXojo() in the JS and the event JavaScriptRequest() in the DesktopHTMLViewer instead of trying tricks with Title events, I used this trick too in the past (intercomm simulation with Title) and had some headaches in edge cases until Xojo introduction of proper Xojo<->Html intercomm methods and events. So I refactored all that and it was really good.
I would, but this method does not exist under Linux (or the event does not fire). I discovered this last year. See my #73196, and also #76066 more recently created by @Anthony_G_Cyphers.
That was when I simplified my app somewhat by abandoning my websocket server that I was using to communicate back and forth between Xojo and teh HTMLViewer.
It was reproducible as William reproduced it while we were talking. I didn’t get a notification for Robin’s message there for whatever reason.
There are issues with HTMLViewer on Linux that need attention. One of my projects causes the WebKit renderer to crash in the background and I’m still trying to figure out why.
On reading further in the Quill docs, it seems that the binding I posted earlier acts after any internal Quill binding, but that there is a formulation which allows such a binding to precede any Quill binding. I’ve now employed that and it makes not a scrap of difference - under Windows the app goes into a loop, which is either inside the IDE or inside the HTNLViewer’s Quill javascript.
.
