ReadStringFormat() - PB 4.4

[srod]

Hi,

just an observation really.

The values of #PB_Ascii and #PB_Unicode have changed since PB 4.31. This caused one of my programs to break which took a long time to figure out why? I always relied upon ReadStringFormat() returning a value in which #PB_Ascii was the highest value supported by PB's ReadString() command and it is this which caught me out!

Just posting as a warning to others and to ask why this was changed? Just out of curiosity you understand!

[Rescator]

Well, what you did was bad programming practice, relying on a behaviour that didn't exist.
I really doubt that the values are enumerations, just plain constants? (looks at Fred)
Now that I think about it, I don't think any PB built in constants/flags are enumerated at all, maybe a note should be put in the manual about this?
Hmm, actually the OSVersion ones are the only ones I can think of that seem enumerated in some way.

[srod]

Yes I agree; bad practice, though it made for more efficient code at the time. I did not hard code the values if that is what you are thinking; I just had a line similar to : If StringFormat <= #PB_Ascii... etc. It is because the ordering of the values in question changed which caught me out.

I just didn't expect these constant values to change - a foolish assumption I know, but, well, not an entirely unreasonable one I reckon.

All said and done, the problem is resolved; I was just left wondering why the values have changed - having a naturally inquisitive mind and all?

[freak]

> I was just left wondering why the values have changed - having a naturally inquisitive mind and all?

#PB_Ascii and #PB_Unicode now also represent the .a and .u type for functions like Bin(), StrU() etc, and there was a colision with the constant for another type.

[srod]

Ah, yes that makes sense.

Thanks; curiosity satisfied!