Strange !SrcEdit redraw issue when moved/resized by another WIMP task

I’m writing a program to make a tab bar that can be used to organise windows belonging to other applications (to make programming more convenient) and it almost works, except that the window redrawing for !SrcEdit does not work correctly. I’ve made a short (1:16) video to demonstrate the issue, as it is quite difficult to describe:

https://youtu.be/NtCoiiMF3HA

To add a window to the tab bar, you click on the green LED and drag the window over the tab bar. When it has recognised the window is there, the LED turns yellow for 1 second, so you have time to let go of it cleanly, and then it turns green again and the window is re-opened below the tab bar (and resized). The inactive windows are kept hidden behind the background.

If I add !Draw windows, or a window belonging to an application I have written, the redrawing works fine, but with !SrcEdit, the redraw is incomplete. If I scroll up and down, it starts redrawing correctly, unless I move the tab bar (which re-opens the !SrcEdit window again). It seems to be using screen position information from when it was previously open when redrawing.

In short, I think there is something I don’t understand about changing window parameters using Wimp_OpenWindow. I had assumed that any alteration (e.g. moving the window using the title bar, or resizing it using the resize button is equivalent to calling Wimp_OpenWindow, but they seem to have different behaviour for my program.

This is a shame as !SrcEdit is the one program where I really need this to work! ;o)

There is something distinctly awry with SrcEdit – often I will search in a file and be presented with some half-redrawn screen containing gash data. Scrolling fixes it. Does Edit work OK?

No, Edit does pretty much the same thing. I was wondering whether it has some clever efficient redrawing code that is storing some state information that isn’t getting updated somehow.

Best to send it an Open_Window_Request message though, so it can vet what you’re asking for. If you need to check where it actually ends up, I guess you could schedule a null event to check then.

In ye olden days, calling SWI Wimp_OpenWindow on another task’s windows used to error, don’t know if it still does.

Thanks, that explains it perfectly! SWI Wimp_OpenWindow doesn’t return an error in RISC_OSLIB when applied to another WIMP task, perhaps it should, but I suppose it allows some optimisations for WIMP tasks that are very closely coupled.

Many thanks again Stuart, it is all working perfectly now. I think I understand the mechanism a lot better now as well, which was at least half of the aim!

Sadly we failed BITD to supply Welcome applications that were simple enough to demonstrate the How-Tos and Gotchas of RISC OS Wimp programming – too much stuff added in.

I suspect writing WIMP tasks that messed about with other WIMP tasks would be beyond the scope of Welcome applications! I’m enjoying learning how to program RISC OS after 30+ years (I think I got my Archimedes A410/1 back in the late 80’s)! This is my first actually useful WIMP application, I think even in it’s current state it will make writing the IDE rather easier by keeping all of the source files under control.

I suspect writing WIMP tasks that messed about with other WIMP tasks would be beyond the scope of Welcome applications!

I’m fairly sure that Madness was cited by Acorn as an example of how to do exactly what you’re doing… :-)

True, unfortunately I don’t speak BASIC and I’m not sure I understood it! It is where I got the idea for finding the window handles by iterating through the window stack though.

BTW I found your series on WIMP programming in C very useful – much appreciated.

In case it’s any help, this project is written in C and moves windows around.

Thanks Julie, I’ll have a look at that, it looks like a useful program as well.

In ye olden days, calling SWI Wimp_OpenWindow on another task’s windows used to error, don’t know if it still does.

I have a vague recollection that this changed when the nested window manager was introduced. Presumably to allow one application to nest inside another applications window.

I have a vague recollection that this changed when the nested window manager was introduced.

Just for completeness, it was. I’ve just stumbled across this in the Nested Window Manager Functional Specification:

Under previous Wimps, the window handle at R1+0 had to be owned by the task calling Wimp_OpenWindow. Because a child window need not belong to the same task as its parent, this restriction has now been lifted; this is the case even for the non-extended form (R2 not equal to the magic word “TASK”).