![]() |
|
Illegal string-number conversion - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3) +---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10) +---- Thread: Illegal string-number conversion (/showthread.php?tid=3792) |
Illegal string-number conversion - Herve - 07-02-2025 Hello, I am new to this forum and also to using QB64PE. Here is a piece of code that causes the following error. Could you tell me what is wrong? Illegal string-number conversion Caused by (or after):GLOP . ELEMENT . S = "Home",4 LINE 15:glop.element.s = "Home" Code: (Select All) type SomeTypeRE: Illegal string-number conversion - Jack - 07-02-2025 use Dim Shared glop As OtherType RE: Illegal string-number conversion - Herve - 07-02-2025 Thank's a lot ! RE: Illegal string-number conversion - TempodiBasic - 07-05-2025 @Herve welcome it is an interesting glitch of parser ![]() ![]() ![]() Code: (Select All)
In Lubuntu and QB64pe 4.1.
RE: Illegal string-number conversion - eoredson - 07-06-2025 btw: before you even get into it, this cannot be done: Code: (Select All) Type StructWish I knew who is currently working on them now!? However you can make an array of a UDT such as: Code: (Select All) Type StructRE: Illegal string-number conversion - Herve - 07-06-2025 @TempodiBasic We can also see this on the page https://qb64phoenix.com/qb64wiki/index.php/Variable : "Variables in QB64 can be any name except the names of QB64 or QBasic keywords and may not contain spaces or non-alphabetical/non-numerical characters (except "." and "_"). Numerical characters cannot be used as the first character of a variable or array name! QB64 reserves the use of a leading underscore to QB64 procedural or variable type names only!" I notice that with OPTION _EXPLICIT we no longer get “Illegal string-number conversion” but instead: “Variable ‘glop__ASCII_CHR_046__w__ASCII_CHR_046__element__ASCII_CHR_046__i’ (SINGLE) not defined” I will now prefer using an underscore instead of a dot when naming variables; by using the dot exclusively for variables in a UDT, I’ll avoid triggering the parser bug. And from now on, I’ll be using OPTION _EXPLICIT. RE: Illegal string-number conversion - TempodiBasic - 07-06-2025 Hi @Herve yeah there must be something to define and rule, the first image about rules for naming a variable it has been taken from a online tutorial about Qbasic. I dunno if in Qbasic and in QB4.5 the DOT is allowed out of UDT's name reference in the code. and I totally agree that Option _Explicit is a handy wonderful tool! RE: Illegal string-number conversion - a740g - 07-07-2025 IMO, it would be a nice to have an option under Options > Compiler Settings to enable Option _Explicit behavior by default. The QB64-PE compiler already supports this via the -e switch, so the functionality exists. Many modern BASIC IDEs provide a similar setting, allowing users to enforce explicit variable declarations as a project-wide preference. |