Edit clipboard receiving
8 posts, 3 voices
Andrew Rawnsley (492)
1445 posts
|
I’ve been meaning to mention this for a while, but had a particular issue today while preparing a demo. !Edit is very fussy in its clipboard implementation, and (I think) only accepts data via ram transfer and not wimp$scrap transfer Certainly I was copy/pasting from Iris into StrongEd quite happily via copy/paste, but trying the same demo resulted in !Edit reporting Data Transfer Failed I have seen this (or similar) when receiving data into !Edit from other applications too (some my own, but others too). My guess is that !Edit is implementing only a subset of the whole clipboard protocol, and being rather stringent about things, rather than supporting some of the more basic “fall back” methods that the specification includes (and which tend to be more widely compatible with other applications, from experience). It would be nice if this could be resolved, as it makes the clipboard features in !Edit a bit one-sided, and less useful. Note that I’m sure one response will be that this is the fault of (in this case) Iris (which ironically uses ROOL Clipboard module https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20Clipboard ). That’s a valid complaint, but the protocol allows for a “lowest common denominator” which !Edit doesn’t seem happy with based on experience with other programs. Ironically, IIRC all the code for wimpscrap based transfer is already in !Edit for ram transfer drag’n’drop to iconbar icon, as I recall seeing it in RISCOSLib. |
Steve Fryatt (216)
2105 posts
|
I’m fairly sure that’s not correct. Clipper only does WimpScrap transfer in some cases, and it’s happy to send text to Edit for pasting:
Could I suggest recording what actually happens, and then we can see where the problem lies? If you don’t have a favourite tool for this kind of thing, MsgMon apparently works OK. I don’t have Iris, otherwise I’d try it out. |
|
Andrew Rawnsley (492)
1445 posts
|
Reporter 2.66d (11 Feb 2012) List Fri 16th Oct 2020 16:38 16:38:16.21 * ReportClear * from Menu Message &044EC0 [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message &044EC0 [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_ClaimEntity (&00000F) [Message] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataRequest (&000010) [Message Recorded] Message_DataSave (&000001) [Message Recorded] Message_RAMFetch (&000006) [Message Recorded] Message_RAMTransmit (&000007) [Message] Message_RAMFetch (&000006) [Message Recorded] Message_RAMFetch (&000006) [Message Acknowledge] Message_FilerOpenDir (&000400) [Message Recorded] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Message_WindowClosed (&0400CB) [Message] Reporter 2.66d (11 Feb 2012) Listed 445 lines |
|
Andrew Rawnsley (492)
1445 posts
|
Note that the reason I mentioned wimp$scrap was that that is the method I have used previously, and that never seemed to work with !Edit, but did with all my other clipboard test applications. Iris may be doing something different, or it could be something else entirely. PS, thanks for recommending MsgMon |
|
Steve Fryatt (216)
2105 posts
|
It looks from this as if if Iris is starting off on the RAM Transfer route, but then not finishing the exchange. First, Edit asks for the some data, and Iris replies:
Edit offers a buffer of 219 bytes, which matches the estimated size from Iris, and Iris responds with a full buffer. Since Iris fills the buffer, the exchange hasn’t finished, and so Edit sends a second RAMFetch:
Iris should respond with zero bytes in the buffer if it has finished, but it doesn’t and the message bounces back to Edit. Presumably Edit, not unreasonably, takes this as the operation failing. The whole data transfer protocol is filled with pitfalls like this. PS. Arguably Edit isn’t being too clever by offering a buffer of exactly the size given by Iris, as it forces two messages. However, it’s a documented edge case, the sizes are estimates only… and if Edit didn’t do it, something else would. |
|
Steve Fryatt (216)
2105 posts
|
If you’re only interested in data transfer protocol messages, having an Obey file containing which you run after starting MsgMon will remove a lot of background noise from the logs! |
Steve Pampling (1551)
8170 posts
|
Amend both applications? |
|
Steve Fryatt (216)
2105 posts
|
Possibly… although the way the RAM Transfer protocol was designed/evolved/came into being, you’re always going to hit the edge cases at some point, so an app must be able to handle them. In the absence of a Data Transfer Test Suite, knowing that Edit will probably present the most exciting edge case to an application that you’re developing is actually quite useful. :-) |
