suggestions for future QB64

[madscijr]

Also i think that QB64 phoenix really deserve modern GUI code editor not just console looking blue thing?
what you think?

I like the console looking blue thing.   Although...I do modify some of the colors.

I'm torn on the editor.

I like the authentic DOS-looking editor, and I wouldn't want to get rid of it as an _option_ but the reality is that I do 99.5% of my editing in Notepad++, and much prefer the standard Windows interface, standard Windows keyboard shortcuts, and all the nice things that go with it.

I'm pretty happy with QB64 but I do miss some things from VB6, VBA and even some of the .NET era Visual Studio (though MS got WAY too complicated with it, and then even rolled things back after VS 2008, like the ability to write macros to customize Visual Studio itself (remember that??)).

And so a HUGE reason that draws me to QB64 is its simplicity - you only have to run ONE program -QB64.EXE- to get to the compiler and IDE. You don't have to deal with the headache of dealing with different tools and figure out how to set it all up and remember how to make them work together.

When I was looking for a language to get back into making games and programs with, I also checked out FreeBasic. The language seemed OK but one thing that turned me off was it just seemed COMPLICATED to get up and running. By comparison, QB64 is a cakewalk: just unzip the archive, run QB64.EXE and voila!

So if it means keeping this simplicity, I'll live with the DOS looking editor anyday!

:-)

[crumpets]

I agree with the idea of keeping the UI simple and oldschool for sure. For those who desire a more involved interface, plenty of IDE's exist that will work with QB64. Personally I use Geany. I don't feel there's a need to be focusing time on interface stuff that has already been solved by others.

[bplus]

Notepad++ has Syntax checking, formatting, case correction and help from F1?

[dano]

I agree with the idea of keeping the UI simple and oldschool for sure. For those who desire a more involved interface, plenty of IDE's exist that will work with QB64. Personally I use Geany. I don't feel there's a need to be focusing time on interface stuff that has already been solved by others.

I downloaded Geany but cannot find a config file that supports QB64.  I see Freebasic, but the command structure is too different to work out of the box without significant work.

Did you find the config file online or did you create one?  Would you care to share the config file so that those that are interested can try it?

While the QB64 IDE is great, considering what it is and that it was written in QB64, I am very interested in finding a full-featured IDE that works with QB64.

Thanks,
Dano

[mnrvovrfc]

Some features I would find helpful for future QB64:

* Native dictionary (associative array) type. The basic of which can hold strings, but maybe make it like VBA's which can hold different types? 
:
* Built-in / expanded support for hardware images. Built in hardware image commands for shapes (circle, square, line, etc.) and copy portion of hardware image. Maybe commands for tilesets? Or 3-D & isometric graphics? Whatever will make hw images and graphics easier to work with.

* Form/GUI editor and with events (just like VB6 & VBA) built right into the IDE.

* Optional "variant" type? (useful for operator overloading, would need an accompanying typename function)
:

If this is added to QB64 then I'm just going to leave and not come back. You will have to do it yourself pretty much if you really want it. I don't want another M$VB-clone while there is already one out there! Sometimes I contradict myself but... I don't like the type sigils anymore and I don't mind "RETURN" being transformed. Otherwise the somewhat archaic syntax of QB64 inherited from M$QB grew on me a long time ago. It doesn't bother me. Making it more like VB then, it would really really bother me.

[RNBW]

I agree with the idea of keeping the UI simple and oldschool for sure. For those who desire a more involved interface, plenty of IDE's exist that will work with QB64. Personally I use Geany. I don't feel there's a need to be focusing time on interface stuff that has already been solved by others.

I downloaded Geany but cannot find a config file that supports QB64.  I see Freebasic, but the command structure is too different to work out of the box without significant work.

Did you find the config file online or did you create one?  Would you care to share the config file so that those that are interested can try it?

Is there a QB64 config file (or recommendations) for Geany?
While the QB64 IDE is great, considering what it is and that it was written in QB64, I am very interested in finding a full-featured IDE that works with QB64.

Thanks,
Dano

Is there a QB64 config file for Geany, or alternatively recommendations for QB64 set up?

[madscijr]

Some features I would find helpful for future QB64:

* Native dictionary (associative array) type. The basic of which can hold strings, but maybe make it like VBA's which can hold different types? 
:
* Built-in / expanded support for hardware images. Built in hardware image commands for shapes (circle, square, line, etc.) and copy portion of hardware image. Maybe commands for tilesets? Or 3-D & isometric graphics? Whatever will make hw images and graphics easier to work with.

* Form/GUI editor and with events (just like VB6 & VBA) built right into the IDE.

* Optional "variant" type? (useful for operator overloading, would need an accompanying typename function)
:

If this is added to QB64 then I'm just going to leave and not come back. You will have to do it yourself pretty much if you really want it. I don't want another M$VB-clone while there is already one out there! Sometimes I contradict myself but... I don't like the type sigils anymore and I don't mind "RETURN" being transformed. Otherwise the somewhat archaic syntax of QB64 inherited from M$QB grew on me a long time ago. It doesn't bother me. Making it more like VB then, it would really really bother me.

Thank you for your reply.

Could you be more specific? I assume you are talking about variant types. I don't NEED variants - it has its use in some cases. But not all cases - the whole typeless (or whatever you call it) way they do variables in Python and JavaScript is maddening to me, so I don't mind strictly typed. 

Likewise, an IDE with a built-in GUI editor isn't something I view as mandatory, more like a nice-to-have.  That could be part of an alternate IDE, not replacing the existing one. I know there is inform, so at least there is some option.

However, I don't see the point of being against a native dictionary object or arrays inside of user-defined types. That stuff would make life a lot easier in many ways, and really should be added to the core QB64 language in my opinion.

[RhoSigma]

Follow the first link in my signature, in the projects list you find a Notepad++ setup.

[mnrvovrfc]

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

[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!