Feature Request: Split Screen

[hanness]

As I am writing code, I find that I constantly need to reference other sections of code located elsewhere within the same program. Currently I use bookmarks to bounce around from one area to another, or I open a second instance of QB64, but neither of these work nearly as well as a split screen solution would work.

I'm currently working on a program where I have over 5000 lines of code and being able to display one section of code in a split screen above another section of code would be a fantastic boost to my productivity.

If this could possibly be considered for a future version it would be greatly appreciated.

[STxAxTIC]

As someone who never edits qb64.bas, I can assure this wont happen. Best thing to do is develop good habits for navigating your code, and maybe fragment the file apart. Beyond that, just open the same file twice, perhaps as read only in another editor, and be careful with which editor does the saving.

[Jack002]

Many thoughts about this
* at first I thought you were making or wanting to make a split screen output to a program. That would be fun to code.
* you mention bookmarks. I forgot about them. Back in the QB (B464) days I used them. Handy to have. You can set many and parse over them
* I often used the F2 option to jump to different parts of the code, the subs and fns. Handy to jump around with.

This IDE we have is slicker than it's ever been, even now, without split screen. I'd think opening two instances of QB64 would be the best solution to this now.
Good luck

[Petr]

You have an intentional error option. For example, if you can't remember what the hell the element name in the array is, make a mistake, skip to the array declaration and use Ctrl + Shift + G to go back. Excellent function.

I assume that if you use SUB and FUNCTION and F2, that must be enough. If you're coding with the GOTO / GOSUB style, all in one..... then..... learn using SUBs and FUNCTIONS in your own interest.

[hanness]

The problem with opening 2 separate instances of QB64 is that as you make changes in one Window, the changes are not reflected in the other Window. That's what I'm I am having to live with for now, but  I was just throwing this out there as a wish list item.

It seems like a logical feature to have in anything where you are editing a program or document. That's why just about every word processing program has this as a standard feature. A program, after all, is just a document. However, since it's not always read in a linear manner, instead, you jump from one place to another in subroutines or with branches to different sections in code, a split screen would make even more sense then in a word processing program.

[Petr]

Please give one example where a double window would make sense to you. Somehow I can't imagine.

[SMcNeill]

Please give one example where a double window would make sense to you. Somehow I can't imagine.

I use multiple windows/tabs all the time for a lot of things.  In coding, it’s nice to take a long piece of code and easily make changes at multiple points at once.  (Say change the code directly before a SUB/FUNCTION call, and then inside that function, then after the call, for testing purposes.). It’s a quite handy feature to have, but — as someone who does edit QB64.bas — I can assure you, it’s something we’ll never have.

The history of QB64 prevents such massive changes to the IDE.  Ages ago, Galleon started this project, and — for those who may not know — originally it was written and compiled in QB45, until QB64 matured enough to compile itself. With that “core” programming at its base, the internals of QB64.bas are a mess.  Variable names are non-descriptive; are reused constantly for different things at various points in the code, and archaic code usage is peppered into the source.  We don’t have one screen which we work with for the IDE — we have *AT LEAST* four which we page flip between to create our display.  We use SCREEN statements liberally to toggle between active and visible screens, and VIEW, WINDOW, and other such seldom used screen splitting commands are active....

...Then, to obfuscate things even more, there’s GOTOs, GOSUBs, labels everywhere, and a maze of spaghetti code to try and navigate between and sort out...

To say it’s a mess is beyond an understatement, and even trivial changes like adding coloring to the keywords are rather difficult to sort out and implement.  For ages, I’ve wanted to swap us over to a 32-bit IDE display for advanced color and graphical support, and so far, I’ve still failed at that simple change over.  Fellippe has wanted collapsing blocks for ages (such as a means to collapse IF-THEN blocks, or DO-LOOP blocks.), and we haven’t sorted that out.  Luke was, at one time, talking about adding an auto-complete feature for keywords and such, and that hasn’t went anywhere either...

It’s a nice idea, but honestly, I can’t see it ever really happening.  The only real solution to the mess is either:

1) Rip the whole IDE out and build a new one from scratch for QB64.  (And I don’t see anyone with the time and interest to do this at the moment.)

2) Find a new IDE to code in (which unfortunately won’t have the vibrant syntax checker our IDE has for BAS code), and then only use QB64 as a stand-alone compiler.

Or 3) Just live with it while saying, “Man, I wish it would do this or that, but I understand it’s not that simple so I’ll just cuss and cope as best I can....”

[hanness]

Example 1

At the start of my program, I declare all my variables. As a 5,000+ line program, I have a lot of variables I am working with, probably 100+. I can't always remember every single variable name so I have to bounce back up to my definitions to get the correct name, then back down again to where I was working.

Likewise, if I'm working on a function that has local variable definitions, but the spot I'm working on is a number of pages down, it would be nice display those at the top of the scren, and the code I'm working on at the bottom.


Example 2

I'm working on a section of code that is similar to an earlier section 2,000 lines earlier, but with some parts requiring changes. I repeat this several times in my code because I'm performing a lot of similar operations but all with some changes. The changes prevent this code from being completely reusable as a subroutine. It would be nice to have the original code at the top of the screen, while I work on the section requiring changes in the lower portion of the screen so I can see both at the same time.


I know that can make use of tools such as bookmarks to bouce between sections, but then I don't have both sections open to reference at the same time.

If I open a second instance of QB64 to display the other section of code, as I move from section to section, I repeatedly have to close and reopen the second instance to refresh with the changes I have made.

[Cobalt]

If you don't mind codeing outside the QB64 IDE I would recommend a program called UltraEdit, you can have the split screen look, horizontally or vertically, and both copies(I believe you can have more than just two splits of the same file, never tried) update as you go. it also supports syntax highlighting, display font options, line number options, and Hex editing too. Only thing is its very old and I'm not sure if its still maintained, I've been using my copy since the late 90s.

[hanness]

Thanks everyone for your feedback. I'm fine accepting that it will never happen. I'll work within the constraints of what I have now.

Again, it was just a wishlist item and I'm fine to accept that it may not be possible.

Thanks again for all the feedback.

[TempodiBasic]

Wow

originally it was written and compiled in QB45, until QB64 matured enough to compile itself. With that “core” programming at its base, the internals of QB64.bas are a mess.  Variable names are non-descriptive; are reused constantly for different things at various points in the code, and archaic code usage is peppered into the source.

until QB64 hasn't  been mature enough to compile itself surely QB64 is under the 50kb of code!
So I have imagined that there was an interruption between first project (qb45 in which is used BC.exe compiler ) and the second project (QB64 autocompiling) in which there is a solid use of a C++ compiler (g++), instead the line is straight and continue!


in a quick look into QB64, to my hobbist eyes QB64 appears to be build by more than one person... (I want be clearer, it is possible that Galleon has let to somebody to write blocks of code following his project and his manner for coding. Like when a writer pass his opera to a ghost writer for implementing minor blocks of story) ,  but it is not so clear to my eyes how distinguish the original code and the add-on of Developers. I could confound these new blocks with those of original version of 7-8 year ago.

Until the original core is still the core of QB64 without a clear and specific I/O structure with the new part of QB64, I think that is impossible for the developers to get a multiwindows QB64 or indipendent child window of the program.

[SMcNeill]

Wow
...in a quick look into QB64, to my hobbist eyes QB64 appears to be build by more than one person... (I want be clearer, it is possible that Galleon has let to somebody to write blocks of code following his project and his manner for coding. Like when a writer pass his opera to a ghost writer for implementing minor blocks of story) ,  but it is not so clear to my eyes how distinguish the original code and the add-on of Developers. I could confound these new blocks with those of original version of 7-8 year ago.

Until the original core is still the core of QB64 without a clear and specific I/O structure with the new part of QB64, I think that is impossible for the developers to get a multiwindows QB64 or indipendent child window of the program.

A brief history of QB64, for those interested:

Galleon started QB64 as an independent project, and up until above version 0.8, or so, the work was 100% all his.  Around that stage in QB64 history, I started delving into the internals and expanded CONST so that it works with basic math calculations and functions.  By version 0.954, (the last version which was based on the SDL framework), I was starting to add new functionality into the language with Galleon’s blessings, but a sizable portion of the user base thought I was pushing “operational bloat” into the language and regularly complained every time a new keyword or change was made, and at this point, Galleon began to become disillusioned with the project and its user base. 

It seemed to me, Galleon was tired of having to work on maintaining it all alone, and yet the user base did nothing but gripe the moment someone actually stepped up to help work on things.  Heck — and I’m not kidding here — I even got paid for several months to *NOT* add, or alter, anything within QB64; so you can imagine how that disillusioned Galleon.  Nobody had helped him work on the project, and yet the first time somebody does step up to help with the development, they get paid to stop for several months...

...And, soon after, QB64 v1.0 comes out and we swap over to OpenGL instead of SDL, behind the scenes.  Several things need to be reimplemented, and instead of allowing Galleon time to develop the project, several members once again blow up over the changes.  Check the old N54 site if you want to read some of those archived gripes and whines. ( https://www.tapatalk.com/groups/qbasic/ )

...Then Galleon starts to add Android support (and from my testing, several small things would work, but the process was extremely complex to put it all together and make it go).  More complaints started to pile up, and Galleon’s interest in the project continued to fall precipitously.  Around this time, Luke started studying the project and he and I studied the source extensively, with him helping me understand the c-side of things, while I helped him try and decipher the internals of the BAS side of things.

A little while after that, the website started to have lots of issues.  [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] was down as much as it was up and the more people griped, the less interest Galleon had in continuing the project.  Luke, Felippe, and Stxatic started the website here as a back up for when the main site went down.  Felippe started to help with maintaining and enhancing the source.

And then, Galleon just...  quit.  Enough was enough.  He had his family life, with small children to raise and nurture, and his interest in the project was kaput.  Sine then, it’s been mainly Felippe, Luke, and me maintaining and enhancing the source.  Kobolt has added a few bit-shifting keywords, Rhosigma has pushed a few bug fixes and alterations, and a few others have worked on our install scripts...

...And that gets us up to the current state of the project.

What was Galleon’s exclusive baby, was completely abandoned by its original Father.  (And that’s part of the issue with altering the source — the rest of us are still sorting out deciphering Galleon’s logic/process.)  Since just before v1.1, QB64 has been maintained and altered several times by folks which aren’t the original author (which you noticed looking at the source). 

And that’s probably more than you ever really wanted to know about how we got to where we are now.  ;D

[Bert22306]

Nice recap, Steve. To me, when I discovered QB64, it was a godsend. I'm forever grateful to you guys, Galleon of course, Steve, Fellippe, Luke, and all of the Apostles, for continuing to develop QB64. The IDE has never been better, and the whole language is way beyond MS QuickBasic. I'm sad that Galleon became discouraged and hope and trust this doesn't happen again!

[STxAxTIC]

indirectly blames me for galleon leaving, bravo steve!

[SMcNeill]

indirectly blames me for galleon leaving, bravo steve!

Not at all.  After all, you never paid anyone to NOT work on QB64...  Don’t read more into my words than what was there; I tried hard not to mention anybody in particular. It was the general toxicity of the old forums and the overall brouhaha of every little thing that made Galleon lose heart in the project.

A lot of folks affected the atmosphere to a much greater degree than you did — I doubt you’d actually fall in the top 10 for “negative users” out there.  BLANK was terribly negative about the “spirit of BASIC being destroyed” — only PYTHON preserved it, in his opinion.  BLINK and BLONK both danced naked and burned effigies of Galleon the moment SDL was retired, leaving the forum and saying they’d never, ever be back — only to come back later and act like nothing had changed... Lots of folks were much higher on the list of reasons for “Why Galleon left,” than you’d ever be.  BLUNK keep claiming he was going to “fix everything and release his own version”...  Just check the N54 forums and read the archives, and you can see where a ton of endless negativity oozed everywhere, and see why Galleon lost interest in working on things.

Honestly, I wasn’t thinking of you at all, when I wrote my post earlier.  ;)

If you’re curious, see if your rhetoric compares with any of these old posts:
https://www.tapatalk.com/groups/qbasic/some-good-news-and-bad-news-about-qb64-t38760.html#p200078
https://www.tapatalk.com/groups/qbasic/the-last-straw-for-qb64-t38750.html#p200035
https://www.tapatalk.com/groups/qbasic/the-mal-formed-question-that-killed-sdl-t38748.html#p200011
https://www.tapatalk.com/groups/qbasic/what-s-the-difference-between-qb64-gl-and-a-train--t38763.html#p200084