Question 1:JaxMusic wrote:versus the procedure
I changed the procedure reference to match. I am guessing that EventType is a system variable, so the procedure would have to match it?
The parameter variables in the actual procedure and the declaration need not match
name-wise but must match
type-wise. So, the following are correct:
Code: Select all
;the parameter variable [anything] defaults to integer type (.i) when no type indicated
Declare buttonEvent(anything)
is compatible with:
Code: Select all
;the type must match the declaration - the parameter variable [somethingElse] also defaults to integer type (.i) since no type indicated
Procedure buttonEvent(somethingElse)
The following, with
string-type parameters, are also correct:
Code: Select all
;the parameter variable [stringVariable] is declared explicitly as string type (.s)
Declare someProcedure(stringVariable.s)
is compatible with:
Code: Select all
;the type must match the declaration - the parameter variable [anyVariableName] must also be declared explicitly as string type (.s)
Procedure someProcedure(anyVariableName.s)
is a PureBasic function, but since
PureBasic allows the use of same names between functions and variables,
EventType by itself
(with no bracket suffix) simply refers to a variable. Notice the difference in the form code:
Code: Select all
; no brackets here - EventType refers to an integer (.i)
; variable (the same name is used to be more descriptive)
Declare buttonEvent(EventType)
...
...
; with brackets here - EventType() refers to the PureBasic function.
; the result returned by the EventType() function is of an integer type (.i),
; and will be passed as the argument for the buttonEvent() procedure,
; and will therefore match the declaration above.
buttonEvent(EventType())
...
...
JaxMusic wrote:How does the compiler know where to start? There is no void main() like in C. Does it just start at code that it first encounters that is not in a procedure?
Yes. Any code not encapsulated in procedures or modules fall within the
global scope and will be executed sequentially as they are encountered. Furthermore, since PureBasic is a single-pass compiler, all definitions for arrays, variables, structures, procedures, etc., must precede their reference;
meaning they must be defined or declared before they are used. Here are some examples:
Code: Select all
;the first usage of any variable will automatically define it.
;in this case the variable [x] is defined with the default type
;which is the integer type (.i) and assigned with a value of 0
Debug x ; = 0 and not 9
;this essentially re-defines variable [x] as an integer and assigns it
;a value of 9 - this definition has no bearing on the earlier usage
Define x = 9
Debug x ; = 9
Similarly:
Code: Select all
Debug add(1, 2) ;throws the error [add() is not a function...]
;DEFINED after being called (incorrect)
Procedure add(a, b)
c = a + b
ProcedureReturn c
EndProcedure
The proper sequence should be:
Code: Select all
;DEFINED before being called (correct)
Procedure add(a, b)
c = a + b
ProcedureReturn c
EndProcedure
Debug add(1, 2) ; = 3
And this works too:
Code: Select all
;DECLARED before being called (correct)
Declare add(x, y) ;here the parameters are x & y
;the function [add()] is recognised here because it was declared above before being called
Debug add(1, 2)
;the function is defined after being called but works because it was declared before the first call
Procedure add(a, b) ;here the parameters are a & b
c = a + b
ProcedureReturn c
EndProcedure
It should also be noted, that the
EnableExplicit directive overrides automatic definitions, and requires all variables to be explicitly defined before use
(eg: Define anIntegerVariable.i, someFloatVariable.f, anyStringVariable.s, etc).
Question 3:
JaxMusic wrote:What do you mean by take note of the paths? Is there an organizational issue here that I should be cognizant of? In this case I just put all the files in the same test directory I'm using.
PureBasic recognises both
absolute file paths as well as
relative file paths. The following illustrates them:
Code: Select all
;absolute file path
filename.s = "C:\somePath\someFolder\actualFile.txt"
;relative file path
filename.s = "actualFile.txt"
Both assignments above
refer to the exact same file, in the exact same location.
The first reference, qualified with an
absolute file path, works regardless of where the calling code file resides. The code file can be saved anywhere, even on any other disk, because the reference to the file is absolute
(C:\somePath\someFolder\actualFile.txt).
However, the second reference, with only a
relative file path, works only if the calling code file resides in the same folder as the referenced file, which means that it must be saved in [C:\somePath\someFolder\] in order for it to find the file [actualFile.txt].
Question 4:
JaxMusic wrote:; Event procedures need to be put in another source file.
I assume this is because the form is exclusive to form procedures?
No. This is because the form code file, which is automatically generated by the Form Designer, shouldn't be modified. Any code changed or added within
form files (.pbf) will be purged, and the original code will be restored, when the form file is opened and read by the Form Designer. So, in order to continue to use the Form Designer to amend and update form files, it would be best to keep all other code in separate files.
Question 5:
JaxMusic wrote:Are these "#PB_Event" constants always generated in a form?
The standard events procedure
(as shown below) is generated only when the
Generate Events Procedure checkbox is selected in the form's
Property window, under the
Layout properties. Deselect that, and the procedure will be removed. The constants
(#PB_Event_CloseWindow, #PB_Event_Menu, #PB_Event_Gadget) are built-in PureBasic constants referring to window events that are triggered when a window is closed, a menu item is selected, or a gadget event occurred
(respectively). There are other events as well
(eg: #PB_Event_Timer, #PB_Event_SysTray, etc.), which are not included in the form code because they do not fall under the purview of the Form Designer.
Code: Select all
Procedure Window_0_Events(event)
Select event
Case #PB_Event_CloseWindow
ProcedureReturn #False
Case #PB_Event_Menu
Select EventMenu()
EndSelect
Case #PB_Event_Gadget
Select EventGadget()
EndSelect
EndSelect
ProcedureReturn #True
EndProcedure