Clipboard Manager & Message_DataRequest
19 posts, 9 voices
Steve Fryatt (216)
2105 posts
|
I’m not sure if this is something that I’m doing wrong, but there seems to be an oddity with how the Clipboard Manager in the Wimp (WindowManager 5.75) handles a Message_DataRequest with a null list of filetypes. The original AppNote 240, which as far as I know is what defines Message_DataRequest, states that from offset 40 into the message block there is a list of filetypes terminated by -1. It also notes that “the list can be null, to indicate that the native data should be sent.” Clipper uses this, but when the Clipboard Manager has the clipboard, the Message_DataRequest bounces:
However, if I add a filetype of Text in there, Clipper gets a response:
Can anyone spot something wrong in the message blocks above, or isn’t Clipboard Manager responding correctly to a null list of types? PS. For comparison, Draw is quite happy with the null list:
|
|
Steve Fryatt (216)
2105 posts
|
I might have found another (or, at least, had another reported to me). Ovation Pro appears to acknowledge the Message_DataRequest to the Wimp, so that it doesn’t bounce back to Clipper, but never sends a Message_DataSave back in response. Meanwhile, Zap and TechWriter fall into the “appear to be doing what AppNote 240 says” category. Is Clipper really operating in some twilight zone that no-one else has used for the past 25 years, or is it doing something fundamentally wrong with the Message_DataRequest shown above? |
|
Steve Fryatt (216)
2105 posts
|
I’m gently bumping this thread in the hope that anyone has any ideas on where the problem lies! |
André Timmermans (100)
655 posts
|
As far as I remember from toying with the clipboard and dragging protocols in NoPaint and DigitalCD a long time ago, Clipper does nothing wrong, the empty list case mentioned by AppNote 240 was there mainly to allow clipboard management applications to take a copy of the clipboard in the native format. Clearly, the Wimp does not follow the protocol. For Ovation Pro, as a guess, maybe it just forgets initialize the file type and as it doesn’t matches any of its exporter formats doesn’t start the transfer. |
Dave Higton (1515)
3534 posts
|
I have no experience whatsoever of programming for the Clipboard, so this is a totally naive idea… Since the clipboard’s content is likely to be in RAM, wouldn’t it make sense for the data exchange to be by RAM transfer? Maybe it uses that and doesn’t even bother to implement a file-based protocol. |
|
Steve Fryatt (216)
2105 posts
|
Sort of, although there’s quite a lot of stuff that doesn’t do RAM Transfer (there was some issue with WimpScrap exchanges in the early Clipboard Manager code that caused it to fail, IIRC, which caused all kinds of wild speculation over on the R-Comp mailing list). I had initially planned to upgrade Clipper to do RAM Transfer, until I looked at how it’s implemented. It’s not really an option for Clipper, because of how it works. Since it allows the user to drag the clipboard contents to disc, all that it actually does is lie enough to both the clipboard owner and the destination task (the filer, or whatever) such that both parties believe that they’re actually talking to each other, then lets them get on with it. This allows it to do something apparently complex with very little code. Given all of the MyRef/YourRef tracking that goes on to make it all work, it’s also a good example of how to do the protocols completely (and it’s in BASIC, too). For now, I’ve worked around the issue by following the null list with one specifying “text” if the original message either bounces or goes into a black hole. I’ve also dropped David P an email; I’m assuming that this thread should be sufficient to get some feedback about the Clipboard Manager… |
Sprow (202)
1158 posts
|
Looks like Clipboard Manager skipped over the bit in 5.3.1 about returning the native type if there’s no match. I’ve put a test module here which should fix it. Usual drill: exit the desktop via Task Manager, RMLoad the module, then |
Chris Hughes (2123)
336 posts
|
Sorry if I have hi-jacked the thread, but have encountered an issue with Messenger Pro and Email Edit and copy/pasting which used to work Ok before the WIMP changes. I have informed R-Comp of this issue last week, not sure if it a bug or something else going on. |
Andrew Rawnsley (492)
1445 posts
|
I was waiting for Andy to return from holiday before troubling him with this. Since it works with the clipboard manager on Adjust, I wouldn’t have thought the problem lay in Mpro, but it’s not impossible. I intend to share the source with Andy, and hopefully between us we’ll be able to track it. I suspect it has to do with Mpro implementing copy/paste in icons itself (long before the wimp did it), but that shouldn’t stop it all working together, so some investigation will be required. |
|
Steve Fryatt (216)
2105 posts
|
There’s something odd with this, as M-Pro seems to get its message size wrong. The Message_DataSave here shouldn’t be that big.
I don’t think that’s actually the problem, because the content looks correct and Clipper is still happy to accept the information. You can actually save the contents out via Clipper, too, and the convoluted two-way exchange between M-Pro, Clipper and Filer works fine:
Clipboard Manager and Email Edit look to be fighting each other. If you look at the exchange below, EmailEdit sends out a MessageDataRequest with ref &936, then Clipboard Manager sends one out with ref &937. This suggests that both are planning on handling the paste request in the icon. What happens then is odd: M-Pro responds to both message &936 and &937 with a Message_DataSave, but sends both of the replies (refs &938 and &939) to the Clipboard Manager. After that, the Clipboard Manager appears to attempt to start up a RAM Transfer, but fails. I’m not going to rule out MsgMon being broken and getting its task handles confused, but on the face of it, the apps seem to be confusing themselves a little:
|
|
Chris Hughes (2123)
336 posts
|
yes that basically what I have been doing since I found the issue, so Clipper has proved very useful. I don’t understand all that analysis Steve sorry, but it seems there is an odd issue there. You got me playing about with EmailEdit more to see what happens and that also does not work for CTRL-C/CTRL-V on the To: or Subject line. But you can highlight the text in those fields and drag them if you hold the select mouse down. Which I had not seen before. I think this is one for Andrew and Andy to dig into further when Andy is back from his Holiday. |
|
Steve Fryatt (216)
2105 posts
|
You said…
…which implied that it wasn’t working. In fact, this is all that I’d expect Clipper to do at that point: it’s found the new clipboard owner, and has remembered the information for future reference.
I was expecting that info to be of use to those with access to the source code, not to an end user. I was already set up to grab them, having been doing similar analysis on something else earlier in the morning, so figured they could be useful to someone. |
|
Chris Hughes (2123)
336 posts
|
I meant it got copied to the clipboard as shown in Clipper. But the only way to paste the text was to drag the icon from Clipper to the To: or Subject field, etc.. using CRTL-V in the fields did not work, even though the text was showing in the clipboard |
Rick Murray (539)
13850 posts
|
People go on holiday? In 2020? 😱 Well, I suppose rummaging around code is a way to pass the time in whatever half-assed idiotic knee-jerk mandatory quarantine the government decides to apply. |
Andy Vawer (5817)
28 posts
|
I think I know what the problem is here thanks to the logs above. If you have a writeable icon with validation string KA, the client task is notified of all key presses as requested, including caret motion presses but notably also ^C, ^V, etc. So if you press ^V to paste, the Wimp traps it and starts up its thing. It then passes the keypress to the client which also does the same thing again… leading to a message fight. I am looking at a change whereby the Wimp won’t pass clipboard keypresses on to the client when KA is used to prevent this clash. If a client task really does want to see those presses, then the newer (unless you use Adjust in which case it’s been about a bit longer) KC validation string can be used to stop the Wimp intercept of clipboard functions for writeables. I have tweaked my version and will check it a bit more tomorrow. |
|
Steve Fryatt (216)
2105 posts
|
I still think someone needs to look at M-Pro… that Message_DataSave block looks malformed, and regardless of what other apps might be doing to it, it should not be sending message responses back to the wrong tasks.
Does anyone know what the ROL clipboard did for this? I don’t know how widespread it is, but some of my apps rely on receiving keypresses to know when data has changed in the icon. Could this change result in data being pasted in to an icon without the app knowing that it has happpened? It’s not unreasonable to expect such apps to use the KC validation, although this does then force them to implement the clipboard themselves. I just wonder if it might suddenly spark a new collection of “Eureka Complaints” for apps which aren’t supported – although changing a validation string is often simple in well-written apps. |
|
Andy Vawer (5817)
28 posts
|
My tweak does work in that by selecting a different return pathway, the keypresses get absorbed by the Wimp nicely. However, this does run into exactly the possible situation you are talking about, Steve, in that there’s no sensible way for the client to know that there may have been a change to the icon text at all. It seems the logical interpretation of ‘return all keypresses’ should be exactly that. Hmm. The tricky part is that some historic apps will then misbehave as we are seeing with 2 conflicting attempts at a clipboard at the same time. It may be possible to correct some behaviour by tweaking the templates to insert the validation strings. For other legacy apps you could implement a simple module with a command like *NoClipboardKeys that would pick up the new task and install a postfilter to remove the keypresses returned so that the clipboard bits aren’t seen if the keypress is being reported for an icon. It’s then easy to add the extra command to the Run file. Newer apps (currently being maintained) that do want to maintain their own clipboard bits for older OSes may need to check the Wimp version to determine whether or not they handle icon clipboard stuff themselves or not? Obviously the M-Pro mangled message is still potentially an issue with M-Pro, but that’s possible to look at and fix; the length is certainly too long. I think we may have to see what the general consensus is as to the preferred way forward on this one as all options may break something :( The other thought is that if you’re relying on keypresses to know an icon has changed then there won’t be any notification after a drag/drop paste into your icon. There probably ought to be a way to signal to the client that this has happened. The Wimp could raise a ^V keypress event on the target perhaps (but that may cause issues like above)? Or do we add a different Wimp message for ‘icon has been changed’ or ‘clipboard paste completed’? |
|
Steve Fryatt (216)
2105 posts
|
I’ve done some quick tests on this, and it seems that your idea is in line with both how ROL did it, and how IcnClipBrd works1. Interestingly, CashBook, which is the app I was thinking of, is actually broken in this respect – and no-one has noticed. On that basis, I’d suggest that your fix is correct. Apps then have two choices: defer all clipboard support to the Wimp, or use the KC validation and do it themselves. The only question I have is how ROL’s clipboard insets text into an icon on paste. The bit about the KN validation here implies that it could type it at the caret, but I’ve not checked. That would explain how CashBook can see pastes but not cuts in its icons.
Are you aware of Wimp_ReadSysInfo 21? I’m sure that I’ve asked about detecting the clipboard availability, but don’t recall it coming up; I’ve just stumbled across it in the ROL documentation (towards the end of this). Perhaps this needs to be implemented in RO5 if it isn’t already (it’s shown as Reserved for future use at the moment), so that apps can see if they should disable their own support. Any apps which already do so for the ROL strand would then get this right out of the box.
Of course. :) 1 I should probably have known that, but in my defence, I didn’t actually write it… |
Martin Avison (27)
1494 posts
|
Andy wrote:
Steve replied:
Andy’s suggestion to check Wimp versions is not really viable: I have no idea which versions to check fo, and it requires more code. Changing validation codes for affected icons would be possible, but it seems stupid to have to check thousands of icons in templates, and do the necessary testing. Can I add my support to Steve’s suggestion that Wimp_ReadInfo,21 is urgently implemented on the new Wimp, at least so that bit 0 of r2 is set when Text selections are enabled. This would mean that programs which already use that to check for the Select C’n’P automatically work on the new Wimp, and it is an easy check to add to any program. Is there any way to request this, as it does not seem right to raise it as a bug? |
