QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Cobalt on September 19, 2019, 11:25:01 pm

Title: On Timer only allows SUB with Integer argument error?
Post by: Cobalt on September 19, 2019, 11:25:01 pm
Just what is this about?
Code: QB64: [Select]
  1. DIM Board(50, 30) AS INTEGER
  2. CONST TRUE = -1, FALSE = NOT TRUE
  3.  
  4. CONST MaxX = 50
  5. CONST MaxY = 30
  6. on timer(t1&,.025) AgeBoard(Board())
  7.  
  8. sub AgeBoard(B())
  9.  FOR x%% = 1 TO MaxX
  10.   FOR y%% = 1 TO MaxY
  11.    B(x%%, y%%) = FALSE
  12.  NEXT y%%, x%%
  13.  

ERROR:"Only SUB arguments of integer-type are allowed on line 7:

and yet Board is an integer type

why would it matter what type is sent to the sub by the Timer?

or is there something else going on and that is just some generic error coming up and not really telling what the true error is?
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: SMcNeill on September 19, 2019, 11:49:25 pm
Board isn’t an integer; it’s an ARRAY of integers.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: bplus on September 20, 2019, 12:49:15 am
That is curious.

Consulting Help on ON TIMER, it says "SUB parameter values are passed by value and should be SHARED or literal values!"

Which means even if it would take an array, it would be a temp copy of it and you could not save changed values through the arguments.

Looks like you will have DIM SHARED the array so that SUB would need no arguments.

Oh wait, maybe it's not just one array you want to change... ;(
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: RhoSigma on September 20, 2019, 01:34:55 am
Strings and Arrays are ALWAYS passed as reference (not BYVAL) to any SUB/FUNCTION call according to my findings. Had a similar problem a while back, and did investigate into it as far as possible. It makes sense, as Arrays and Strings arguments in fact are only the start addresses of the string/array, hence references to the actual string/array arguments. In that thinking, it won't probably work with UDTs either (exept if you pass just a single UDT element, not the entire UDT structure).

But as you can use SHARED variables as well to pass variables into a SUB/FUNCTION, I see no reason for bothering the developers, I think SUBs/FUNCTIONs are complicated enough with its internal implementation in QB64.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: SMcNeill on September 20, 2019, 01:44:40 am
Is my medication breaking my brain again, or....

****************

EDIT:  Never mind.  My poor brain is broken again.  I was thinking in terms of DECLARE LIBRARY for some reason.  I’m just gonna shut up and go back to bed.  LOL!
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Petr on September 20, 2019, 07:07:44 am
This "error" is not an error. The command ON TIMER simply does not have a specified value from the field, which have to use. I think it's more of a bad combination of commands by the programmer.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: bplus on September 20, 2019, 08:48:36 am
Strings and Arrays are ALWAYS passed as reference (not BYVAL) to any SUB/FUNCTION call according to my findings. Had a similar problem a while back, and did investigate into it as far as possible....


Which makes the case for ON TIMER that much more curious. It is NOT ALWAYS.

http://qb64.org/wiki/ON_TIMER(n)
  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Cobalt on September 20, 2019, 10:18:09 am
I was just hoping to make a more versatile program an not have anything shared. but ahwell.

Still wonder why a sub called by an on timer would be different than just calling the sub.

But I guess I'll just have to use SHARED. Poomp!
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Petr on September 20, 2019, 11:15:24 am
Big apology, Cobalt. I misunderstood the problem described. This is pretty stupid that the ON TIMER command is studying the parameters of the called subprocess. Why is ON TIMER interested about SUB parameters? It just has to call a subroutine.A really nonsensical restriction.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: SMcNeill on September 20, 2019, 02:13:14 pm
Which makes the case for ON TIMER that much more curious. It is NOT ALWAYS.

http://qb64.org/wiki/ON_TIMER(n)
  [ This attachment cannot be displayed inline in 'Print Page' view ]

I think Rho has hit the nail on the head with: “Strings and Arrays are ALWAYS passed as reference (not BYVAL) to any SUB/FUNCTION”.

ON TIMER *only* accepts values being passed to it BYVAL, (as per the screen shot bplus provides points out), so it can’t accept strings or arrays as a parameter type.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: bplus on September 20, 2019, 02:30:29 pm
I think Rho has hit the nail on the head with: “Strings and Arrays are ALWAYS passed as reference (not BYVAL) to any SUB/FUNCTION”.

ON TIMER *only* accepts values being passed to it BYVAL, (as per the screen shot bplus provides points out), so it can’t accept strings or arrays as a parameter type.

OH man, I missed the first few words of what Rho said, Strings and arrays, dang! I was skipping over that assuming he was saying all parameters were passed by reference which is true enough that we can pass arrays and change them in a sub and the main code accepts the change.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: RhoSigma on September 20, 2019, 02:59:32 pm
And I've an idea why it should be SHARED variables or literals:

Assume you define a variable X in the your main module, which shall be used as parameter to the ON TIMER() DoSomething(X) call...

Now think about the nature of ON TIMER, you define a time interval for the function call, but who says that your program is right executing anywhere in your main module when the interval is elapsed and the DoSomething(X) function is called.

What happens, when your program is executing within any of your SUBs or FUNCTIONs when the timer is ready to call DoSomething(X)? What is passed then? Because variable X is not known in your SUBs/FUNCs unless SHARED or maybe defined as a local X within the SUB/FUNC.

Literals will work always, as it's like a constant value.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Jack002 on September 20, 2019, 03:18:20 pm
I have never used ON TIMER.
The help said this
The ON TIMER statement sets up a timed event to be repeated at specified intervals throughout a program when enabled
So, is it like an interrupt?
If so, I understand the above post. You might be in a function or subroutine somewhere that does not have the scope of this parameter, then it makes sense that it can only take shared vars and literals.

What kinds of things do you use ON TIMER for?
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: bplus on September 20, 2019, 03:53:55 pm
I have never used ON TIMER.
The help said this
The ON TIMER statement sets up a timed event to be repeated at specified intervals throughout a program when enabled
So, is it like an interrupt?
If so, I understand the above post. You might be in a function or subroutine somewhere that does not have the scope of this parameter, then it makes sense that it can only take shared vars and literals.

What kinds of things do you use ON TIMER for?

Yes Rho's reasoning makes sense.

I don't use ON TIMER either, but you can make events happen at regular intervals regardless of what is happening in code, does it actually interrupt a sub? Might be useful in clock making.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Jack002 on September 20, 2019, 04:16:15 pm
Its useful in games programming. Interrupts are kinda mysterious. Think of two or more programs running concurrently. I think about this hot wheel timer I want to write, the two events you can't miss are when the car enters the first gate, and when it enters the 2nd gate and how much time has elapsed. Basic alone might be too slow to see these events if you need accuracy to 1/1000th a second, interrupts can help with that.  I'm still not to where I have done one yet tho.

I'm sure the mind of a juggler appreciates them. So many tasks going on simultaneously :-)
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: bplus on September 20, 2019, 05:02:45 pm
Its useful in games programming. Interrupts are kinda mysterious. Think of two or more programs running concurrently. I think about this hot wheel timer I want to write, the two events you can't miss are when the car enters the first gate, and when it enters the 2nd gate and how much time has elapsed. Basic alone might be too slow to see these events if you need accuracy to 1/1000th a second, interrupts can help with that.  I'm still not to where I have done one yet tho.

I'm sure the mind of a juggler appreciates them. So many tasks going on simultaneously :-)

Well for timing cars like a stop watch, just use start! = TIMER(.001) and stopTime! = TIMER(.001) and subtract Stop - Start.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: RhoSigma on September 20, 2019, 06:55:53 pm
I doubt the whole concept of passing arguments to a timer called SUB works well at all for a senseful use.
The passed variable must be initialized prior the ON TIMER statement, otherwise it won't work, hence the concept is pretty useless for passing any variable which changes during runtime...

Code: QB64: [Select]
  1.  
  2. 'x% = 1 'this works
  3. ON TIMER(1) TimerSub (x%)
  4. x% = 1 'doesn't work
  5.  
  6. PRINT "Next five seconds in main module, TimerSub() should print 1..."
  7. xWait
  8.  
  9. SUB xWait
  10.     PRINT "Now five seconds in a SUB, TimerSub() should still print 1..."
  11.     SLEEP 1
  12.     SLEEP 1
  13.     SLEEP 1
  14.     SLEEP 1
  15.     SLEEP 1
  16.  
  17. SUB TimerSub (arg%)
  18.     PRINT arg%
  19.  
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Cobalt on September 21, 2019, 11:43:54 am
Now think about the nature of ON TIMER, you define a time interval for the function call, but who says that your program is right executing anywhere in your main module when the interval is elapsed and the DoSomething(X) function is called.

What happens, when your program is executing within any of your SUBs or FUNCTIONs when the timer is ready to call DoSomething(X)? What is passed then? Because variable X is not known in your SUBs/FUNCs unless SHARED or maybe defined as a local X within the SUB/FUNC.

That should be up to the programmer to keep track of, at that point it is their responsibility. And I have ran into that, where I didn't want a TIMER event to run while certain SUBs were running, and had to turn TIMER off anytime those SUBs were running then back on when they returned.

That is all on the Programmer.

Another situation is where X could be different in each SUB or FUNCTION too and maybe you want that to be part of the program so the TIMER CALLed routine actually does something different depending on where in the program its happening.

If everything has to be SHARED then nothing in your program would work outside that program, so you couldn't make a Library of code for use in multiple programs. each one would have to be tailor made and that is not very helpful or fast.

TIMERs are actually very powerful tools, and need to be used responsibly to begin with.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Petr on September 21, 2019, 02:12:19 pm
I agree with Cobalt. If ON TIMER does not reject the SUB in the example above, it is sufficient to turn off the timer at the beginning of the called SUB and to switch it on again before ending this SUB. The argument check for the called SUB by ON TMER - i don't understand what it is for. After all, the task of ON TIMER is to run SUB. It is not his task to check the parameters with which the SUB is triggered.
Title: Re: On Timer only allows SUB with Integer argument error?
Post by: Petr on September 21, 2019, 02:33:11 pm
Quote
RhoSigma wrote:
I doubt the whole concept of passing arguments to a timer called SUB works well at all for a senseful use.
The passed variable must be initialized prior the ON TIMER statement, otherwise it won't work, hence the concept is pretty useless for passing any variable which changes during runtime...

Big true. In this must be some bug. I add BEEP to your SUB TimerSUB and row arg% = arg% + 1. WORK NOT. But BEEPs. If is this used in SUB, which is not called by ON TIMER this works.

Code: QB64: [Select]
  1.  
  2. 'x% = 1 'this works
  3. ON TIMER(1) TimerSub x%
  4. x% = 1 'doesn't work
  5.  
  6. PRINT "Next five seconds in main module, TimerSub() should print 1..."
  7. TimerSub x% 'if is the same sub called "normally", x% is returned as bigger. If is this sub called by ON TIMER, is x% returned as zero
  8. TimerSub x%
  9. TimerSub x%
  10. TimerSub x%
  11. TimerSub x%
  12. xWait
  13.  
  14. SUB xWait
  15.     PRINT "Now five seconds in a SUB, TimerSub() should still print 1..."
  16.     SLEEP 1
  17.     SLEEP 1
  18.     SLEEP 1
  19.     SLEEP 1
  20.     SLEEP 1
  21.  
  22. SUB TimerSub (arg%)
  23.     arg% = arg% + 1
  24.     PRINT arg%
  25.     BEEP
  26.  
  27.  
  28.  


and BEEP signalize, that this SUB is not end before increase the value of arg%.