WinEd 3.23

Using git bisect I have traced the triggering change in RISC OS to commit 9cc627ac of Wimp: Clipboard caret/task fixes which was committed on 18th December 2019.

Using git bisect I have traced the triggering change in RISC OS to commit 9cc627ac of Wimp: Clipboard caret/task fixes which was committed on 18th December 2019.

Thanks for tracing that! The description of that commit seems to fit.

This appears to be a side effect of the Wimp’s automatic handling of writable icons in transient dialogue boxes. Open a transient window with a writable icon (or just a writable menu field), and the Wimp will move the caret into it. When the window closes, the Wimp will put the caret back where it came from. If the window no longer exists, such as if the application has just closed and deleted it as a result of the menu action, then Wimp_CreateMenu throws an “Illegal Window Handle” error before it gets around to destroying the menu tree. DeskLib calls the X form of the SWI, and doesn’t pass the error back to the application.

I still can’t explain why I’m not seeing the issue on 5.24, as a simple BASIC test case seems to trigger the same error. But, re-writing WinEd to log the error from Wimp_CreateMenu doesn’t show it being raised.

The fix in WinEd appears to be to swap the order of the actions: first close the Save As dialogue, then deal with the file destruction. This is why the problem doesn’t show up on drag saves: a different bit of code does that, and already had the calls in the reversed order.

The input focus on the browser doesn’t seem to be necessary to trigger it. If I open a file, then open a window, move it (so that the window has the input focus, and the browser window doesn’t), then click Close on the browser, I get the persistent SaveAs. If I close the window first, giving the browser the focus back, then click on a Filer window to lose that focus, then the SaveAs dialogue works as intended.

True, but the key point is simply that prior to starting the close-and-save sequence, the focus was in a window belonging to the file within WinEd – that is, one which is about to get closed and deleted by the operation.

It’s a long shot, but could there be any link to this issue, which I never got to the bottom of?

Was your dialogue box a transient one? If so, it seems likely.

I’m a little nonplussed by this one, to be honest. The Wimp is technically correct to raise an “Illegal Window Handle” error here, but since it’s the one doing the caret shuffling, wouldn’t it be better to catch the error, swallow it and then destroy the menu tree as requested? Moving the caret is somewhat incidental to the reason why things usually call Wimp_CreateMenu in the first place, and they probably still want the menu tree closed.

One other thing that I have trouble with using WinEd is the feature where an Adjust double-click minimises an icon to its contents. As you have to use Adjust to resize the icon, if you accidentally double-click rather than hold down to drag (very possible on RPCEmu, which seems to occasionally get the mouse-clicks a bit wrong), and the icon has no contents (eg, it’s a frame icon), you can get the icon minimising so small that it can disappear entirely, or be laborious to drag back to full size. Is there any chance of modifying this behaviour? Maybe never auto-shrink to 0? Or just make the feature on/off configurable?

Resizing needs some thought, as has been discussed over in csa.apps in the past week or two (broadly, that the ability to change “Don’t Resize” is only really necessary because resizing is often less than optimal).

It would certainly make sense to do something like what you suggest. For now, I’m trying to fix the actual bugs and low-hanging fruit in the UI stakes, with a view to releasing 3.25. People then have a version which can be used on modern systems (which was my reason for picking this up), while I consider breaking stuff like the resize code.

Thanks for the updated WinEd – great to see it being maintained.

That was pretty much my thinking, but furlough seemed like the time to stop hoping that someone else would do it. :-)

So, with the Save As problem fixed, WinEd r101 is available to download from my website.

I’m viewing this as a candidate for releasing as version 3.25, unless anyone can find any more serious bugs. There are still some bits of undesirable behaviour (see !WinEd.Resources.UK.Features for things that are known about), but they’re all likely to require significant internal work and a usable, stable release seems like a good idea first.

Let’s hope R101 doesn’t go down in flames! Thanks Steve

Moved, in hindsight, to a more appropriate place.