suggestions for future QB64

[DSMan195276]

So, for anyone is reading this, the takeaway from me is: 
* native support for arrays inside UDTs and 
* a native dictionary or associative array 
* HTTP/HTTPS

FWIW @mnrvovrfc, I currently work on QB64 and think all of these are great suggestions Built-in HTTP/HTTPS support is one of the things I'm currently working on and I've made some pretty good progress. Arrays in UDTs and built-in support for some other data structures is something else that I think is desperately needed (if for nothing else, to improve the code of QB64 itself). I think many of madscijr's other suggestions are also quite good.

Are all of them going to happen soon, or ever? Absolutely not We're a pretty small team (and any help at all is appreciated). But I think I can speak for all of us who work on QB64 in saying that we _do_ want suggestions like this, that's the only way for us to know what features people think QB64 is currently lacking and get a sense for what the most common feature requests are. Obviously if someone is demanding we do something then yes that's a problem, but madscijr's comments aren't even close to that.

Edit: I'll also add I agree with madscijr's general idea around what the purpose of BASIC is. QB64 is already a perfectly capable language, you can certainly implement your own HTTP logic, your own dictionary, fake arrays in UDTs, etc. I and many other members have done that often But you really shouldn't have too, frequently these implementations tend to have bad limitations or usability issues, and for newcomers they create a fairly big barrier for what should be simple things. So that said I definitely think we wouldn't exclude new features from consideration just because it's technically possible to do them today.

[TempodiBasic]

what do you think about a collapsable code in editor window?
For now if we want to navigate and read the code we can follow the run step by step or use the Mark points to go up and down in the code, or you can follow the code and jump to label/SUB/FUnction/ or line of code by right mouse button and then coming back using the arrow at the top of window area of editor.
In different Editors/ IDE of language it is possible to collapse or expand single block of code (a SUB/FUNCTION or a SELECT CASE/ IF THEN ELSE END IF/ DO LOOP/ WHILE WEND/ FOR NEXT block)
Is this feature interesting or useful or void of real significance?
Thanks for feedbacks

[DSMan195276]

what do you think about a collapsable code in editor window?
For now if we want  to navigate and read the code we can follow the run step by step or use the Mark points to go up and down in the code, or you can follow the code and jump to label/SUB/FUnction/ or line of code by right mouse button and then coming back using the arrow at the top of  window area of editor.
In different Editors/ IDE of language  it is possible to collapse or expand single block of code (a SUB/FUNCTION or a SELECT CASE/ IF THEN ELSE END IF/ DO LOOP/ WHILE WEND/ FOR NEXT block)
Is this feature interesting or useful or void of real significance?
Thanks for feedbacks

I can't really speak to that because I don't have much experience with the IDE/editor side of things. I don't think there's any reason not to add it, but I'm not sure there's anybody really interested in trying to do it.

From a "serious" development standpoint I think the lack of multiple file support (beyond just opening multiple IDE instances) is a bigger issue, but that's probably even less likely to get fixed

Another consideration could be supplying configurations for other editors, maybe even completely pre-configured versions which make them easier to use with QB64. That certainly seems a lot more realistic in terms of time it would take, and would make it easier to move "beyond" the built-in IDE if your programs are starting to get a bit too large for it.

[TempodiBasic]

the real issue of external editors is:
no parsing with debug... see Option _explicit and Option _explicitArray for examples,
I dunno if in Notepad++ we can get a syntax helper, surely we can get no a Debug module like that defined above.
Moreover I dunno if Notepad++ or other complex Multilanguage editors let us navigating code like we can do in QB64 IDE (marking line of code or following the code jumping to SUB/Function or label and coming back in reverse order of our observation.

So when we talk of external professional editors, we must think if there was a way to show keywords with syntax, highlight keyword, suggest syntax to the coder, activate a module or rule as option _explicit, navigate the filecode following the flow of code and not the only typewritten order.
Getting these goals we can use with pair opportunities QB64 IDE and professional Editors to typewrite QB64PE code!

[madscijr]

the real issue of external editors is:
no parsing with debug... see Option _explicit  and Option _explicitArray for examples,
I dunno if in Notepad++ we can get a syntax helper, surely  we can get no a Debug module like that defined above.
Moreover I dunno if Notepad++ or other complex Multilanguage editors let us  navigating code like we can do in QB64 IDE (marking line of code or following the code jumping to SUB/Function or label and coming back in reverse order of our observation.

So when we talk of external professional editors, we must think if there was a way to show keywords with syntax, highlight keyword, suggest syntax to the coder, activate a module or rule as option _explicit, navigate the filecode following the flow of code and not the only typewritten order.
Getting these goals we can use with pair opportunities QB64 IDE and professional Editors to typewrite QB64PE code!

Yes, I've been using Notepad++, and it kicks off compile fine, but I do rely on QB64's IDE for syntax checking. It doesn't kill me to periodically copy/paste my code from NPP to QB64 to get a syntax check, but it would be nice all in one. 
 
I'm OK with the existing editor and can live without the multi-file (mainly since I use Notepad++). 
The one thing that would greatly improve the editor for me, would be the option to have standard Windows style cursor and select behavior, and keyboard shortcuts. 

Most importantly, the option to keep the editing cursor in its original location when you scroll off the page with the mouse wheel... Stuff like that causes some frustration. 

Hope this helps...

[mnrvovrfc]

Wow, you sound very riled up about this stuff! LoL

What I meant by "could you be more specific" was, which features I had mentioned caused you such upset? What I am hearing is, the variant and the GUI. Which is fine. 
:

I wasn't angry and I'm not angry. I'm just saying what has been going on. Developers doing things for free, that's everywhere. (Sourceforge enough said.) Developers moving mountains without being paid, then well...

DSMan195276 answered you so I hope that is some insight about what is wanted and what a man/woman has to do to get precisely what he/she wants. "I would like" could easily turn into "I need it first". For somebody who could take the initiative, instead it could turn into, "Hey I really need this so I'm going to implement it!" The explanation wasn't aimed only at you in particular. If I were a programmer and not working for a multinational I wouldn't be very eager to fix things for other people, only modify it for my needs.

[SMcNeill]

 If I were a programmer and not working for a multinational I wouldn't be very eager to fix things for other people, only modify it for my needs.

Honestly speaking, that's about how QB64 has always been developed.  Somebody will speak up and say, "I wish we could do X with QB64."  If it's simple enough, one of the nice folks who push stuff into the repo will say, "Hey, no problem! I know where and how to do that -- give me a moment!"  Usually, in those cases, the change/addition/fix can be ready for testing by the next day.

IF there's more to it than that, the answer is, "Ummm...  *You* might want to check in XYZ area in the source.  You might figure out how to change/add what you want there.  If you have questions, ask, and we'll help **all we can**."

NONE of us are the original designers of this source/project.  I doubt *anyone* working on it knows 100% how/why/where everything works exactly as it does.  We like to help folks do what they want, but we're not the original code creators of the project.  We have to dig, research, and decipher how and why things interact as they do, and that's often a very time consuming task.  Since, as you mentioned, nobody earns a single cent working on this project, each developer has their own list of personal needs -- and their priority is to work on those things first.

User suggestions do get worked on, as free time and interest allows, but the main "push foward" for development has always been, "What features do the devs need *themselves*, the most?"