JavaScript-ing it, I need to get with it

[CharlieJV]

SELECT CASE moves the program flow through just one condition in the block. SELECT EVERYCASE moves your program flow through every case in the block that is true. SELECT EVERYCASE is therefore useful during some instances where the coder would otherwise need to add more conditional statements to handle all possible conditions.

Pete

Well crap.  EVERYCASE means every case.  Dammit.

Whereas SELECT CASE means "JUSTTHEONECASE".

I knew I should have skipped this morning's dose of stupid pills.  They really should only be taken on an empty brain...

Embarrassingly, thanks?

[Pete]

I'm not comfortable with other people calling themselves stupid; 'cuz that's my job 'round these parts!

No worries. There are days I feel like I'm on a full I.V., and it ain't set to slow drip, either.

Isn't cool though that folks around these parts just talk stuff out instead of snubbing each other? I kid a lot, sure, but I do mean that sincerely.

Oh, I gave you a +2 for the demo link to your website project. That was a blast. I like the possibilities the future holds more and more now.

Pete

[CharlieJV]

I'm not comfortable with other people calling themselves stupid; 'cuz that's my job 'round these parts!

No worries. There are days I feel like I'm on a full I.V., and it ain't set to slow drip, either.

Isn't cool though that folks around these parts just talk stuff out instead of snubbing each other? I kid a lot, sure, but I do mean that sincerely. 

Oh, I gave you a +2 for the demo link to your website project. That was a blast. I like the possibilities the future holds more and more now.

Pete

Back in '95, I became a third body thrown on a project that was over budget and late delivering.  I became the third programmer, working with two functional analysts, a technical architect (and dba), and a project manager (Bob.)  The other two programmer's had become so frustrated with the analysts who had last programmed in Cobol and were now dictating how to do windows 4GL programming, that the programmer's took an empty pill bottle, labelled it "Doctor Bob's Stupid Pills" with a side label warning to only take on an empty brain, and made sure it was always in a prominent location.  (I kept that bottle.)

Yeah, at that age of having a story for everything...

Snubbing others?  That's like eating plain/bland white mushy rice full-time.  Totally missing out on the sweet/salty/spicy/fatty/sour/bitter (all of my food groups), baby.  Much like my philosophy: some people live to eat, some people eat to live.  I. Eat. To. Die !  How could I snub any of that?

Love TiddlyWiki and love BASIC and love massive/complicated/intertwingled problems/projects.  The project exists because of the the original desire of getting QB64 programs running in web browsers.  When QBJS popped up in March, that was my incentive to get in a different lane and focus more on all aspects of the software development process, project management, requirements management, source code management and documentation for BASIC projects (QB64PE as first-class citizen.)  Well, I have other goals for BAM, but they aren't QB64PE-specific, so not talking about those here.

[Pete]

ROFL @ Dr. Bob Stupid pills story. Do they come in chewables?

Pete

[CharlieJV]

ROFL @ Dr. Bob Stupid pills story. Do they come in chewables?

Pete

Damned thing was empty by the time I got there.

Thinking back about the source code, I will forever remember this comment placed very deep in there:  "totally non-standard way to implement [blank], see my analyst."

[blank] being some throwback screen design from cobol days instead of standard Windows application design of the day.

[dbox]

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.

Thanks for the feedback @mnrvovrfc.  As this is still a work in progress a lot of these items that marked as not supported really just mean they are not supported yet.

"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.

This is one of those in the "not yet" category.  There is not a direct web equivalent, so I've held off on implementing this one yet.  I have thought about adding an optional parameter that could be added to the URL that would allow you to specify pseudo command-line arguments.

"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...

Yeah, admittedly GOTO is problematic to convert to Javascript with the approach we've taken.  Because the source is converted to JS (much in the way QB64 converts basic to C) we can take advantage of the JS engine optimizations and Just-In-Time (JIT) compilation.  In many cases this allows us to have performance on-par with native.  I'm still looking into how this could feasibly be accomplished without negatively impacting performance.

"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"...

I'm not sure what this one is in reference to.

"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.

The hard part for this was completed in 0.6.0 (which we just released).  Now that the virtual filesystem is in place this will not be too difficult to add.  Plus, we have already implemented support for BINARY mode which is very similar.  This was just a case of finding a place to stop to get another release out.

"SELECT CASE" - what is "EVERYCASE"? Do you mean "CASE ELSE"? Must be Visual Basic tendency.

I think this one has been pretty extensively covered in this thread.

"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.

I assume this is in reference to the accuracy parameter not being supported.  This is definitely in the not yet category.  The variation of ON TIMER which calls a SUB can be added relatively easily.  The variation which calls GOTO or GOSUB is more challenging for the same reasons I mentioned above.  This is more in the never say never but don't expect it soon category.

"_MOUSEINPUT" - LOL so this is like being on a Macintosh.

We're planning mouse wheel support for the next release.  I think this is @vince's most requested feature (aside from full WebGL support).

"_OS$" - I think this should work like in normal QB64, some programs depend on this information and don't use the preprocessor.

I'm interested in additional thoughts on this.  Support for this method was added with interoperability in mind.  Instead of returning OS as the first value in the string we are returning [WEB] so that you could know programmatically that the program was running in the browser when platform-specific logic is needed.

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.

Yeah, this may be one area where my personal preferences have bled through a bit.  I think passing parameters by value is a better default mode (especially for beginning programmers).  This also happens to be the default for JS methods as well.  Translating methods to pass-by-reference would require a good deal of additional generated code in order to support this.  So, this one is probably in the never say never category.

"GOSUB... RETURN" not supported: yeech!

See SUB.

Function return could be array, associative arrays support: don't need unless the above two are fixed!

Totally optional.

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.

We are looking at supporting implicit variable declaration for an upcoming release.  I didn't have this from the start because frankly... it's harder to implement.

As I've said, these are just observations (opinions).

Thanks, I appreciate any and all feedback.