Mark,
I'm curious...is the clipboard timing problem a new problem on trunk,
or did it occur on 3.2.0 also? I'll explain why I'm asking once I
have your answer.
Rick
On Wed, Jul 2, 2008 at 5:56 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> 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
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
-------------------------------------------------------------------------
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
