On Exit question

[bplus]

BTW there is no "On Exit" thing in QB64

There is a bunch of On Somethings but Exit is not one of them.

_Exit is a Function that tells you mainly the user wants to quit they clicked the top right X button to quit or some key combo that usually lets them escape the app.

Opps OK maybe ON _Exit... might work
https://qb64phoenix.com/qb64wiki/index.php/ON...GOTO


This is poorly worded in my opinion

• numericalExpression represents the line or label that the program should branch to: 1 branches to the first line or label in the list, 2 branches to the second, etc.
  

NumericalExpression evaluates to a number, that codes which line label or line number to goto.

But yeah, _Exit returns numbers according to what way the user attempts to quit.

Would
On _Exit() work better?

[bplus]

@NasaCow Search can't find ON EXIT anywhere in your code you posted.

This is what I do find:

Code: (Select All)

'Disabling the default exit routinue
ExitFlag = EXIT
ON TIMER(1) GOSUB ShutDown
TIMER ON

Code: (Select All)

ShutDown:
ExitFlag = EXIT
IF ExitFlag THEN SYSTEM
RETURN

Does not look good to set ExitFlag Twice nor putting Shutdown on Timer.

When you know the user wants to quit from _Exit then you run the save work code if not saved and quit or just quit if work already saved. 

I don't see need for Timer sub here.

[TerryRitchie]

Hi Terry - hope I'm not taking this tread down a different road but on that Option_Explicit, do you find it highlights an "undefined variable" error when the variable is just a local loop control type. I don't DIM or DIM SHARED those loop control variables.

Ie

For XYZ = 1 to 10
 XYZ$ = str$(XYZ)
 FileName$ = "MyFileNumber"
 File$ = FileName$ + LTrim$(XYZ$)
 Print File$
Next XYZ

In this case I'm just trying to add a number to the file name and XYZ does not need to be Dimensioned as I believe it's a Single by default. But I take your suggestion as a very good one to debug for a "Duplicate Definition".

I'm under the opinion that all variables should be declared. OPTION _EXPLICIT in your code will require this for every single variable. By declaring all variables you get the added benefit of having a detailed listing of your variables followed by a REM statement after each explaining its use:

Code: (Select All)

    DIM lineStart AS Type_Vector2 ' start vector of line (x,y)
    DIM lineEnd AS Type_Vector2 '   end   vector of line (x,y)
    DIM dx AS SINGLE '              run  (delta in the x direction)
    DIM dy AS SINGLE '              rise (delta in the y direction)
    DIM m AS SINGLE '               slope (rise over run)
    DIM b AS SINGLE '               the y intercept

This is a habit, in my opinion, that every programmer should get in to. It GREATLY helps when debugging your own code or asking someone else to have a look at it for help. The above code snippet contains the variables I use in a function that detects a point on a line. Imagine trying to debug this code without declaring the variables and having a description associated with them. Here is the entire function :

Code: (Select All)

FUNCTION PointOnLine (TestPoint AS Type_Vector2, __line2D AS Type_Line2D)

    ' based on the Slope Intercept Form of the equation of a straight line
    '
    '
    '  |                                       S = Line Start = (0,1)
    '  |                             (8,5)     E = Line End   = (8,5)
    ' 5+                             __ù       Need to get values of this formula: y = m * x + b
    '  |                           _-          Solve for m:
    '  |                        _--              - dy = Ey - Sy = 5 - 1 = 4
    ' 4+                     __-                 - dx = Ex - Sx = 8 - 0 = 8
    '  |                   _-                           dy     4     1
    '  |      P         _--                      - m = ---- = --- = --- (m solved)
    ' 3+      ù      __-                                dx     8     2
    '  |    (2,3)  _-                          Solve for b:
    '  |        _--                              - b = y - mx  (plug in x (0) and y (1) from line start)
    ' 2+     __-                                            1
    '  |   _-                                    - b = 1 - --- * 0 = 1 - 0 = 1 (b solved)
    '  |_--                                                 2
    ' 1ù                                       Plug in values from Px along with solved m and b to compare y result with Py
    '(0,1)                                              1
    '  |                                         - y = --- * x + 1 = y = .5 * 2 + 1 = y = 2 (FALSE) 2 is not equal to Py (3)
    '  +---+---+---+---+---+---+---+---+---             2
    ' 0    1   2   3   4   5   6   7   8
    '

    DIM lineStart AS Type_Vector2 ' start vector of line (x,y)
    DIM lineEnd AS Type_Vector2 '   end   vector of line (x,y)
    DIM dx AS SINGLE '              run  (delta in the x direction)
    DIM dy AS SINGLE '              rise (delta in the y direction)
    DIM m AS SINGLE '               slope (rise over run)
    DIM b AS SINGLE '               the y intercept

    PointOnLine = 0 '                                            assume point not on line
    lineStart = __line2D.from '                                  get line start vector (x,y)
    lineEnd = __line2D.too '                                     get line end   vector (x,y)
    dy = lineEnd.y - lineStart.y '                               calculate rise
    dx = lineEnd.x - lineStart.x '                               calculate run
    IF dx = 0 THEN '                                             vertical line? (avoid divide by 0)
        IF TestPoint.x = lineStart.x THEN '                      yes, do x values match?
            PointOnLine = -1 '                                   yes, must be on the line
            EXIT FUNCTION '                                      leave
        END IF
    END IF
    m = dy / dx '                                                calculate slope
    b = lineStart.y - (m * lineStart.x) '                        calculate y intercept
    IF TestPoint.y = m * TestPoint.x + b THEN PointOnLine = -1 ' point on line if y = mx + b

END FUNCTION

[bplus]

and ironically Option _Explicit makes no difference in the example Dimster gave us

Code: (Select All)

'Option _Explicit ' <<< try this with and without comment, no difference
Const i = 1

for i = 1 to 10
print i
next

[Kernelpanic]

When I get a "Duplicate definition" error it's seems to always be related to my misuse of the CONST statement. Somewhere in my program I tried to change the variables value when it supposed to have been fixed.

Option _Explicit is not called for in this case, everything already has worked for your protection.

You declared a variable name to be constant and the IDE is telling you of your blunder of trying to use a Constant like a true variable.

Option _Explicit is just good programming practice, specially for large projects.

A const variable is just a normal variable. If it is misspelled, the following happens: In QuickBasic (Basic in general), a new variable is (was) initialized with 0 by default until it is assigned a value. That means every typing error leads to a new variable with the value 0.

Example of a typo for a const variable (calculate the circumference of a circle):


And this is how the result is correct:

[bplus]

KP "A const variable is just a normal variable."

Then why bother with Const? because it is not just a normal variable.

[Kernelpanic]

KP "A const variable is just a normal variable."

Then why bother with Const? because it is not just a normal variable.

So that it cannot be accidentally changed in the program.

The example above is simple, but in real programs there should be enough reason that certain variables not be can changed in the program (not paying attention!), or by the user.

[Dimster]

and ironically Option _Explicit makes no difference in the example Dimster gave us

Not sure what you mean B .... The example with NO Option _Explicit runs fine with no error, but if you place Option _Explicit at the beginning of that code you get an error warning of an undefined variable. 


Also Kernelpanic ... you mentioned " If it is misspelled, the following happens ".... actual my comments were if it "misused". I suppose that's splitting hairs because I do often misspell an often used variable which I believe you are pointing out Option _Explicit is ideal to catch. But the point I was trying to make, is that there are number of control variables ( ie For x = 1 to 10, or For i = ?? to ??), these control variables I don't think are usually Dimensioned and a program can have a ton of them. Option _Explicit seems to force you to Dimension them.

[mnrvovrfc]

But the point I was trying to make, is that there are number of control variables ( ie For x = 1 to 10, or For i = ?? to ??), these control variables I don't think are usually Dimensioned and a program can have a ton of them. Option _Explicit seems to force you to Dimension them.

It doesn't "seem" to force anybody to do anything. Any variable, regardless of its role, has to be dimensioned (declared) if OPTION _EXPLICIT is in place. What if you wanted to use variable "i" or "x" for something else having to do with integers?

"DIM" keyword caused a fair amount of confusion because "traditionally" it was used to create arrays. Especially in GW-BASIC there was no way to allocate space for an ordinary variable because INTEGER was pretty much the only scalar type. Could have also declared DOUBLE or SINGLE or even STRING but that wasn't thought of until QuickBASIC and QBasic.

On one of the Atari computers, "DIM" was used to allocate string space which added to the confusion. A new keyword should have coined like "GLOBAL". I think some people tried to force the use of COMMON SHARED in QuickBASIC to get away from DIM and leave DIM only to declare arrays.

[TerryRitchie]

But the point I was trying to make, is that there are number of control variables ( ie For x = 1 to 10, or For i = ?? to ??), these control variables I don't think are usually Dimensioned and a program can have a ton of them. Option _Explicit seems to force you to Dimension them.

Yes, it does, and that's the point. BASIC, and by extension QB64, allows the creation of variables "out of the blue" and is one of the main reasons professionals in the IT field say programmers that grew up using BASIC have many bad habits and label BASIC as a language to avoid. I don't agree with their thinking since BASIC was designed this way on purpose and creating variables like this is just fine for BASIC.

However, I think you'll find that declaring every variable, even those control variables, will make your code much cleaner and easier to read and debug in the long run, not only for others, but especially for you. Besides the benefits I've already pointed out by declaring variables with DIM and STATIC, there is another one. You need to think about the control variables beforehand and name them. I would much rather see this:

DIM column AS INTEGER ' text columns on an 80x25 screen
DIM row AS INTEGER      ' text rows on an 80x25 screen

FOR column = 1 TO 80
    FOR row = 1 TO 25
        .... <code>
    NEXT row
NEXT column

than this:

FOR i = 1 TO 80
    FOR j = 1 TO 25
        .... <code>
    NEXT j
NEXT i

The first example control variables are not only documented but self-document as well.

If you decide to start dabbling with another language it more more than likely require declared variables. BASIC does form a bad habit in this sense.