link statement can't find the label

[hsfrey]

I've got more done in Run Basic in a couple of days (with your help) than in the prior several months of trying it in Java! ;D

(FYI: The program is a general rule evaluator using ternary logic.)

But, here's another little problem:

I adapted the link code from the 'calculator' example program, but when clicked, the link can't find the label, just a couple of lines below.

Here's the relevant section of the code:

call setCSS
''''much snipped out

function evalPred(ep)
''''much snipped out

'IF RULE POINTER IS NULL, ASK USER FOR ANSWER

if numPredsInRule = 0 then
[ask]
    cls    
div askpred
   print "Is it true that: ";predName$(ep);" ?" 
    print
   link #Y, "Yes", [yes] : link #N, "No", [no] : link #U, "I Don't Know", [unk]
   print : print
   link #H, "Help", [help] : link #Q, "Quit", [quit]

   #Y cssclass("myButton") : #N cssclass("myButton") : #U cssclass("myButton") : #H cssclass("myButton") : #Q cssclass("myButton")

 end div 'askpred
   wait

 [yes] 
    predRest(ep, prtruth) = cTRUE :    evalPred = cTRUE :    goto [done]

 [no] 
    predRest(ep, prtruth) = cFALSE : evalPred = cFALSE: goto [done]

 [unk] 
    predRest(ep, prtruth) = cUNKNOWN : goto [pass1]

 [help] 
    if predRest(ep, prexp) <> 0 then
        print text$(predRest(ep, prexp))
    else
        print "Sorry, no explanation is available"
    end if   
    goto [ask]

  [quit]
    end  'abort 

end if
''''''''much snipped out
end function 'evalPred
''''much snipped out

sub setCSS

   cssid #askpred, "{ background: #CCF; width: 590px; height: 200px; padding: 16px }"

   cssclass "a.myButton", "{ font-size: 20pt; width: 60px; height: 30px; display: block; float: left; background: #EEF; text-align: center }"

   cssclass "a.myButton:hover", "{ background: #FFF }"

end sub 'setCSS

when I click on the 'Yes' button, for example, I get a run-time error which says that it can't find the label [yes].

I want to grab it and say "Hey Look, it's right on the NEXT line!"

I know you can't run it, since it's too long to include in its entirety, but Is there something obvious I've overlooked?

[Janet]

It's usually not a good idea to include branch labels inside subs and functions. The [yes], [no], and [help] seem okay, but then they lead to GOTO's to either [done] or [pass1]. I don't see those branch labels inside the function. If they are outside the function, then they can't be seen inside the function. Its an issue of global vs local. Can you rewrite the program so that links lead to links without the use of a function? - Or, give the function a return value, and then, based upon the return value, GOTO the links.

[hsfrey]

Thanks for the response Janet!

All those labels (done, pass1, etc.) are in the same function, evalPred.

They were part of the code I snipped to save space.

And the error messages say that the run-time engine can't find the labels in the LINK statements, i.e. [yes], [no], etc., which are directly below, in the same function.

I'm afraid I'll have to back to an old-fashioned inelegant multiway branch. (Which is what I had working before, before I tried to "prettify" it.)

[Carl Gundel - admin]

In Run BASIC, a WAIT statement inside a SUB or FUNCTION actually stops and waits and it dumps you back out to the outermost scope. This is different from Liberty BASIC.

That's the reason why it can't find the branch labels, because you're not in the FUNCTION anymore.

-Carl

[hsfrey]

Carl:

Aha! That's surely the problem!
So, is that a Bug or a Feature? ;D

And, does that mean, since it always requires a wait, that the link method can't be used within any function?

It would be especially hard for this program to put the links at the highest level, outside of all functions, since the routine calls itself recursively.

[carlgundel]

May 7, 2008 16:17:17 GMT -5 hsfrey said:

Carl:

Aha! That's surely the problem!
So, is that a Bug or a Feature? ;D

And, does that mean, since it always requires a wait, that the link method can't be used within any function?

Sure you can, but you must put the routines outside of the function.

It would be especially hard for this program to put the links at the highest level, outside of all functions, since the routine calls itself recursively.

Well, that is a problem since you cannot have recursive calls and use WAIT in that way.

Could you build a stack based version of your program?

-Carl

[StefanPendl]

How about using a module, would that make any difference

[hsfrey]

Carl:

>Could you build a stack based version of your program?<
Ooh - that would be pretty difficult. I'd have to push an awful lot of variables at each iteration.

What about, apart from the problem of CPU usage, I replaced the "wait" with a polling loop? Is there some way to query whether a button has been clicked, without having the "wait"??

[Carl Gundel - admin]

May 7, 2008 20:29:14 GMT -5 hsfrey said:

Carl:

>Could you build a stack based version of your program?<
Ooh - that would be pretty difficult. I'd have to push an awful lot of variables at each iteration.

What about, apart from the problem of CPU usage, I replaced the "wait" with a polling loop? Is there some way to query whether a button has been clicked, without having the "wait"??

You cannot have a polling loop. The web browser doesn't return a page to the user until a WAIT or INPUT statement, or until the program ends.

Perhaps in a future version Run BASIC might be able to do something fancy like that using Ajax techniques, but I haven't got that figured out.

Do you understand what I mean when I say stack based?

-Carl

[hsfrey]

Carl:

What I was thinking of was using setkey() for each key, and then checking EventKey$() in the polling loop, and branching appropriately from there. Perhaps I could lower the program's priority, so it wouldn't lock everything else out while the user is scratching his head.

Are you saying that won't work?

By "stack-based" I assumed you mean that I would push the relevant environment onto a home-made stack before calling the subroutine, and pop it when I'm done. I used to do such things in the old days, before programming languages had recursive calls.

I hope you don't mean getting involved with the system stacks! I don't think I'm up to that!

[hsfrey]

Carl:

OK, I'm answering myself! ;D

I tried the following program to avoid the "feature" in the wait command that prevents you from branching to a label in a subroutine:

call tryit

sub tryit
div askpred
   print "click a button" 
    print
   link #Y, "Yes", [yes] : link #N, "No", [no]
   print : print
 end div 'askpred
   #Y setkey("Clicked YES")
   #N setkey("Clicked NO")
 wait
[loop]
 if EventKey$ <> "" then
   print "EventKey$ = ";EventKey$
   goto [done]
 end if
goto [loop]

 [yes] 
    print "Got to Yes" : goto [done]
 [no] 
    print "Got to NO" : goto [done]
  [done]
    print "got to [done]"
    end  'abort 
end sub

It works without the 'sub', but not if it's in the 'sub', just like the problem I had originally.

Omitting the wait prevents all output from being displayed until the loop times out.

Is this problem of being unable to use "wait" in a subroutine something that you are considering fixing?

Or is there some reason that this behavior is desirable?

[Carl Gundel - admin]

As I explained, this is how it is meant to work. Is it a requirement that you write you program this way, or just a preference?

Could WAIT be made to work differently? Yes perhaps. I don't have any short term plans to change it.

-Carl

May 8, 2008 17:20:37 GMT -5 hsfrey said:

Carl:

OK, I'm answering myself! ;D

I tried the following program to avoid the "feature" in the wait command that prevents you from branching to a label in a subroutine:

call tryit

sub tryit
div askpred
   print "click a button" 
    print
   link #Y, "Yes", [yes] : link #N, "No", [no]
   print : print
 end div 'askpred
   #Y setkey("Clicked YES")
   #N setkey("Clicked NO")
 wait
[loop]
 if EventKey$ <> "" then
   print "EventKey$ = ";EventKey$
   goto [done]
 end if
goto [loop]

 [yes] 
    print "Got to Yes" : goto [done]
 [no] 
    print "Got to NO" : goto [done]
  [done]
    print "got to [done]"
    end  'abort 
end sub

It works without the 'sub', but not if it's in the 'sub', just like the problem I had originally.

Omitting the wait prevents all output from being displayed until the loop times out.

Is this problem of being unable to use "wait" in a subroutine something that you are considering fixing?

Or is there some reason that this behavior is desirable?

[hsfrey]

Carl:

>Is it a requirement that you write you program this way, or just a preference?<

It's just that recursion seems like the most convenient way to do the same thing at different levels of a self-similar structure.

But, if I understand you correctly, Run Basic will always force the link/wait construct in ANY subroutine to branch back to the main level, making it impossible to link to a label within the same subroutine.

I'm sure you have your reasons, but I fail to see why this is a desirable behavior.

Anyway, I got my program to work by dumping the link/wait construct and going back to the old DOS way of doing things - input a character and branch on it.

[Carl Gundel - admin]

I agree that it would be desirable for Run BASIC to be able to do what you're trying to do, but there are some technical issues with it. Perhaps I will be able to overcome those, but as I said I have no short term plans to do so.

-Carl

May 9, 2008 1:03:52 GMT -5 hsfrey said:

Carl:

>Is it a requirement that you write you program this way, or just a preference?<

It's just that recursion seems like the most convenient way to do the same thing at different levels of a self-similar structure.

But, if I understand you correctly, Run Basic will always force the link/wait construct in ANY subroutine to branch back to the main level, making it impossible to link to a label within the same subroutine.

I'm sure you have your reasons, but I fail to see why this is a desirable behavior.

Anyway, I got my program to work by dumping the link/wait construct and going back to the old DOS way of doing things - input a character and branch on it.

[hsfrey]

Carl:

>there are some technical issues<

Yes, I can certainly understand that! You've done a remarkable job with Run Basic, and it would be odd if there weren't some technical issues left. I wish you the best as you continue to improve it.