Am I going mad here?

Please don’t jump in with your affirmation so soon…

I’m writing a little BASIC app with a single window containing two indirected writable text-only icons, plus an indirected icon with button type “Never”. I want the user to be able to drag a file into the window and for its name to be displayed in the “Never” icon.

What I’m seeing is that dragging a file, and dropping it on one of the writable icons, causes the first line of the file’s content to be displayed in the icon.

That shouldn’t happen, should it?

There is no code running to handle DataLoad messages – I commented it out so it’s not called.

What I’m seeing is that dragging a file, and dropping it on one of the writable icons, causes the first line of the file’s content to be displayed in the icon.

Drag and drop support for writable icons, at a guess?

Isn’t there a flag or validation code that you can set to avoid that happening? Or is it the other type of writable icon?

It looks like it may be WindowManager doing that and I’ve just managed to completely crash a machine by dragging a file to a writable icon. Hopefully it is checking buffer lengths!

I’ve just tried an experiment – if you reply to the DataLoad message with a DataLoadAck (message 4) it stops the behaviour.

I have just tried dragging files to writable icons – if not a Text file it seems to do nothing. If it is a text file it inserts the first characters of the file contents into the icon, up to the length of the icon text. Original text is added to, not replaced. The icons had a variety of K validations, or no K validation. No crashes or other effects were noticed.

My target icons were in a simple window that was just Created & Opened by BASIC from a Template, with Wimp 5.87.

Hopefully it is checking buffer lengths!

OS or apps in RO checking input parameter validity? Novel idea.

I’ve just tried an experiment – if you reply to the DataLoad message with a DataLoadAck (message 4) it stops the behaviour.

Ah, thanks, I’ll try that as soon as I get a chance.

Drag and drop support for writable icons, at a guess?

Clipboard manager trying to be “helpful”?

Isn’t there a flag or validation code that you can set to avoid that happening?

There’s a large part of me that wants to scream “no, you use flags to turn ON non-normal behaviour”, but it’s too hot and I’m too damn tired.
(and eating a bowl of microwaved linguine and drinking tea is not helping!)

There’s a large part of me that wants to scream “no, you use flags to turn ON non-normal behaviour”

This isn’t “non-normal” behaviour, however – it’s what writable icons should do by default unless there’s a very good reason for them not to. The Drag and Drop protocol works alongside the Clipboard one to ease data transfer around the desktop, so having to re-write all applications before they can make use of the new functionality would be less than optimal.

If you have a writable icon, you probably want to think hard about why a user shouldn’t be able to insert text into it from elsewhere before blocking the functionality.

OS or apps in RO checking input parameter validity? Novel idea.

The Wimp has always bounds-checked text typed into a writable icon, so there’s no reason to assume that it shouldn’t do so for text copied in. This is user-facing, not an internal API.

I can confirm that sending a DataLoadAck message stops the writable icons being loaded with text.

Interesting, isn’t it, that the problem wasn’t caused by code that I had written, it was caused by not having written code that was necessary.

My next question is, is this undocumented behaviour? The only places I could think to look were on this site under the two relevant Wimp messages, and I couldn’t see anything relevant. Should there be? Are they the right places?

I’m not suggesting that the behaviour is in any way wrong, but it needs to be known about. I didn’t know. Either I should have known, or the information wasn’t obvious to me.

Is it reasonable/logical to have the beginning of a dragged file put into the writable when the file is larger?

I can understand the reason why this is being done, and I wish I had known about it before copy-pasting my stupidly long WiFi key a bunch of times. But things that are too big to fit maybe shouldn’t be stuffed and truncated.

Is it reasonable/logical to have the beginning of a dragged file put into the writable when the file is larger?

Why not? It’s just the same as truncating a large block of text that’s pasted from the clipboard. Better that than trying to second-guess what the user might have wanted to do, and blocking valid actions as a result.

Let’s not get too upset. I only fell into this because I had an incomplete implementation of the drag and drop protocol. The only use case for DataLoad without DataLoadAck seems to be to fill a writable icon, in which case the file (probably Wimp$Scrap) would contain only the wanted text. If the icon were too short, one would expect the Wimp to truncate the text.

My questions about documentation still stand though.