Latest update kills Entry Mode Switcher

[jgreenb2]

The latest firmware seems to have a broken Cristóbal De Jesús's brilliant little entry mode switcher:

Code:


// Cycles over entry mode options. 
KEY K_On() 
BEGIN 
LOCAL an:={"Textbook","Algebraic","RPN"}; 
Entry:=(Entry+1)MOD3; 

STARTVIEW(-8,1); // Out to ANY AVAILABLE view... 
STARTVIEW(-1,1); // ... and back in, to refresh 

TEXTOUT_P(an(Entry+1),G0,2,207,2,RGB(255,0,0)); 
END;

This is one of the most useful programs I've ever found (thanks to Cristobal, a thousand times over!) but it doesn't quite work the same since the update. It actually does switch modes but the mode label (e.g. TEXTOUT_P(an(Entry+1),G0,2,207,2,RGB(255,0,0)); ) is cleared as soon as it's written to the screen. You can see the labels very briefly but then the screen is cleared and they disappear. The virtual calculator has the same issue.

Any insight into why the text no longer appears?

[StephenG1CMZ]

This might be similar issue as thread "10077 and RECT_P"?

[jgreenb2]

Any other thoughts?

[DrD]

You can see the entry mode longer by adding a delay after TEXTOUT_P():

WAIT(n); // See Help for options

-Dale-

[Terje Vallestad]

(04-30-2016 12:13 AM)jgreenb2 Wrote:  Any other thoughts?

As I tend only to switch between RPN and textbook, I have the following key assignment

Code:


KEY K_On()
BEGIN
  IF Entry == 0
    THEN Entry:=2
    ELSE Entry:=0; 
END;
END;

Cheers, Terje

[jgreenb2]

(04-30-2016 09:56 AM)DrD Wrote:  You can see the entry mode longer by adding a delay after TEXTOUT_P():

WAIT(n); // See Help for options

-Dale-

Thanks, that's actually really close to what I need. 300ms is a better delay and WAIT is too coarse. But spinning for a bit doesn't seem to hurt anything:

Code:


// Cycles over entry mode options. 
KEY K_On() 
BEGIN 
LOCAL an:={"Textbook","Algebraic","RPN"}; 
Entry:=(Entry+1)MOD3; 

STARTVIEW(-8,1); // Out to ANY AVAILABLE view... 
STARTVIEW(-1,1); // ... and back in, to refresh 

TEXTOUT_P(an(Entry+1),G0,2,207,2,RGB(255,0,0)); 
waitms(300);
END;

Code:


EXPORT waitms(ms)
BEGIN
  local T0;
  T0 := TICKS;
  while (TICKS-T0) < ms DO
  end;
END;

[DrD]

The upshot of the problem is that a delay (of some sort) is necessary to "see" the TEXTOUT_P output.

Showing the change isn't absolutely necessary, because the change is immediately shown in the [Shift] [HOME] corresponding setting. It can be detected programmatically, using the Home Settings "Entry" variable, or directly via the command line, making the switcher program even more compact!

-Dale-

[Tim Wessman]

(04-26-2016 02:53 AM)jgreenb2 Wrote:  Any insight into why the text no longer appears?

The text no longer appears because there was never any code to ensure that the text ever would be visible. When you draw to the screen, you need to either do some sort of wait, or use the FREEZE command to avoid the next screen draw.

I believe that when the inner display loop was cleaned up and improved it was now fast enough that your text basically "disappeared" due to having the next screen draw happen.

Adding FREEZE will make the text stay until you do something else. WAIT can be any value - not just integers. WAIT(.3) would be completely valid.

Since TEXTOUT now returns the last X position "drawn" on the text, you could possibly get unexpected behavior due to evaluating that number as a "key". So now you probably want to return a specific number such as -1 (otherwise you may get an unexpected key executed).

Code:

// Cycles over entry mode options. 
KEY K_On() 
BEGIN 
LOCAL an:={"Textbook","Algebraic","RPN"}; 
Entry:=(Entry+1)MOD3; 

STARTVIEW(-8,1); // Out to ANY AVAILABLE view... 
STARTVIEW(-1,1); // ... and back in, to refresh 

TEXTOUT_P(an(Entry+1),G0,2,207,2,RGB(255,0,0)); 
WAIT(.3); //wait 300ms
-1; // return an invalid key number to ensure nothing else happens
END;

[jgreenb2]

Tim,

Much obliged, thanks!

-- Jeff