On Wed, Jul 2, 2008 at 1:48 PM, Chip Davis <[EMAIL PROTECTED]> wrote:
> On 6/30/08 14:48 Mark Miesfeld said:
>> The Clipboard test case that failed did a clipboard copy immediately
>> followed by a clipboard paste.
>>
>> cb1~copy("Some text")
>> text = cb2~paste
>>
>> Sometimes text would be the empty string. I think that was just
>> timing. If you query the clipboard to see if it has data after the
>> copy, then do the paste, it works every time. Normally you would
>> query the clipboard to see if it has data before doing a paste anyway.
>
> uh, Mark... Is this behavior documented? I'm not at all sure that I would
> have
> thought to "query the clipboard" any more than I would have thought to
> re-read a
> just-written file record "to see if it has data".
Chip,
This behavior is that of the underlying Windows API. I'm not real
familiar with the Clipboard API, I'll research it a little, I'm not
sure if Microsoft documents or not. If you mean do we (ooRexx)
document it, then no. In all of the ooRexx extensions that provide
access to the underlying Windows API, we document some of the high
level behavior. It would be impossible to try and repeat all the
Windows documentation in our ooRexx documentation.
But, the Clipboard stuff is inter-process. There has to be some delay
while the OS marshals the data for inter-process communication.
This test opened two separate clipboards (two separate underlying OS
clipboards.) Then after they were both open, it wrote (copied) to one
clipboard and immediately read (pasted) from the other. In the
underlying C functions that implement this for ooRexx, the actual read
first checks that there is data in the clipboard and if not returns
the empty string.
It is not surprising to me that the would second clipboard signal it
did not have the data yet. I am sure that the underlying API would
marshal the data going to the second clipboard, even though we know
the two processes were the same.
> A copy operation, immediately followed by a paste operation, that failed on
> occasion would definitely raise my astonishment factor...
The test case that opens only 1 clipboard and does a copy / past back
to back never fails.
Remember too that we are trying to test that our (ooRexx's) functions
are working correctly, we are not trying to see if we can break the
underlying Windows API.
I put a printf in the code to see why we were getting the empty string
back. It was because the second clipboard (the underlying OS's
clipboard) signaled that it did not have data. Our ooRexx function
was doing the right thing and working as designed.
I then stepped through it with the debugger and the clipboard *always*
signaled it had data. That leads me to believe the problem with the
test case was timing. The test case was trying to simulate the
behavior of copy / paste between 2 processes, but in a single process.
The point I was trying to make with the post was that: Hey, I changed
a test case, but I don't think the change in the test case changed the
nature of the test.
> I'm not at all sure that I would have
> thought to "query the clipboard"
You would if you were writing to the underlying Windows APIs in C and
something didn't work. <grin>
--
Mark Miesfeld
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
