IDE - just a thought on Next and Out of Subscript

[Kernelpanic]

@bplus - Your sizing [foo(100)] is static. This cannot be resized. This is only possible with a dynamic array.

Code: (Select All)

Option _Explicit

On Error GoTo Fehlermeldung
Dim As Integer feldGroesse

'Otherwise static: feld(10)
feldGroesse = 10
Dim As Integer feld(feldGroesse), neueFeldGroesse

Locate 2, 2
Input "Neue Feldgroesse: ", neueFeldGroesse

'Only with Redim
ReDim feld(neueFeldGroesse)

Locate 4, 2
Print "Neue Feldgroesse: "; neueFeldGroesse

Locate 6, 2
'Muss groesser sein! - Have to be greater!
Input "Neue Feldgroesse: ", neueFeldGroesse

Locate 8, 2
'New array size without ReDim.
Print "Neue Feldgroesse ohne Redim: "; feld(neueFeldGroesse)


Fehlermeldung:
Locate CsrLin + 1, 2
Beep: Print "Fehler bei: "; _ErrorLine

Locate CsrLin + 1, 2
Print "Fehler: "; Err

End

[SMcNeill]

Remember, when you run the EXE, you're running the compiled program which executes independent of the IDE.  A subscript error only happens at run time, and there's no real way for the IDE to interact with your program itself at that point.  The easiest solution in this case is simply to write down or remember the line number and then CTRL-G and type in that number to instantly go to that line.  (Or use the main menu and Search>Goto Line #...)

Hi Steve - So the EXE is running and picks up an out of range error. The program stops running and you get a choice of Continuing or not. The line number is already identified. If I chose Continue, I'm assuming the program starts running again after the line the EXE has just informed me where the error is. Why is it, if I chose NOT to continue, the cursor not on or near the line which caused the error.

This is because your EXE is completely independent of QB64 and the IDE once it's compiled.  Write a program sometime and then copy it onto a computer without any version of QB64 on it whatsoever.  It'll compile as there's no errors in the code itself, so you can make a valid EXE, and you don't need QB64 anywhere around to run that EXE after its compiled.

If the EXE tells you "Out of Range on Line 12345", and you don't have QB64 installed on that PC, how's it going to load *anything* into the IDE?  Even IF you do have a copy of QB64 somewhere on your computer, how's it going to load the BAS file to jump to that line?  Lots of folks distribute EXEs without the source being attached anywhere with it.  

When the EXE encounters an error, it basically gives you all the information that it can  -- "You went beyond your defined limits on line XYZ..."  The EXE doesn't have the BAS file embeded with it, it doesn't automatically have a copy of QB64 attached to it, and it isn't going to load its source into any editor for you automatically.

The languages that tend to allow such interactions are more likely to be interpreters rather than compilers, and at the end of the day, QB64 is nothing more than a compiler at work.

[Dimster]

I see - so the IDE can't sniff out the "out of range" error, it's only caught by the EXE run. The IDE and EXE must have the same copy of the program. I totally understand, if you run the EXE on a computer which does not have the QB64 program, then it can't possible move the cursor in the IDE to the offending line it has just identified but if the IDE and EXE both reside together during the creation of the program, is there not a shadowing movement of the cursor in the IDE to follow the line pointer in the EXE? I guess that presupposes that the EXE would know when it stands alone or in concert with the IDE code. We'll maybe a job for ChatGPT.

And on the other matter of NEXT + the name of the variable control. Is something like that possible or undesirable ?

[mnrvovrfc]

It's better not to provide the variable for "NEXT". Otherwise the variables have to be in reverse order they were submitted with "FOR".

Code: (Select All)

FOR X = 1 to 10
FOR Y = 1 to 10
FOR Z = 1 to 10
:
NEXT Z
NEXT Y
NEXT X

It cannot be "x, y, z" listed for the "NEXT" lines. It's easier just to leave out the variables from "NEXT". Freebasic even flags this behavior of using a variable with "NEXT" in their "fu-ben" mode. It's still allowed if the user wants to compile plain QuickBASIC/QBasic code.

[mnrvovrfc]

... then it can't possible move the cursor in the IDE to the offending line it has just identified but if the IDE and EXE both reside together during the creation of the program, is there not a shadowing movement of the cursor in the IDE to follow the line pointer in the EXE?

What "shadowing movement"? You're confounding yourself with the fact the QB64IDE "shadows" its window while your program is being created. Then when the creation is done, it is run, apart from the QB64 IDE. They remain two separate programs that have nothing to do with one another. This is like using any other code editor and being able to give it a command to QB64 to compile a BAS file to an EXE file.

As I've said, either you need an interpreter like QBasic, or there has to be a special edition of the QB64 IDE with a debug mode that allows what you want. This "special edition" has to do something like pick up text written to "stderr" and expect the user's program to complain into "stderr" besides throwing a MessageBox. Then from that information from "stderr" or whatever the IDE could move the cursor to the line where it thinks the error occurred.

LOL ChatGPT isn't going to make anybody wiser, and it's not going to teach anybody how to be a better creator of applications.

If the EXE tells you "Out of Range on Line 12345", and you don't have QB64 installed on that PC, how's it going to load *anything* into the IDE? Even IF you do have a copy of QB64 somewhere on your computer, how's it going to load the BAS file to jump to that line? Lots of folks distribute EXEs without the source being attached anywhere with it.

This is emphasized when the user's program was created with QB64 Phoenix Edition v3.7, and the QB64 that is available somewhere else is an earlier version, or the "dot-com" or "dot-rip" version, or even before it hit v1.

Without source code, the program would have had to be compiled in debug mode to have a ghost of a chance to see source code lines. In "gdb" and even better if using Freebasic. I don't know if a program compiled by QB64 could cause "gdb" to show BASIC source code lines while stepping through the program. That was a convenient trick Freebasic has which made me a bit more willing to use "gdb".

[mnrvovrfc]

It's going to be tricky and complicated, and it will require you to learn another programming language. But it might work.

Pick up Autohotkey. Create a script that could read the text from the QB64 runtime error MessageBox. From the message extract the line number. Then have Autohotkey open the QB64 IDE, load in the source code and use the "Goto Line" command and enter the line number automatically.

Autohotkey used to have an "Autospy" feature but it was removed in the release when I last used it years ago. Have to be bogged down with windows classes and that sort of thing. It might not be enough to read the window title to detect if it comes from QB64. What if you have to run more than one program that you created with QB64?

I have done something like this with Psycle, a music-creation application that sadly isn't being developed anymore. I used Autohotkey to automate the load of "pages" of the song document. It wasn't very difficult but had to waste several hours perfecting the job because there is no debugger for Autohotkey scripts. Also because the user has to be attached so much to the CHM file that describes the syntax and the commands.

EDIT: it's going to require some trial and error. Take a look at these pages for starters.

https://www.autohotkey.com/docs/v2/lib/WinGetText.htm
https://www.autohotkey.com/docs/v2/lib/WinActivate.htm
https://www.autohotkey.com/docs/v2/lib/RegExMatch.htm
https://www.autohotkey.com/docs/v2/lib/Send.htm

BTW this would work on Windows only, or on Linux with Wine. There's a Linux-only equivalent but it needs Python and I refuse to invest in it. I want the original article, LOL.

[Dimster]

Hi mnrv .. Hot Keys look interesting. I gather an autohotkey program would need to be running at the same time as the EXE is being built. Once the EXE hits the 'out of range' error the EXE should stop and give the option to end execution or continue. If I select end execution then the autohotkey program would grab the line number where execution stopped, reload the IDE and position the IDE cursor at the offending line??? Is that basically how a Hot Key program would work??

I think I may have a fundamental misunderstanding of the dance between the IDE and the EXE. I thought there HAS to be a point where the EXE builds itself from the coding in the IDE. I'm calling this shadowing. In the course of this shadowing, not only does the EXE pick up the syntax but also the line numbers. Where the IDE can monitor the syntax errors it can't know runtime errors. Those can only be detected by the EXE when running the program. As soon as the EXE hits the 'out of range' error, by the very fact it gives an option to end execution or continue, I thought ... as long as the IDE code was available, and the line number with the error identified, then electing to end execution could reposition the cursor at the offending line. 

I've learnt something here. Any connection between the IDE and the EXE only takes place during the shadowing process or whatever you call the process where the EXE is being built from the IDE code. I would need to write code in the IDE that traps all runtime errors and identifies the error line number and then a GOTO that line. I can hear b+'s and Kernelpanic's "told you so". I have used Error trapping code before but always when I knew or expected what the error was likely to be so could watch for that particular error situation. Here I'd want to trap ALL runtime errors, identify the errorline and goto that errorline. Seems very easy to do.

[SMcNeill]

Hi mnrv .. Hot Keys look interesting. I gather an autohotkey program would need to be running at the same time as the EXE is being built. Once the EXE hits the 'out of range' error the EXE should stop and give the option to end execution or continue. If I select end execution then the autohotkey program would grab the line number where execution stopped, reload the IDE and position the IDE cursor at the offending line??? Is that basically how a Hot Key program would work??

I think I may have a fundamental misunderstanding of the dance between the IDE and the EXE. I thought there HAS to be a point where the EXE builds itself from the coding in the IDE. I'm calling this shadowing. In the course of this shadowing, not only does the EXE pick up the syntax but also the line numbers. Where the IDE can monitor the syntax errors it can't know runtime errors. Those can only be detected by the EXE when running the program. As soon as the EXE hits the 'out of range' error, by the very fact it gives an option to end execution or continue, I thought ... as long as the IDE code was available, and the line number with the error identified, then electing to end execution could reposition the cursor at the offending line. 

I've learnt something here. Any connection between the IDE and the EXE only takes place during the shadowing process or whatever you call the process where the EXE is being built from the IDE code. I would need to write code in the IDE that traps all runtime errors and identifies the error line number and then a GOTO that line. I can hear b+'s and Kernelpanic's "told you so". I have used Error trapping code before but always when I knew or expected what the error was likely to be so could watch for that particular error situation. Here I'd want to trap ALL runtime errors, identify the errorline and goto that errorline. Seems very easy to do.

Think of it in terms of going to your sink and pouring a glass of water.  You can turn the faucet and make water come out from the sink, but there's no "reverse" installed so you can pump any back down and into your well, if you decide you don't need it.  

The IDE works in this same, one-way manner -- it takes your BAS code and compiles it into an EXE which then runs independently.  There's no way to then take that EXE and decompile it back down into the BAS source.  All the IDE does is compile the program into a working EXE.  After that, the two are independent processes and one  has no bearing on the other.  There's just no way that an error generated at run-time is ever going to be caught or interacted with, with the IDE itself.  

You might pour oil into the engine of your car, but you sure aren't going to pump it back out from that same hole! 

[Dimster]

Steve, there will come a day when ChatGPT will describe how a faucet will both pour and suck back water so the world can conserve that precious substance. I have accepted my fate, I will simply have to hunt down the offending line physically with my ancient eyes and arthritic hands (just kidding). And it would appear I cannot come up with an error trap routine which will do the job for me. Error Trapping has no "Select EVERYCASE" feature which would allow me to trap every line of code and trap every run time error and then GOTO the offending line of code.

Thanks for the discussion on this guys and girls  ,,, er fellow coders ... the frustration I encountered has once again returned to rational thought.