|
Post by sarossell on Mar 4, 2020 18:43:39 GMT -5
If you call the mstimer sub, and try to close the window while it's counting, you get an error saying that the [finish] branch label is invalid.
If instead, you include the timer code (currently commented out), it works fine.
It also works fine if you wait for the count to finish before trying to close the window.
So, why does it freak out when using the subroutine, but not the same code incorporated in the loop?
[start] nomainwin global [finish] WindowWidth = 300 WindowHeight = int(WindowWidth*.618) UpperLeftX = int((DisplayWidth-WindowWidth)/2) UpperLeftY = int((DisplayHeight-WindowHeight)/2) open "Loop Tests" for graphics as #main #main, "font courier_new 36 bold" print #main, "trapclose [finish]" for n = 1 to 5 #main, "place 100 100" #main, "\";n
call mstimer 500
' timer 500,[done] ' wait ' [done] ' timer 0
next wait [finish] close #main end
sub mstimer inMS timer inMS,[done] wait [done] timer 0 end sub
|
|
|
Post by Chris Iverson on Mar 4, 2020 18:52:43 GMT -5
Scope. There's no such thing as a global branch label. Branches at the top-level scope are not visible inside functions/subroutines, and vice-versa.
Quite frankly, this line:
global [finish]
should be throwing a syntax error, and I consider it a bug that it's not. It's a meaningless statement.
If code execution is inside the mstimer subroutine when the event fires, it will try to move execution to a branch label that doesn't exist.
That's why subroutine event handlers are recommended if you're doing a lot with subs/functions.
EDIT: Actually, that GLOBAL statement DOES throw an error. It says "invalid variable name" instead of "syntax error", but all the same. The code as written wouldn't run anyway.
|
|
|
Post by Carl Gundel on Mar 4, 2020 18:55:57 GMT -5
Scope. There's no such thing as a global branch label. Branches at the top-level scope are not visible inside functions/subroutines, and vice-versa. Quite frankly, this line: global [finish] should be throwing a syntax error, and I consider it a bug that it's not. It's a meaningless statement. If code execution is inside the mstimer subroutine when the event fires, it will try to move execution to a branch label that doesn't exist. That's why subroutine event handlers are recommended if you're doing a lot with subs/functions. EDIT: Actually, that GLOBAL statement DOES throw an error. It says "invalid variable name" instead of "syntax error", but all the same. The code as written wouldn't run anyway. Yes, and it is usually considered bad form to use wait or scan inside of a sub or function. So, global should throw a compile error, I agree. And compiler reporting would also be improved if it warned about the wait inside a sub.
|
|
|
Post by sarossell on Mar 4, 2020 20:28:51 GMT -5
I'm so sorry guys. I was down to trying stupid stuff when I finally gave up and posted the code in the message. I forgot to remove the global nonsense. Sorry for the confusion.
And thanks for the scope info. Makes perfect sense. I really appreciate it! :@)
|
|
|
Post by sarossell on Mar 5, 2020 3:25:29 GMT -5
So, I outsmarted myself (not that hard to do, apparently).
I used a simple loop comparing time$("ms") for my delay along with SCAN to allow the trapclose. That works. But then something weird happens; the count skips numbers as it increases. What the...? I assumed the For..Next loop would have total control. What am I missing here guys?
[START] nomainwin WindowWidth = 300 WindowHeight = int(WindowWidth*.618) UpperLeftX = int((DisplayWidth-WindowWidth)/2) UpperLeftY = int((DisplayHeight-WindowHeight)/2) open "Loop Tests" for graphics as #main #main, "font courier_new 36 bold" print #main, "trapclose [FINISH]" for n = 1 to 60 #main, "place 100 100" #main, "\";n t1 = time$("ms") while time$("ms")-t1 < 200 scan wend next wait [FINISH] close #main end
|
|
|
Post by Rod on Mar 5, 2020 6:04:08 GMT -5
Well I don't see that happening on my machine, all values of n are displayed. Its hard to see if its running fast but slow it down with a bigger number to check.
Now this is nothing to do with your current problem I just comment in general terms about loop delays. I am not a fan of these time wasting loops. For two reasons.
First off they can make your program unresponsive but you have that covered by the scan statement. But on my machine the processor is executing 14000 loops in each n increment delay, the processor could be doing other things.
Second reason is the Windows "clock" the timer uses is not that accurate. It has millisecond precision but the clock face it shows us only changes every 16.6 ms. So when you look at the clock to get your starting value its part way through this long clock tick, when you look at the clock to get your ending value its part way through this clock tick. Do this lots of times per second and accuracy can suffer. On top of all that Windows paces the processor cycles so you may see a slow start then a sustained burst interspersed with short delays as Windows dishes out the cycles.
But back to the current problem, aside from the variation in speed I see nothing wrong with the code.
'the clock face problem for n= 1 to 500 print time$("ms") next
'nomainwin WindowWidth = 300 WindowHeight = int(WindowWidth*.618) UpperLeftX = int((DisplayWidth-WindowWidth)/2) UpperLeftY = int((DisplayHeight-WindowHeight)/2) open "Loop Tests" for graphics as #main #main, "font courier_new 36 bold" print #main, "trapclose [FINISH]"
for m= 1 to 10 st=time$("ms") for n = 1 to 60 #main, "place 100 100" #main, "\";n t1 = time$("ms")+100 c=0 while time$("ms")<t1 c=c+1 scan wend print Time$("ms")-t1,c next print time$("ms")-st next
wait [FINISH] close #main end
|
|
|
Post by Rod on Mar 5, 2020 6:17:13 GMT -5
This timer delay allows you to break out. The timer 0 statement at [FINISH] is important so too anywhere else you might branch away to.
nomainwin WindowWidth = 300 WindowHeight = int(WindowWidth*.618) UpperLeftX = int((DisplayWidth-WindowWidth)/2) UpperLeftY = int((DisplayHeight-WindowHeight)/2) open "Loop Tests" for graphics as #main #main, "font courier_new 36 bold" print #main, "trapclose [FINISH]" for n = 1 to 60 #main, "place 100 100" #main, "\";n;" " timer 100,[delay] wait [delay] timer 0 next wait
[FINISH] timer 0 close #main end
|
|
|
Post by sarossell on Mar 5, 2020 15:58:19 GMT -5
As always, much appreciated!
I was just surprised by the way LB behaved with my code. It just seemed to me that the logic would go something like this...
For says n = 1 Print 1 What time is it? What time is it again? Has it been 200 ms yet? What? You want out, Scan? No? Then shut up, I'm watching the clock. Okay, 200 ms passed, carry on. Next For says What was all that noise about? Whatever... For says n = 2 now Print 2 ...
Instead, what I got was more like...
For says n = 1 Print 1 [Same as before] For says What was all that noise about? Whatever... For says n = 2 now Print 7
What the heck For?! Wat happened to 3, 4, 5 and 6? Did you print them somewhere else?
I can understand if the time$() option is not accurate or is unreliable, but it's contained in the For..Next loop. It just seemed logical to me that the loop wouldn't care if time$() was off by a few ms, it would just print the next number in the loop. But that's not what happened. It takes roughly the right amount of time to display the numbers. It just doesn't display all of them.
|
|
|
Post by Rod on Mar 5, 2020 16:41:21 GMT -5
Ok, I am not seeing anything like that behaviour. The code is plain old normal for me and I see every value of n in sequence. What happens if you keep an audit trail?
[START]
WindowWidth = 300 WindowHeight = int(WindowWidth*.618) UpperLeftX = int((DisplayWidth-WindowWidth)/2) UpperLeftY = int((DisplayHeight-WindowHeight)/2) open "Loop Tests" for graphics as #main #main, "font courier_new 36 bold" print #main, "trapclose [FINISH]" for n = 1 to 60 print n #main, "place 100 100" #main, "\";n t1 = time$("ms") while time$("ms")-t1 < 200 scan wend next wait [FINISH] close #main end
|
|
|
Post by Rod on Mar 5, 2020 16:57:21 GMT -5
Its probably about getting your OS to paint the screen. Try CLS before print \n, try FILL or FLUSH, See if you can find a drawing command that forces your system to paint the screen. John might have better advice about Linux systems. Your on a Linux based system right?
If you keep your mouse moving while it is running do the numbers display?
|
|
|
Post by Chris Iverson on Mar 5, 2020 17:24:06 GMT -5
Rod's test is pretty much exactly what I was going to suggest.
And I agree with his assessment, as well. Whatever's handling window painting in your OS is only drawing the buffer about once a second, which equates to five skipped numbers, as we see.
The numbers are all being drawn, the OS just doesn't draw them to the screen before a new one has taken its place.
|
|
|
Post by sarossell on Mar 5, 2020 17:28:01 GMT -5
What happens if you keep an audit trail? I'm not sure what you mean.
I'm running v.4.5.1 (not Pro) in Windows 10 in Parallels on a MacBook Pro 2.5 GHz i7 with 16 GB RAM and dedicated AMD Radeon R9 video.
You're on to something about the mouse though. It does function normally if I just keep wiggling the mouse. But the window has to be active and the mouse has to be inside the window.
|
|
|
Post by sarossell on Mar 5, 2020 17:29:57 GMT -5
The numbers are all being drawn, the OS just doesn't draw them to the screen before a new one has taken its place. I wouldn't be surprised if yet again it's Parallels. There was an issue a while back where it was altering the quality of graphics and colors.
|
|
|
Post by sarossell on Mar 5, 2020 17:33:12 GMT -5
Hey hey! Adding flush appears to have done the trick! Now every number displays exactly as expected.
You guys rock! :@)
|
|
|
Post by Rod on Mar 5, 2020 18:00:17 GMT -5
The audit trail code was just showing that Liberty had been through all the n loops. It printed to the mainwin in my example. Ok so flush works but I would still see if there are any solutions or updates for your OS because it shouldn’t be necessary to force a screen repaint. If you do use flush you should be aware of cls, discard, delsegment etc. All these commands keep flushed segment growth in check. Only a big deal if you do lots of repetitive drawing.
|
|