Wimp bug, not sure if it’s still in RO5

I’ve just had a frustrating time tracking down a bug in the Wimp.

I had a window that potentially changed size when clicked in. When clicked, I closed the window, resized it, then reopened it. I can’t remember now why I thought that was a good idea but you would think it was harmless. The close and resize were ok, it was the reopen that triggered the bug.

The symptom was that it appeared that the mouse click was registering twice – once to cause the above and then immediately again as a second click. This second phantom click seemed to be triggered by the OpenWindow. I finally worked out what it was.

The window’s click type is 6 – ClickDrag. So clicking Select returns 4, and dragging returns 64, but I wasn’t dragging. My code was resizing the window to be one textline shorter, and the pointer was at the bottom of the window, so the result of the resize is that the pointer would now be over the horizontal scrollbar.

This seems to fool the Wimp into thinking the pointer has moved (from inside to outside the window), and hence must have been a drag, so it immediately returns with a click type of 64.

Edit: Yes, the bug is present in RO5.

I think you can get the same effect when a click causes the application to report an error, because the mouse moves to inside the error box. You get it after the user has responded to the error and the box has disappeared.

We have code in our library to suppress response to this spurious event. That probably means we’ll never spot when the problem is finally fixed.

There are all sorts of funny things in the Wimp with regard to mouse handling. Some I remember of hands are:
- in older versions of DigitalCD, try initiating a drag when a playlist window that has not yet the focus. DigitalCD received the simple click, sets the focus, but does not get the drag click. Since it is just a selectable list, I modified the code to initiate the drag when receiving the simple click.
- while dragging a drag box, get an other application to generate an error box. The dragging is cancelled but there is no event than can signal this, so I added some code to check the mouse state while dragging and abort the dragging if none of the mouse button is pressed.
- In the DigitalCD player window, the close button is not a furniture of the window but an icon and IIRC when the use clicks on this icon an extra mouse click event was received after I already closed the window.

try initiating a drag when a playlist window that has not yet the focus.

I wonder how the Filer used to handle that?

It steals the focus now, since there are potential keypresses… but did it always claim focus?

there is no event than can signal this,

Yeah, the Wimp is missing quite a number of event messages. There’s no notification, for example…

• if the alphabet/country/territory is changed
• if the user connects/disconnects the USB drive (or, for that matter, any USB device)
• change of timezone (or large-step change of time)
• files closed (by *Close or *Shut)
• any others?

There are Service Calls and such, but we’re talking about USER mode Wimp applications so they’d need messages rather than being expected to try to hook into the OS (surely that’s the Wimp’s job?).

<thinking type = “out loud”>
There doesn’t seem to be any notification for an explicit change of country or alphabet (WTF?). Instead, one should look out for Service_International 5 which requests the country provider (usually the International module) to redefine characters to match the newly chosen alphabet.
Territory, at least, issues a Service Call when a territory starts up.

Territory makes a Service Call (&81080) when changing the offset due to entering/leaving summer time, or manual changes to timezone or DST setting.

Simplest way to detect a USB drive (rather than trying to work out USB descriptors) is to simply look out for FS starting/dying. It’ll catch RAMFS too, but that may not be a bad thing.
For other USB devices, just read the Class bytes and Vendor/Product/Device IDs. If the application needs more, it can enumerate for itself.

It doesn't appear to be possible to get into the *Close process to determine what file handles are actually closed. It looks like it just cycles through the open handles closing them.
This is an issue as *Close closes all files on the current filing system, not all files everywhere.
A potenially bigger issues is that the Master MOS supports Service Call &26 to notify that *Shut is happening, but this is not available within RISC OS. And then there’s *Shutdown.
So, in short, it looks like one can notify applications of some conditions when its file may be closed, but not all conditions. Nice going RISC OS. :-/
</thinking>

the close button is not a furniture of the window but an icon and IIRC when the use clicks on this icon an extra mouse click event was received after I already closed the window.

Strange – surely pretty much every “OK” or “Cancel” button will cause the window to close in a way that isn’t the close icon?

Reminds me of a mouse-related oddity I spotted some time ago. I had one icon partially obscuring another icon: clicking on the first icon removed it, fully revealing the other icon underneath (yes it was a remove-the-tiles game). Clicking again without moving the mouse would now generate two events: one for the mouse click on the now-revealed icon, the other was for a mouse click on the icon that used to be there. Move the mouse between clicks and there would only be one event (for the now-revealed icon).

There’s no notification, for example…

if the alphabet/country/territory is changed
if the user connects/disconnects the USB drive (or, for that matter, any USB device)

and yet very recently added to the documentation on line

List of nonsensical functionality

This list contains functionality that doesn’t make sense, from the perspective of creating a clean API.

RISCOS_AddDevice can theoretically fail (if a device with that address is already registered and something prevents it from being removed), but no return value is given to indicate this failure. However this may be a non-issue since you’re just trying to add a device which is already added, so the device will be there whatever the outcome.

When I read that I thought of the USB device change that people have complained isn’t detected while whereas Sprow is highlighting that the OS does detect device changes but doesn’t let you know.
All in all I’d put that down as two sides of an incomplete aspect of the HAL/OS such that the completed functionality would allow for changes of connected devices, including one assumes network connections.

When I read that I thought of the USB device change that people have complained isn’t detected while whereas Sprow is highlighting that the OS does detect device changes but doesn’t let you know.

Say what now? I didn’t write that paragraph. Also, I edited a different part of the page recently (to remove the old touchscreen reference). And for extra puzzlement RISCOS_AddDevice refers to HAL devices which are not even slightly related to plugging in USB devices. I’m going for a lie down…

and yet very recently added to the documentation on line

Yeah… You might want to go back and reread my message. :-)

I’m talking about Wimp Message notifications to user mode and multitasked applications so they can be notified of various system wide events that would otherwise require lots of little (application specific) modules to be loaded to hook into the appropriate events or service calls. The reason that I picked those specific things is because they seem as natural to me as notifying when the screen mode changes.
I mean, don’t you think that the Wimp/FileSwitch has a duty to notify when a file handle is closed? (given recent discussion on this, potentially exacerbated by the habit of assigning handles from 255 down, so am app that does not know its handle has been closed could easily end up writing crap into files belonging to another application)?
Don’t you think the Wimp has a duty to notify if the entire machine is suddenly speaking UTF-8? Or having been switched to the Baltic character set?
Wouldn’t it be nice if it was a simple notification from the Wimp when a USB device is connected or disconnected? You could have “nice things” like Maestro enabling its MIDI support on the fly. Or the new Chars app allowing access to Unicode characters without needing to be restarted.
And so on.

I would have added “internet is connected/disconnected” but I’m not sure that this is propagated from the ether driver; though come days of WiFi it may be essential to know the connection status…?

I would have added “internet is connected/disconnected” but I’m not sure that this is propagated from the ether driver; though come days of WiFi it may be essential to know the connection status…?

There is a “Cable has been unplugged” type notification you can get if you keep polling the Ether_whatever module and looking at a certain bit. However what you look at and which bit is covered by an NDA if you want to read the official docs! I would hope that by the time we get to wifi support that a proper wimp message will be assigned and it will do it for you, no need to sign NDAs and write your own code!

Yeah… You might want to go back and reread my message. :-)

Hackcherly I’d just like to get some uninterrupted sleep – finishing a week long stint on call at 8am tomorrow and the list of sillies¹ in the past week is assisted by a cat that thinks I exist for fuss at 5am.

Let’s just forget I commented shall we?

¹ “It’s a network problem ICT are aware of” actually it was a lack of power into their kit due to a pulled lead.

Let’s just forget I commented shall we?

Nah, it’s fine. Gave me some time to think of the sorts of events that an application might be interested in that the Wimp ought to be providing.

And, besides, my nose would be a foot long if I tried to claim that I never grabbed the wrong end of the stick. ;-)

However what you look at and which bit is covered by an NDA if you want to read the official docs!

Is it only certain EtherX drivers that provide this information, or all of them? Because it rather takes the p*** if one needs to sign an NDA to get information on the behaviour of an open source module.
Especially given that I can imagine link disconnect triggering this bit, so just make some EtherX calls with the cable plugged in, and unplugged, and see what changes…?

…moved to somewhere more appropriate than this topic…