QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: hanness on September 05, 2019, 02:40:55 pm
-
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.
-
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.
-
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
-
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.
-
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.
-
Please give one example where a double window would make sense to you. Somehow I can't imagine.
-
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....”
-
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.
-
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.
-
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.
-
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.
-
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
-
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!
-
indirectly blames me for galleon leaving, bravo steve!
-
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
-
Steve, as the originator of this particular thread, I just wanted to chime in and add my final comments. Thanks greatly for that recap - it helps clarify many things for me.
Please also don't understand my original post as a complaint in any way. I had merely thought of it as an idea of something that would be useful to me.
As it stands right now, I absolutely love QB64. I'm getting countless hours of enjoyment out of it. As I mentioned earlier, I have a program I'm currently working on that is over 5,000 lines long at this point. I've never really done much in the way of programming. I did play with QuickBasic 4.5 many years ago when I was young lad, but only really simple programs.
I'm using QB64 currently to automate a whole bunch of command line operations in Windows which allow me to automate tasks. These tasks would take days to run manually but with the aid of my trusty QB64 program takes mere minutes. I had originally started this program as a batch file, but trying to build any decent logic into a batch file was just not an easy task for me.
For the most part it's been incredibly easy to be productive with QB64 and it's now an absolute necessary part of my toolkit.
Thanks for maintaining and enhancing such an incredibly useful tool!
-
Hi,
Steve, thank you for your summary. Writing my own IDE - I didn't even think about it. I'm really happy for the new commands you add to the IDE. I also have to apologize to Fellippe Heitor for the grumpy commentary right after QB 1.3. I think I touched him deeply. I really didn't want to.
There's only one thing I'm sorry about. You keep pushing some broken things from the past. That's why I (wrongly) thought that when the new version came out, it was such a huge step forward that the flies from the past will not be there. Unfortunately, it did not concern them and it was my stupid reaction. I understand that it is not in the human power of an individual to correct a foreign code, especially if there is no contact with the original author so that one can ask him for advice, if something see as unlogical.
Fellippe Heitor, I'm sorry. I didn't mean to offend you in any way.
I respect you all. Developers and contributors, because I am always expanding my knowledge.
Hannes: Thanks for the reply. I realized that what you describe is true. It would really be beneficial.
Only in general. If was found someone (sheer lunatic) who wanted to completely write a new IDE. I assume that without knowing C ++ it absolutely makes no sense to try, is it? I also assume that it would not be enough to overwrite qb64, but also other large attached bass files. I would like to discuss this topic (without obligation and really out of knowledge) in a new thread.
I enjoy QB64. Very much.
-
Please also don't understand my original post as a complaint in any way. I had merely thought of it as an idea of something that would be useful to me.
No worries at all. I didn’t think anybody was complaining at all; I just wanted to explain a bit about why I didn’t think we’d see such changes in the IDE anytime soon. The way it’s structured just simply doesn’t present itself for easy modification or alteration.
If you’re curious, just look inside the source yourself and examine ide_methods.bas (where most of the IDE related code is located). Do a search for SCREEN and see how many SCREEN , , 3, 4 statements and such are in it. Those are all page flippers which set various active display and source pages. Then search for VIEW, and WINDOW commands and see how many of them are peppered into various places and multiple routines... Then, just imagine how complicated it’d be to make *any* simple change to the IDE and integrate it into the existing system — all without being able to ask the original coder any questions about how things work.
It’s just a tangled mess and hard to sort out, so I wouldn’t hold my breath in waiting to see any major changes happening to the IDE. ;D
Personally, if I could just POOF a new feature into the IDE, I’d like TABS for multiple programs to be open at the same time, in just one instance of the IDE running.... But, like with your request, I don’t think I’ll hold my breath waiting to see that functionality added either, anytime soon. ;)
-
Only in general. If was found someone (sheer lunatic) who wanted to completely write a new IDE. I assume that without knowing C ++ it absolutely makes no sense to try, is it? I also assume that it would not be enough to overwrite qb64, but also other large attached bass files. I would like to discuss this topic (without obligation and really out of knowledge) in a new thread.
I enjoy QB64. Very much.
If you look in the Steve64 folder you downloaded to test things previously, there’s a file in the archive folder there called NewIDE, I think — it was my experimental attempt to write my own IDE, and it’s 100% all .BAS file. QB64’s IDE is, more or less, all inside ide_methods.bas, and it’s all .BAS code. I think Stxatic’s IDE is all in QB64 as well.
You don’t need to know c++ to write one at all; you just need to mainly work out screen scrolling, highlighting, copy/paste, and mostly text handling/input manipulation routines. I learned a lot playing around with my IDE, as I sorted things out with it; and I’d encourage anyone who’s interested in them to give creating one a try. Who knows — you might even come up with some nice functionality which we can then plug into QB64 itself! (After all, that’s what happened with my IDE — the ASCII chart and internal math routines we use inside QB64 now, first originated in my IDE as features which I thought would be nice to have, and then were imported over...)
-
Just a correction:
I think Stxatic’s IDE is all in QB64 as well
It was Dav who wrote the alternative IDE. If there's a rumor that I made anything similar, the closest hit would have been qxed.
-
Growing pains - no meaningful change in life or anything we do, which involves others, can be accomplished without it.
I hope Galleon and you guys carrying the mantle now can take some pride in where QB64 is going and all you guys carrying the mantle now can somehow recognize the issue in comments, no matter how hard it is to see when the remarks are so personally directed.
And we,who benefit and depend on your talents, present our wants and needs in terms of an issue or topic, and avoid personal remarks that begin " You need to do .." or Galleon did..." Just removing personal stuff goes a long way toward civility and thoughtful discussion.
Pretty pious statement but we lose so many good people over personally directed remarks.