I have found that clipboard operations, including the clipboarddata in Rev require a hesitation of 0.5 to 1 sec to allow the operating system to deal with the 'shared/transportable' nature of clipboard data. Microsoft has extensive clipboard definitions (Excel charts, bit maps, rtf, etc) which adds to user flexibility, for example, but they don't easily translate to other programs. The same works for Photoshop, if that is what you are using to work with you images.
Rev can work so quickly and most likely too quickly for the operating system. The slower the computer, the longer the wait. This has been my experience working with AppleScript and not images, but it probably applies there as well. Jim Ault Las Vegas On 10/7/05 9:20 PM, "Todd Geist" <[EMAIL PROTECTED]> wrote: > > On 10/7/05 3:32 PM, "Jerry Daniels" <[EMAIL PROTECTED]> wrote: > >> Todd, >> >> By all means, send an example along to me. If I can replicate it, I >> can fix it. >> >> I copy images pretty often but have not had any problems with it, but >> that doesn't mean there isn't a bug in there waiting to be fixed. >> Best, > > I haven't been able to completely isolate the issue but I did get a work > around. > > My app is processing and saving some Clipboard Contents. A series of > handlers does the work > > GetTheClip -- got the clipboard > > ParseTheClip -- Parsed some stuff and put the clipboard image in a img on > the current card > > SaveTheClip -- Saved some text and the img to a card on a data stack > > > "SaveTheClip" worked just fine As did "ParseTheClip". But strung together in > a parent handler they did not. > > So I put a wait .05 sec in between them and everything worked. > That is as close as I can get. If I get any more info I will pass it on. > > > Thanks > > Todd _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
