A Perplexing Issue

[NakedApe]

This sub took me hours to get going because it's behaving so strangely. It's a simple routine to print out some info, but it won't work unless an INPUT statement is used at the end, not an INPUT$() or INKEY$. Even SLEEP causes the sub not to run right. My first choice is for the user just to press a single key and exit the sub, but only the input statement works right - which requires a carriage return. I don't get it. Any help will be much appreciated! See remarks below...

SUB destTable () '

    SHARED destData() AS STRING
    SHARED destCounter AS INTEGER
    SHARED fuel AS SINGLE
    DIM range AS SINGLE
    DIM AS INTEGER counter, entry, entries(20) '
    DIM n AS STRING

    range = fuel / 35.29 '          fuel / rate of burn per light year
    counter = 0

    _FONT messFont: COLOR YELLOW
    n = _TRIM$(MID$(STR$(range), 1, 5))
    _PRINTSTRING (30, 40), "Destinations Within Present Range" + "  (" + n + " Light Years)"

    DO
        counter = counter + 1
        IF range >= VAL(destData(counter, 3)) THEN '    if range is greater than distance to destination...
            entry = entry + 1
            entries(entry) = counter
            _FONT messFont: COLOR ORANGE
            _PRINTSTRING (30, 66 + entry * 25), CHR$(64 + entry) + ") " + destData(counter, 1) '
            _FONT courseFont: COLOR GREEN
            _PRINTSTRING (340, 70 + entry * 25), destData(counter, 2)
            _FONT courseFont: COLOR PINK
            _PRINTSTRING (580, 72 + entry * 25), destData(counter, 3) + " Light Years"
        END IF
    LOOP UNTIL counter = 20

    _FONT messFont: COLOR YELLOW
    _PRINTSTRING (40, 138 + entry * 25), "Your Destination Choice is"
    LOCATE 30, 344
    INPUT n '          <======= !!                           reuse n string
    ' n = INPUT$(1) '                                                ALL THESE REMMED COMMANDS CAUSE THE ABOVE NOT TO DISPLAY TO SCREEN
    ' WHILE INKEY$ = "": n = INKEY$: WEND '           UNTIL *AFTER* USER PRESSES A KEY
    ' DO: n = INKEY$: LOOP UNTIL n <> "" '              only an INPUT statement gets the above table to print ...
    ' SLEEP                                ... otherwise program freezes w/o performing above code until key is hit, then the table appears for a sec
    counter = ASC(n) - 96 '                                        reuse counter
    destCounter = entries(counter) '
    pickDest

END SUB

[TerryRitchie]

My first guess is that you may have a _DISPLAY statement somewhere else in your code affecting screen output. Try placing an _AUTODISPLAY command where you have INPUT n. If this is the case then the INPUT statement is somehow over-riding this and may need to be looked into (a bug?).

[NakedApe]

My first guess is that you may have a _DISPLAY statement somewhere else in your code affecting screen output. Try placing an _AUTODISPLAY command where you have INPUT n. If this is the case then the INPUT statement is somehow over-riding this and may need to be looked into (a bug?).

Brilliant. I shoulda figured that out... Thanks, Terry! That was the issue. _AUTODISPLAY fixed it, so _DISPLAY may have an issue with INPUT.

Thanks again. 

[TerryRitchie]

My first guess is that you may have a _DISPLAY statement somewhere else in your code affecting screen output. Try placing an _AUTODISPLAY command where you have INPUT n. If this is the case then the INPUT statement is somehow over-riding this and may need to be looked into (a bug?).

Brilliant. I shoulda figured that out... Thanks, Terry! That was the issue. _AUTODISPLAY fixed it, so _DISPLAY may have an issue with INPUT.

Thanks again. 

Happy I could help

This same thing happens to me every time I write a new game. At some point I lose track of where _DISPLAY is controlling screen output and eventually expected screen updates don't happen. 99% of the time when output acts strange or doesn't happen when expected I always start with tracing my _DISPLAY and _AUTODISPLAY statements. _DEST can also be another reason for unexpected output, with the output going to a different image canvas than expected. If my _DISPLAY statements look fine then I starting tracing _DEST and _SOURCE.

I was thinking about INPUT and how it was affecting your output. After some thought I suppose it makes sense that INPUT would force a _DISPLAY otherwise the user would never see the input prompt. Perhaps not a bug but intended?

[NakedApe]

My first guess is that you may have a _DISPLAY statement somewhere else in your code affecting screen output. Try placing an _AUTODISPLAY command where you have INPUT n. If this is the case then the INPUT statement is somehow over-riding this and may need to be looked into (a bug?).

Brilliant. I shoulda figured that out... Thanks, Terry! That was the issue. _AUTODISPLAY fixed it, so _DISPLAY may have an issue with INPUT.

Thanks again. 

Happy I could help

This same thing happens to me every time I write a new game. At some point I lose track of where _DISPLAY is controlling screen output and eventually expected screen updates don't happen. 99% of the time when output acts strange or doesn't happen when expected I always start with tracing my _DISPLAY and _AUTODISPLAY statements. _DEST can also be another reason for unexpected output, with the output going to a different image canvas than expected. If my _DISPLAY statements look fine then I starting tracing _DEST and _SOURCE.

I was thinking about INPUT and how it was affecting your output. After some thought I suppose it makes sense that INPUT would force a _DISPLAY otherwise the user would never see the input prompt. Perhaps not a bug but intended?

Re: INPUT forcing _DISPLAY, I'm glad it works that way - otherwise I would've gone totally crazy. In hindsight I'd say it's intentional bwdik!

[OldMoses]

Here's a goofy thing that I sometimes do in subroutines, since my programs are almost always using _DISPLAY somewhere:

IF NOT _AUTODISPLAY THEN _DISPLAY