Too many nested SELECT statements??

[Stuart]

This bit of code: (which is work in progress) is giving "Too many nested SELECT line 70". It gets executed whenever I click a button on the page, and I'm testing so do that a lot.

There are no other select statements in the program. Something is not getting taken off the stack perhaps, when the returns happen? If I knew the problem I could work around it.

What it does/will do eventually: The code has three modes, and three buttons switch between them. If in Manual mode then two other buttons do on and off.

Code: [Local Link Removed for Guests]

buttonEvent:
wlog "mode was: "+current_mode$
wlog "HtmlEventButton$: " + HtmlEventButton$
[line 70:] select case htmleventbutton$
case "Manual On"
  if current_mode$ = "Manual" then
    gosub relay_on
    wlog "refreshing page man on"
    jscall "location.reload();" ' refresh the page
  endif
  HtmlEventButton$ = ""
  return
case "Manual Off"
  if current_mode$ = "Manual" then
    gosub relay_off
    wlog "refreshing page man off"
    jscall "location.reload();" ' refresh the page
  endif
  HtmlEventButton$ = ""
  return
end select
if current_mode$ = htmlEventButton$ then 
  HtmlEventButton$ = ""
  return 
endif
'just left with mode changes
select case HtmlEventButton$
case "Manual"
  current_mode$="Manual"
case "Interval"
  current_mode$="Interval" 
  gosub check_interval
case "Daylight"
  current_mode$="Daylight"
  gosub check_daylight
end select
HtmlEventButton$ = ""
wlog "refreshing page"
jscall "location.reload();" ' refresh the page
return

[Electroguard]

If you interrupt any Annex code mid-routine before it has a chance to complete normally and keep its house in order, the new interrupt handler code will push the old unfinished remnants deeper until eventually lack of stack space causes the "too many'... " error.
Eg: when a new instance of Select Case is started before the previous instance completes normally with End Select.

I got around such problems by temporarily disabling interrupts before starting any code which needed to complete, then re-enabling interrupts again after completion.

I probably did something like that with the OLED Menu script which had 3 navigation buttons to read, both for the Menu, plus any 'Apps''...
[External Link Removed for Guests]

[Stuart]

Interesting. I'm not sure what interrupts you are thinking about, as the code has ample time to complete each time a button is pressed. The only other interrupts apart from the buttons would be a one second timer tick. But that would do its thing and exit leaving no trace. My conclusion is that a return in a select statement leaves stuff hanging. Coding with If statements has avoided the problem.

[bugs]

I found this effect back in 2019:-
[External Link Removed for Guests]

[cicciocb]

I think that the actual implementation of the SELECT command requires to pass through the END SELECT line to determine that the block is terminated.
I could eventually do a reset if the command return or exit sub is found

[bugs]

This is what I would do - just comment out the return statement(s) in the middle of the "select case" block and replace it with a flag - then check the flag after the select case has completed e.g.:-

Code: [Local Link Removed for Guests]

CODE: xxxx.bas

--------------------------------------------------------------------------------

true=1: false=0:  h$="Manual On":count=0
 
do   
  current_mode$ = "Manual"
   h$="Manual On"
  gosub workitout 
  count=count+1
  wlog count', ramfree     
loop

workitout:
  doreturn=false
  select case h$
    case "Manual On"
      if current_mode$ = "Manual" then
        'gosub relay_on        
      endif
      H$ = ""
      return			'****** comment out
      doreturn=true	'****** replace with flag
    case "Manual Off"
      if current_mode$ = "Manual" then
        'gosub relay_off       
      endif
      H$ = ""
     return			'****** comment out
      doreturn=true	'****** replace with flag
end select

  if doreturn=true then return
  
 'other code in here
return