QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Pete on February 16, 2020, 07:34:09 pm
-
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
-
Same thing I already discovered here: https://www.qb64.org/forum/index.php?topic=1971.msg111995#msg111995
so try a _DELAY...
-
I stand by my post on that thread.
-
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
-
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
-
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