String handling

[Tom]

Is any one else encountering the same problem as i am having with strings?

the statement A$=“Qt” for example which does not result in a 2 byte string, but 3 bytes
where the first byte is a graphic character (cant input it, but it is a circlle with a small square within it) that represents the shift key!! This left shift! Right shift is the same although the graphic is different.

This character is injected each time shift is used within the assignment!

eg A$=“Qt” results in “?Qt” where ? is the graphic!!
also A$=“Qt Nw” results in “?Qt ?Nw”

Have reported it, but no response from Clockwork yet, just wanted to see if others have seen it? Havnt yet tried updating the image yet to see if it goes away,just using the image
on the supplied sd card!

Thanks

Tom Connell

[wezm]

Typed into the PicoCalc directly I don’t see this behaviour on mine.

[adcockm]

I also didn’t see this when I edited code on the PicoCalc.

If you’re editing it over serial connection, maybe something weird is going on with your software on the host?

[Tom]

No I am using the picocalc standalone!!!

[DigitalDreams]

Using the older basic supplied with the PicoCalc ?. Will say something like ‘MMBasic Version 5.09. Copyright 2024’. There is now a ‘Version 6.00. Copyright 2025’ with many bug fixes…

Anybody have interesting to compile firmware for RP2350 / pico2?

here is new PicoMite uf2 file for pico2 based from github issue: welcome to test if you have pico2 or pico2w

[thwill]

I don’t recall anyone having ever reported anything similar with the non PicoCalc versions of the PicoMite.

Best wishes,

Tom

[rlauzon]

I can’t reproduce this behavior on my PicoCalc.

a$="Qt"
print len(a$)

displays “2”

Now, that said, I wrote a quick test program to get the key codes for a program I was doing

a1:
a$=inkey$
if a$="" then goto a1
print asc(a$)
goto a1

If you run this, you will see that the shift keys have codes, which is unexpected. Ctrl and Alt do as well.

[Tom]

Hi, Having decided this morning to revisit the picocalc I have discovered the problem has dissappeared!!!

Strings are now working normally!! Nothing has been changed except that I took it apart for a visual check and removed and replaced the board!!

Maybe something wasnt quite seated right??

Whatever it seems I am good to go!!

Thanks for the thoughts!!!

Tom Connell

[white-round-square]

@Tom

Thanks for the thoughts!!!

best possible approach:

can’t reproduce, issue closed

[rlauzon]

So this problem bit me today when writing a program. Here’s a small program to show it off:

input “test string”;a$:print
print a$
for i = 1 to len(a$)
print asc(mid$(a$,i,1))
next i

Enter something like “12:34”. You will see that an extra character, which looks like it represents the Shift key, is inserted into the string. It is not displayed in the INPUT, but is displayed in the print and shows up when the ASCII codes for the characters are displayed.

Both shift keys exhibit this “problem” and I’ve tried it with other “shift” characters too (@, #, $, etc.) with the same results.

But it seems to only happen when using the INPUT statement.
A$=“Qt” does not exhibit the problem. Perhaps the EDITor removes them.

[Toml_12953]

@rlauzon

input “test string”;a$:print
print a$
for i = 1 to len(a$)
print asc(mid$(a$,i,1))
next i

I get no extra characters:

12:34
 49
 50
 58
 51
 52

[Tom]

OK AS I said it just disappeared for me! All I did is to open it up and made sure the pico was properly seated and checked the display cable! I am sure neither of those would have directly affected the problem, but maybe something else was not quite right and opening it up rectified it???

A mystery!!!

Tom Connell

[rlauzon]

A “Phase of Moon” bug. The worst kind.

How much do you want to bet that if I ran that same little program now, it would work fine?

[DigitalDreams]

@Tom

OK AS I said it just disappeared for me! All I did is to open it up and made sure the pico was properly seated and checked the display cable! I am sure neither of those would have directly affected the problem, but maybe something else was not quite right and opening it up rectified it???

A mystery!!!

Tom Connell

We used to call that “a Murphy”

[rlauzon]

I would have lost my bet.

So I’ve been firing it up and running my test periodically. It’s very consistent.

On a whim, I replaced INPUT with LINE INPUT and the same thing happened.

[cjstoddard]

Interesting, I actually noticed this with another program I was working on a couple of days ago and was ignoring it.

[rlauzon]

a$ = InputString("Test string")
print a$
for i = 1 to len(a$)
    print asc(mid$(a$,i,1))
next i

function InputString(prompt$) as String
    local r$="", b$, i, m$

    print prompt$;
    input b$:print

    for i = 1 to len(b$)
        m$ = mid$(b$,i,1)
        select case asc(m$)
            ' Left shift, right shift, ctrl, alt
            case 162, 163, 161, 165
               m$=""
        end select

        r$=r$+m$
    next i

    InputString = r$
end function