Hey developers, how about a _WAIT CLIPBOARD$

[Pete]

I sometimes take advantage of testing my code, before writing to files, by concatenating all the file entries to _CLIPBOARD$. Then I can just past to notepad to view the results. I had some particularly large files to test, and I noticed some of the expected _CLIPBOARD$ results were missing. Easy to figure out why, the _CLIPBOARD$ function was unable to keep up with the speed of the loop.

In the loop, I used: _CLIPBOARD$ = _CLIPBOARD$ + x$

I suppose I could have tried substituting a variable for _CLIPBOARD$ instead like: _CLIPBOARD$ =  x$: a$ = a$ +x$

Maybe it was th doubling up of the _CLIPBOARD function that caused the problem; however, shouldn't the program flow wait until the clipboard function is completed, even if two or more _CLIPBOARD$ functions are being utilized?

Pete

[RhoSigma]

Same thing I already discovered here: https://www.qb64.org/forum/index.php?topic=1971.msg111995#msg111995

so try a _DELAY...

[FellippeHeitor]

I stand by my post on that thread.

[Pete]

I remember that now, after reviewing the post. I posted in that thread about my experience with the need for using _delay in SCREENCLICK but at that time, I had not personally experienced the looping _CLIPBOARD$ lag. Well, if _CLIPBOARD$ is utilizing Windows API, I get it. Many Windows API calls require _DELAY be added in the user code to function as intended. So this now becomes more a documentation issue, as I' pretty sure I'll be asking it agoin next year, when I forget about that thread and this thread all over again. :D

Pete

[SMcNeill]

I remember that now, after reviewing the post. I posted in that thread about my experience with the need for using _delay in SCREENCLICK but at that time, I had not personally experienced the looping _CLIPBOARD$ lag. Well, if _CLIPBOARD$ is utilizing Windows API, I get it. Many Windows API calls require _DELAY be added in the user code to function as intended. So this now becomes more a documentation issue, as I' pretty sure I'll be asking it agoin next year, when I forget about that thread and this thread all over again. :D

Pete

Or add a termination sequence to your clipboard data.....

Once upon a time.....

The rest of my novel goes here....

THE END

DO
   in$ = in$ + _CLIPBOARD$
LOOP UNTIL INSTR(in$, “THE END”) <> 0


It’s the same concept of how you often work with data statements:

DATA 1,2,3,4,5,6,7,8,9,10,11, -1

DO
    READ x
LOOP UNTIL x = -1 ‘-1 is the end of data terminator in this case

[Pete]

Well for me, the good news is I only needed the copy to clipboard routine for testing purposes. It added about 23K to the clipboard, over about 1200 loops.  For testing, inserting a delay, and it worked just fine.

I have used exit loops before, to identify when a webpage has been crawled and saved, etc. That's a nice idea using INSTR() for the clipboard, but it requires a known terminator. Now in your example, you could have alternately used RIGHT$(_CLIPBOARD$, 7). Another method would be to test the LEN(_CLIPBOARD$) and when it's equal to the oldclipboard% + LEN(whatsbeignadded) then EXIT DO.

Neat stuff to discuss, but this 4000+ line piece of crap I'm writing now isn't going to finish itself. Hey, maybe by V1.5 it could???

Pete