WinEd 3.23

Investigating the crashiness of WinEd on modern systems has been on my to-do list for a while now, and having recently had more time on my hands than usual, I’ve finally got around to it.

It’s been an interesting journey, but I’m pleased to report that the code in SVN will finally, after around a decade, build to a working application. I’d like to thank Adam Richardson for his prompt responses to my questions, even if he was only able to confirm that there might be some gaps in the DeskLib library that WinEd uses. Thank you, too, to the denizens of csa.programmer and the GCCSDK mailing list, whose help in squashing some compiler errors generated by WinEd’s code was invaluable.

I’ve taken the most recent code, which was 3.21a, and with one change, have turned it into a new version 3.23. I’ve skipped 3.22a because there’s some suggestion that a version with this number might have made it out into the wild – although the source code appears to have been lost (if anyone knows different, let me know). I don’t know the exact status of 3.21a, but it seems stable in use – if there are issues, I will try to investigate.

The change is to fix a significant ZeroPain issue in the menu handling, which would either crash the application or generate hundreds of log entries whenever a menu tree was closed on a modern system.

Whilst I look into better ways to make the application available (including how to get its package updated), a ready-built copy can be downloaded from my website – the source for 3.23 is in SVN

There have been attempts to do similar apps to handle ‘menu’ items.
Could ‘menu’ items be added to the templates files and handled by the template editors?

Colin – you’ve “sort of” just described the Toolbox, which does just that (plus rather more).

If you start modifying what a Templates file contains, you basically break compatibility with every version of the OS, and since there isn’t really an "official"* template editor, you’d need to update each 3rd party one as well. I suppose you could concoct some sort of support module to handle a new file format, but then you’d end up with something like Computer Concepts’ ABI as used by Impression/Artworks. Not convinced it’d really offer much more than the Toolbox approach.

• Acorn gave us FormEd, which is massively dated, and I don’t even know if it is available via ROOL any more. More recently (mid 90s) they gave use WinEdit, which I rather like, but it is a little quirky, and has a bad habit of corrupting templates files under certain situations (or making them only compatible with itself). I use it, but at certain points, I’ve found that for some of my programs I’ve had to rebuild them in WinEd or TemplEd. I’ve never quite figured out the trigger though.

A new version of WinEd is certainly more than welcomed – thanks Steve :)

If you start modifying what a Templates file contains, you basically break compatibility with every version of the OS

That’s not quite true¹. The Template file format is actually fairly far-sighted, and consists of typed blocks. Window Templates are block type 1, and for other types, Wimp_LoadTemplate will load the block into memory and leave the application to do whatever it likes with it.

You would presumably need to allocate a new block type from ROOL for menus, although I’m a little unsold on the benefit at this point in RISC OS’s evolution. I have considered it, because with the benefit of hindsight, it’s probably how MenuGen should have been implemented.

Not convinced it’d really offer much more than the Toolbox approach.

Except for applications which aren’t Toolbox apps… Rewriting the lot from scratch to get templated menus is a little drastic, I feel. :)

¹ Although I thought the same until recently, when I started looking at what the Wimp actually does with Template files (for some completely unrelated reason).

Could ‘menu’ items be added to the templates files and handled by the template editors?

Yes, although it’s probably a bit late now. Aside from anything else, a graphical editor for a binary format isn’t actually a great idea for something that isn’t as visual as a window design. You’re far better off using a textual markup format to hold the menu definitions, turning them into a binary blob at build time: that way, version control can track changes to the menus easily.

I’m perhaps a little biased, because all of my software uses MenuGen to do the menus. It takes a slightly icky “C-like” definition language¹ and builds something akin to a Template file from it. The Wimp_CreateMenu blocks are laid out in a data file with the indirected data alongside, and a loader (see SFLib or WimpLib for C and BASIC examples respectively²) pulls it into memory and runs through some linked lists of offsets to join everything together. Very much like what Wimp_LoadTemplate does for window templates, in fact.

As hinted at in my reply to Andrew, with the benefit of 20-20 hindsight, I’d probably have asked for a template block type for the data. As it is, the system uses a plain Data filetype. The user never sees the file, nor has to load it into anything, so I don’t see this as a problem.

¹ My file parsing skills have improved since the format was devised.

² The C routines can take advantage of menu names embedded in the file, in a similar way to how Wimp_LoadTemplate will look for a named template; the BASIC version is more primitive, as it hasn’t evolved for many years.

A new version of WinEd is certainly more than welcomed – thanks Steve :)

No problem; as noted to at least one other correspondent, the motivation was at least partly selfish as WinEd has been my template editor of choice for many years.

I’ve had a few more ZeroPain issues reported, so there might be more updates to follow.

Acorn gave us FormEd, which is massively dated, and I don’t even know if it is available via ROOL any more.

It’s in the Bonus Binaries download, along with WinEdit (which isn’t to be confused with WinEd).

Do not forget MessageTrans_MakeMenus for file-based menu definitions.

I’ve had a few more ZeroPain issues reported, so there might be more updates to follow.

Well, that didn’t take long. Thanks to Martin Avison for trying to break it!

To avoid running out of version numbers, I’ll switch to the same “SVN snapshot” approach that I use for my own software. At the time of writing, r67 is available from the same page on my website – whilst I’m thinking about this, it would be really helpful if other WinEd-using developers could give these releases a workout and report any crashes or ZeroPain logs that they get.

Do not forget MessageTrans_MakeMenus for file-based menu definitions.

Given that I was looking at that just the other day… What is the point of this SWI? :)

More seriously, unless I’ve misread the PRM, you need to set up both some of the menu block, and all of the MessageTrans block, then have the SWI fill in the missing bits of the former for you. Add in the fact that it uses variable-length, 0-terminated strings which cause the other data to shift around, and you’ve got something that’s quite nasty to work with.

If you’re making up a menu block using PROCs or function calls, I can’t help thinking that you’d be better off building the Wimp_CreateMenu block directly and calling MessageTrans_Lookup as you go. If you’re loading a pre-built block from disc, just hold the data file along with your Templates in a suitable place inside your Resources hierarchy.

I can’t help thinking that I must be missing something… so what is it? :)

Back to the original topic, and WinEd r73 is now available to download from my site. Compared to r67, it has a couple of smallish template tweaks, plus support for proper window scrolling (including taking into account the contents of the browser and stats windows) and extended scroll events (ie. scrollwheels).

Having upgraded my Linux system yesterday, it’s also been built using a new (to me) GCCSDK toolchain and libraries. There shouldn’t be any issues, but if anyone spots anything, let me know!

A quick follow-up to this, in that I’ve applied a couple of additional fixes to make WinEd r79. It fixes a possible buffer overrun in the logging code, and attempts to fix an oddity when moving multiple icons with the mouse and cursor keys together¹.

The latter could have broken other stuff in the dragging code, so feedback from any WinEd users who are willing to try the new build would be appreciated.

¹ When the icons were dropped at the end of the selection, they could jump away from the position of the end of the drag.

Found a little bug:-

1. Load template file
2. Modify (open a window and move it)
3. Click close on the templates
4. Choose Save in the Discard/Cancel/Save window
5. Left click the Save button on the Save As Window
6. The Save As window remains on screen, and clicking Save again gives a “No Templates to Save” error

Found a little bug

I can’t reproduce that, I’m afraid. With 3.20, 3.23 and r79, the Save As window seems to close (and the file gets saved) every time, as far as I can see. That seems to be true regardless of what other files are open at the time, as well as if Adjust is used to click Save.

PS. The changelog suggests that a similar-sounding bug¹ might have been fixed by Adam in 3.03. What version are you using?

¹ “Clicking on close icon of an unsaved browser opens save box, but doesn’t allow it to be used.”

Whilst I’m thinking about WinEd, there’s something that’s always annoyed me about the interface… I’d taken the view that I was wrong, because the behaviour is probably technically correct, until one of the first requests for fixes that came in to me was for exactly the same thing.

In the Edit Icon dialogue, the default action is Update, with Don’t Resize being an alternative. This means that pressing Return in the window results in the potentially destructive behaviour of resizing the icon to fit the text, even if it’s part of a carefully laid-out arrangement of icons. The lack of undo often makes this …irritating.

Whilst I can see why this makes sense in the context of ensuring that icon texts are always visible, I’ve long wanted to swap the Update and Don’t Resize buttons so that Update becomes the default action and changing the icon’s size and position is a deliberate act requiring a mouse click.

So far, based on my “extensive” research, two out of two cats would prefer to swap the default button over. Before I do it, though, what do other WinEd users think?

Have neither as the default button!

Sounds sensible to me, Steve. I wouldn’t expect it to apply any automatic transformations to the icon without my express say-so.

I assume it was set up this way so that larger text icons auto-resized to fit their contents, but if you’re carefully aligning icons etc, it is really annoying if the program starts messing with that when you go in to make minor changes.

However, if some users have muscle-memory, it may be counter-intuitive for them. But, I wonder how many people use template editors so regularly that they rely on muscle-memory in the way that users of Impression/Ovation/Techwriter/Fireworkz/Artworks would?

However, if some users have muscle-memory, it may be counter-intuitive for them. But, I wonder how many people use template editors so regularly that they rely on muscle-memory in the way that users of Impression/Ovation/Techwriter/Fireworkz/Artworks would?

It isn’t just muscle memory for WinEd, though. My muscle memory for RISC OS dialogue boxes is that Return applies the changes from the dialogue¹, but doing that in WinEd has unexpected consequences.

The change actually removes the non-standard behaviour, so I don’t think it’s dangerous as such. The problem is if anyone relied on WinEd fixing icon dimensions as a side effect of changing the icon data, as they could end up not correcting the size of small icons. That might be better resolved by adding some kind of “design check” functionality somewhere.

Have neither as the default button!

If I’m making the change, then the only options on offer are “swap the default”, or “no change”, I’m afraid. My muscle memory requires Return to do something in the dialogue. :-)

¹ Which is why O-Pro is annoying, as it uses the now dated “Ktar” effect instead of “Kta”. There’s actually a bug in the Style Guide here, though: in both the ROOL and Acorn editions, it describes the “Kta” behaviour in the text, but then states that a writable icon uses “Ktar” as its validation string.

There’s actually a bug in the Style Guide here, though: in both the ROOL and Acorn editions, it describes the “Kta” behaviour in the text, but then states that a writable icon uses “Ktar” as its validation string

That one had me scratching my head when I saw it a few weeks back – Kta surely has to be the current intent.

I’d plumb for Return to do nothing. Thanks for keeping going with WinEd. It’s my editor of choice for PipeDream’s templates.

Checked it again, and it is 3.23 (17 Jun 2020). Even does it with its own UK Templates file. Move the align window, close the template, save and the SaveAs stays open. This is on both a mini.m running RISC OS 5.27 (09-Jun-20) and a Pi 3B running RISC OS 5.27 (08-Jun-20).

This is on both a mini.m running RISC OS 5.27 (09-Jun-20) and a Pi 3B running RISC OS 5.27 (08-Jun-20).

It’s one of those, then; thanks! Doesn’t do it on a Titanium running 5.24 (16 April 18); does do it in a Beagleboard running 5.27 (16 July 20).

It appears that the file is being saved, but that the dialogue doesn’t close. However, it’s a transient box, and WinEd does call Wimp_CreateMenu with a pointer of -1. A click outside the box closes it as expected, and adding a second call to Wimp_CreateMenu also closes the box just fine.

WinEd uses the following code for all menu opening. The second comment, which isn’t mine, fills me with a certain amount of despair – although removing the bodge doesn’t seem to affect the problem.

void WinEd_CreateMenu(menu_ptr m, int x, int y)
{
  /* Belt & Braces, to avoid any problems with DeskLib. Ensure that all attempts to close
     the menu tree use "(menu_ptr) -1", and pass X and Y as 0,0. This will prevent
     DeskLib from trying to interpret the NULL pointer if Y is -1. */
  if (m == (menu_ptr) -1 || m == NULL) {
    m = (menu_ptr) -1;
    x = 0;
    y = 0;
  }
  /* This is a bodge to avoid mysterious problems with receiving menusdeleted messages which
     result in the overwrite-warning dialogue getting closed but other problems arising when
     the overwrite_warn transient is closed but the close-handler (overwrite_checkanswer) isn't
     called - e.g. when the window closes as a result of an external mouse click */
  if ((!overwrite_warn_open) || !Window_IsOpen(overwrite_warn))
  {
    event_pollblock event;

    event.type = event_USERMESSAGE;
    event.data.message.header.size = sizeof(message_header);
    event.data.message.header.sender = event_taskhandle;
    event.data.message.header.myref = event.data.message.header.yourref = 0;
    event.data.message.header.action = message_MENUSDELETED;
    Event_Process(&event);
    Menu_Show(m, x, y);
  }
  overwrite_warn_open = FALSE;
}

The call to Menu_Show() is part of DeskLib, and just shuffles the coordinates a bit before calling Wimp_CreateMenu in the usual way.

Before I spend more time looking into this, does anyone know offhand if anything has changes with regards to menu handling in 5.25 and 5.27 which might affect this?

Confirming what you’ve found; my Iyonix has 5.24 in flash, and doesn’t leave SaveAs open. Softloading 5.27 does leave it open. I’ve not seen this with any other apps so far though.

Confirming what you’ve found; my Iyonix has 5.24 in flash, and doesn’t leave SaveAs open. Softloading 5.27 does leave it open. I’ve not seen this with any other apps so far though.

I think I’m getting closer to this. It appears to happen if WinEd’s unsaved browser has input focus when it’s closed; if it doesn’t (eg. make it unsaved, then click in a filer window to give that focus and finally click close on the WinEd browser), then the SaveAs closes fine.

It looks as if it could be something to do with the Wimp trying (and failing) to return the caret back to the now-closed WinEd browser window after the menu closes. Does anyone know if anything has changed in this area since 5.24?

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

I can reproduce the bug here (RPCEmu, 5.27 from May). 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. It’s a long shot, but could there be any link to this issue, which I never got to the bottom of?

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?

One other thing that I have trouble with using WinEd is the feature where an Adjust double-click minimises an icon to its contents…

I think it would be good if it just issued a warning about reduction to absurd size, allowing you to carry on if that’s what you really wanted, or cancel otherwise