https://qb64phoenix.com/forum/showthread...66#pid9266
This thread exists because I didn't want to reply to that post, and I selfishly didn't want to post on the dedicated thread about the subject.
Good job with this project, surprised that it's as deep as it is in such a short time. Normally I don't like stunts done by clunky web browsers but this interested me. I visited the page on Github to learn about support for QB64(PE) keywords. These are just my observations.
A few other things:
Sub parameters are passed only by value: this is one reason why I'll have difficulty with this package. LOL I like using "SUBs" instead of "FUNCTIONs" to return values, especially more than one value since I also like to program in Lua.
"GOSUB... RETURN" not supported: yeech!
Function return could be array, associative arrays support: don't need unless the above two are fixed!
Errm... I understand the tendency toward Visual Basic, but I guess this isn't for converting programs created before M$ came up with that product. No spaghetti code allowed! Also give them no choice with "OPTION _EXPLICIT" always enabled. Some people with bad habits made by Q(uick)BASIC are going to be alienated, however.
As I've said, these are just observations (opinions).
This thread exists because I didn't want to reply to that post, and I selfishly didn't want to post on the dedicated thread about the subject.
Good job with this project, surprised that it's as deep as it is in such a short time. Normally I don't like stunts done by clunky web browsers but this interested me. I visited the page on Github to learn about support for QB64(PE) keywords. These are just my observations.
- "COMMAND$" - not even a special "global" dialog to put in its value? Some programs depend on this, including all-uppercase return value, and it might be difficult to change away from it. Might not have to worry a lot about "COMMAND$(1)" or alike. OTOH Linux is very lame about this sometimes, limiting terminal command line to a maximum of 255 characters.
- "IF... THEN" - clarify that it has to be "IF (condition) THEN GOTO (linenum/label)", or "GOTO" cannot be used at all? (OK discovered below "GOTO" and labels aren't even supported.) Does this mean only block "IF" could work? No problem for me but some old programs would need extensive revision then, you know how much colons were loved back then...
- "LOCATE" - does this mean changing the cursor shape? Because this is a bit sad this day and age. I mean in graphics mode "druw yer own kersair for krissakes"...
- "OPEN FOR RANDOM AS" - this should be easy to implement one way. "TYPE... END TYPE" is supported, am I correct? It must have to do with a security issue. Entire files could be "dowloaded" which isn't as useful to me and I could never get to grips with Internet functionality in QB64PE.
- "SELECT CASE" - what is "EVERYCASE"? Do you mean "CASE ELSE"? Must be Visual Basic tendency.
- "TIMER" - a few QB64 programs will be broken because of this. So this might mean the QB64-only edition of "ON TIMER" isn't supported neither.
- "_MOUSEINPUT" - LOL so this is like being on a Macintosh.
- "_OS$" - I think this should work like in normal QB64, some programs depend on this information and don't use the preprocessor.
A few other things:
Sub parameters are passed only by value: this is one reason why I'll have difficulty with this package. LOL I like using "SUBs" instead of "FUNCTIONs" to return values, especially more than one value since I also like to program in Lua.
"GOSUB... RETURN" not supported: yeech!
Function return could be array, associative arrays support: don't need unless the above two are fixed!
Errm... I understand the tendency toward Visual Basic, but I guess this isn't for converting programs created before M$ came up with that product. No spaghetti code allowed! Also give them no choice with "OPTION _EXPLICIT" always enabled. Some people with bad habits made by Q(uick)BASIC are going to be alienated, however.
As I've said, these are just observations (opinions).