Change in CHOOSE behaviour between 8151 and 11586 (Android) (KNOWN)

[StephenG1CMZ]

Version 0.3 of my Z_LIGHTS program exhibited different behaviour on 8151 and 11586 (both on Android).

In both systems, the behaviour documented in the on-device help is that if the user cancels a selection without choosing a selection, 0 is returned in the CHOOSE variable.

That was the behaviour observed in 8151, where Version 0.3 of Z_LIGHTS worked as expected.
In 11586 however, the previous value in the CHOOSE variable is repeated.

A workaround for this changed behaviour is incorporated in Z_LIGHTS V0.4.

Is this change intended (in which case the on-device help needs clarification)?

[StephenG1CMZ]

This change in behaviour has previously been noted here:
http://www.hpmuseum.org/forum/thread-718...ght=CHOOSE

I raised it again because I asked about why there was a problem with Z_LIGHTS V0.3, before narrowing down the cause to a CHOOSE, and re-discovering its change in behaviour.

[Carlos295pz]

Your algorithms are entangled, the general way to use CHOOSE would be something like that for the EXPORT Z_LIGHTS()

Code:

EXPORT Z_LIGHTS()
 BEGIN
  LOCAL CHS; //,OK;♣

  //REPEAT ♣
  // OK:=CHOOSE(CHS,CRID,CHOICES); ♣
  WHILE CHOOSE(CHS,CRID,CHOICES) DO

   //IF OK THEN //WORKAROUND ♣
    CASE  
     IF CHS==1 THEN HELP   END
     IF CHS==2 THEN INFO   END
     IF CHS==3 THEN LIGHTSTEADY END
     IF CHS==4 THEN LIGHTCOLR   END
     IF CHS==5 THEN LIGHTBLINK  END
     IF CHS==6 THEN LIGHT_SOS   END
     IF CHS==7 THEN ASK_WPM     END
     //DEFAULT ♣
    END;//CASE
   //END;//IF ♣

  //UNTIL OK==0;//WORKAROUND ♣
  END; //WHILE

 END;

Implement it like this in the other selection loops

[Tim Wessman]

Hello,

The behavior as implemented is correct and has now been in force longer then the "original" I believe. The less disruptive thing to do is just tweak the help to make it a bit more clear.