in which line am i ?

[bplus]

yes Bplus, do you understand what I mean!

I think I do, but Steve's last looks better than my ideas so far, specially for the monster you show LOL!

[bplus]

Wow ! i like this _EXIT command, i didn't know it before! De! you still avoided the question! You made 5 cycles and identified each one. I intentionally showed 100 cycles. then I put an ID in front of all a hundred? If I did, it would be enough to print the ID with an "on key".

Even better!

[SMcNeill]

Wow ! i like this _EXIT command, i didn't know it before! De! you still avoided the question! You made 5 cycles and identified each one. I intentionally showed 100 cycles. then I put an ID in front of all a hundred? If I did, it would be enough to print the ID with an "on key".

As far as I know, there's no _LINENUMBER command built into QB64, so there's no way to get that value back natively without generating your own ID.  If you're going with 100 loops, and glitch out in them, then you might want to try Felippe's debugger (which basically adds the labels before compiling your code automatically), or else just add them yourself. 

[SpriggsySpriggs]

You keep saying he's avoiding the question but I don't see that being the case. Perhaps you aren't explaining your problem clearly? I would think you are saying that your program is crashing to desktop rather than failing with a message box alert, correct?

[SpriggsySpriggs]

As far as I know, there's no _LINENUMBER command built into QB64, so there's no way to get that value back natively without generating your own ID.  If you're going with 100 loops, and glitch out in them, then you might want to try Felippe's debugger (which basically adds the labels before compiling your code automatically), or else just add them yourself.

You can use a preprocessor macro in a header to generate a static count. Each time the function is called it is increased by 1. That could be helpful, perhaps. Perhaps not.

[bplus]

Aha the Interpreter advantage, press a key and piece of cake to tell what line number you're on and what all the variables are looking like at that moment! And stepping through code, and setting break points... all that good ole stuff!

[MasterGy]

Thank you for your answers. the torment remains. Due to the lack of a simple thing about which queue to stop running when we exit.

[MasterGy]

yes Bplus, it helped a lot, for example such a problem was solved in an instant. I remember under DOS :) Unfortunately, it takes 1 day for a 160kbyte program to see where this kind of error is.

[SMcNeill]

I don’t think you’ll ever find simple answers with 100 loops stacked.

Do
   Do
       Do
           Do
                Do....


Now, let’s say the 2nd loop is the endless loop...  if we manually exit, or hit a key at any time (such as ON KEY), WHY would we do it inside loop 2?  Why couldn’t the program be in loop 3, 4, 5+ when we exit?  Those loops all run fine; it’s not until we get to loop 2 that we endlessly repeat.   Just having a line number by itself doesn’t help much, or at least, I don’t see how it could.

[SMcNeill]

Aha the Interpreter advantage, press a key and piece of cake to tell what line number you're on and what all the variables are looking like at that moment! And stepping through code, and setting break points... all that good ole stuff!

https://www.qb64.org/forum/index.php?topic=458.0 — That’s the closest to all that ole stuff that you’re going to come.

[MasterGy]

Bplus, anyway i am very happy with the QB64! if it weren’t for it, I wouldn’t be able to implement my ideas so quickly, efficiently. In the old days, unfortunately, because of speed, I was forced to give up a lot of things. This shortcoming is a trifle. In the next version, I will suggest that if ctrl + break exits, if you also press SHIFT, for example, a window will say goodbye, which will print out which queue the processing took. I think that would solve the infinite-cycle problem.

[MasterGy]

SMcNeil, suppose I give you a program. huge size. be 10Mbyte and one day it would be read. I secretly place a "DO: LOOP" in it. You are sure that the program will not run due to an endless cycle. My suggestion would solve this problem in an instant. Otherwise, it may take 1 week to find the error.

[bplus]

@MasterGy couldn't you check your loops from the inside out with that key press thing (as opposed to exit) you could see if entering and exiting innermost, then check next innermost... keep going until you find the bad one?

I am talking about a method electricians use to track down a bad component or circuit.

The inner most loop is what has to pass to get to next item in 2nd inner most loop...

[MasterGy]

Thanks, SMcNeill, I'm going to try this!

[MasterGy]

Thanks Bplus for the idea! I already found the error. It took a few hours. But if I know which line you’re stuck with, I’ll win a couple of hours. So the problem remains. It could help anyone at any time if we at least knew where the program was going. All this without loading the source code just for debugging.