www.coridium.us/forum

Problem ?? calling a Function by label with no PARENS (), I thought was illegal
OR is it because I am not passing a value to it, just getting the RETURN value???
'
BT/compiler will call this function:
/////
function event_current_status()
dim current_status
current_status = AD(2) >>6
return current_status
end function
/////
with this result:
Executing...

starting Main:

1 to display time-- 2 to set time
3 live AD value -- 4 set threshold
5 reset data, 6 review data, 7 prnt data
8 battery voltage, 9 event logger - GO
choice was 2
* * RTC updated during 'EVENT logger
set time accordingly
D ? enter value
H ? enter value
M ? enter value
S ? enter value
time is set
30th 21:18:45

1 to display time-- 2 to set time
3 live AD value -- 4 set threshold
5 reset data, 6 review data, 7 prnt data
8 battery voltage, 9 event logger - GO
choice was 9
start status 420....................NO PARENS, to get this value
30th 21:19:OO

30th 21:19:O3

382........................I changed the AD potentiometer input - so the 'while loop would exit"
no parens !!
30th 21:19:O4

373
no parens !!
30th 21:19:O5

396
no parens !!
30th 21:19:O6

404
no parens !!
*******************************CODE SEGMENT that caused the above print out -- notice the parens () are missing !!!
Status:
event_start_status = event_current_status .......................NO PARENS
print "start status ",event_start_status
'
Monitor_loop:
'
if threshold >= 0
while event_start_status < (event_current_status() + hysteresis) AND event_start_status > (event_current_status() -hysteresis)
call RTC_update_time
loop 'checks event monitor input pin every second
else
'REM routine for digital change in value
endif
gosub RTC_read_time
'
print event_current_status.......................NO PARENS
print "no parens !!"
event_start_status = event_current_status()
'log info
'check for an end of job event/button
goto Monitor_loop

FUNCTION or SUB without parameters can be called with or without (). Nothing is being passed so it doesn't much matter.

So I'm not sure what the issue is here.

GOSUB or CALL keywords are optional for FUNCTION or SUB, they are for backwards compatibility with some BASICs that required them. I tend not to use them myself.

no program issue, I thought the compiler was overlooking something., ws all
I first noticed it when doing the mbed, went back and verified it on the BChip.
**
I am confused when you say the GOSUB and CALL keywords are optional --
I took the CALL out of my loop and now I get errors from the compiler -:::
RTC_update_time
-ERROR C:/Coridium/Basic.mbd2/Examples/1768_event_logger01.bas: 302: Expected lvalue: variable, pointer, or register, found end of line
so then I added the empty Parens and still got an error:::
RTC_update_time()
-ERROR C:/Coridium/Basic.mbd2/Examples/1768_event_logger01.bas: 302: Expected lvalue: variable, pointer, or register, found ()
**
it also screws up the else/endif according the the rest of the error messages - which is expected ; just FYI
*******
RTC_update_time is a labeled routine, grouped up in the Function/gosub area [ie. prior to Main: ]
it ends with a Return, but doesn't return a value - just updates some strings for time display & WAIT(998) for my timer.

Hello Basicchip,
I ran into problems when I moved my FUNCTIONS to a file that I "#include(d)" -->> see attached picture
This seems counter to your last reply/ code example in this link:
viewtopic.php?f=9&t=867&p=2757&hilit=CA ... 35ee#p2757
'
Your example appears to have the Function/Sub in the same file as "Main:"
'Using "ARMbasic[9.60c] on the PC Copyright 2021, Coridium Corp." BasicTools 6.40 on a ProStart
on Windows with Notepad++ editor
'
Any thoughts ??
Gary Olzeke51

Moved them Back into the file with 'Main:'

No more issues
Olzeke51

[edited] the 'translate' SUB - GOSUBed another SUB to print an error message ????
actually both of those did the GOSUB Errors(n) to print messages...
?? have to set a 'global variable' for the Error #, then
. do the GOSUB Errors(n) from the "Main:" ??

Would really need more context to answer this.

The example you site compiles and runs correctly.

There is a difference between a subroutine defined by LABEL1: ... RETURN and one defined by SUB LABEL2 ... ENDSUB

The LABEL1: ... RETURN can never have parameters, so CALL LABEL1 () would be illegal
And in this case you must use CALL or GOSUB

In the LABEL2 case, the compiler knows it is a SUBroutine and not just a label, so the following are all legal
LABEL2 subroutines must always be declared before their first use. That restriction does not apply to LABEL1 type subroutines. That is what I would guess your error is about.

Why so many syntaxes? Well in the original BASIC it was always something like GOSUB 120. Doing without line numbers means you need labels. And SUB --- ENDSUB comes along with other later BASICs. CALL, GOSUB or implied are available in many different modern BASICs.

RESOLVED ---
NOW I know what those 'guards' DO '
turns out BOTH of my support #includes had the same 'guard'
SO the second file got ignored for the final compile !!!! [and any of its SUBs]
'
must be a pre-processor function - there is no mention in the help file for 'guard'
'
THANK YOU, Basicchip for testing on your end
It only took about 3 hours, and 12 screen-capture of errors , and 6 extra 'testing' files [including your Blinky.bas}
'
Gary Olzeke51