suggestions for future QB64

[madscijr]

:
Could you be more specific?
:

How much more specific must I be than you have to create it yourself if you want it for free because the current QB64 team, and those on projects forked from QB64, aren't being paid for what they are doing. Maybe I'm wrong. What you're asking for would have other people thinking about the dollars far beyond donations. "But you don't know how to parse strings and put stuff into strings? Why do you want this variant away from programming within Libreoffice?" "But we already have _MEM, so use that instead of array field of UDT!" "Eh you want another GUI for QB64? But what's wrong with the one it already has? What's wrong with using NPPP to compose your programs?" one of the most ignorant might ask, who happens to have enough ability to built what you've been asking for. "I'm on Linux," I would answer, then a long silence and hesitation to answer correctly follows from the other end. "I use Macintosh OS, is that OK?" said somebody else, might cause sniggering. IJS.

I'd like to know what is thought by at least one of the current members of the QB64 team.

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. 

However, I think asking for arrays inside of a UDT is not unreasonable. 
Yes, we can hack together that kind of functionality with _MEM, but, first of all it's a hack. 
Is it cross-platform? Can we be sure it will work as expected a couple versions down the line? 
But most importantly, isn't messing with memory and having to worry about the inner workings of how variables are stored, and working at such a low level what C & C++ are for? 
This is BASIC, designed to be EASY. The beauty of BASIC on a modern PC is, it's even easier (no line #s for one thing, support for structured programming, cross platform, and a wiki & integrated help, etc.)

I don't expect the QB64 team to do ANYTHING for free, it's been cool of them to even have created this great language and IDE, and put up these forums. I try to give back by participating and sharing what little programs and bits of code I make with it. 

And since the community was discussing things we'd like to see with this thread, I'll contribute ideas. 
I'm just being honest - for me, native support for arrays inside UDTs, and a dictionary or associative array, are two features I would ask for in ANY language. 

It's not like I'm asking for them to make it OO, for crying out loud! 

The other huge feature I think a lot of people would find useful is native HTTP/S. And I think they're working on it so I'll wait patiently.

Another feature I think would be cool, would be better sound support. 
I realize that's probably not at the top of most programmers' lists, but I'll throw that out there too. 
No expectations for it to happen, and I'm trying to learn more about doing sound on my own. 

I would love for someone to come up with code to read multiple USB mice and keyboards plugged into a PC as separate input devices - hell, I even floated the idea of paying a "bounty" to get that feature! I realize it's probably not the most asked for feature, so I research how to get that working as time allows.

Finally, I've done some stuff with hardware images and seen how much faster it can make a program (thanks bplus/steve/etc.) and I wish there were some way to maybe do it a little more easily. But at least it can be done in QB64 the way it is, so I'm not going to push too hard. Priorities! 

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

would be most useful for me. 

I'm out of time, hope this explains things a little.
Peace!