Page 1 of 3
MEMVARs, PUBLICs etc.
Posted: Mon Apr 29, 2019 6:09 pm
by Karl-Heinz
Guys,
a journey back to the roots
I´m just playing with the PUBLIC/PRIVATE/MEMVAR feature. That´s what i´ve noticed so far:
1. If a PUBLIC is declared and no value is assigned, the initial value is NIL and not .f. It seems that it´s not possible to declare a PUBLIC within the Start().
2. It´s not possible do declare a PRIVATE and assign a value at the same time. Depening on the compiler setting either a warning or an error is thrown.
More comments and some tests are in the attached ZIP which contains a XIDE viaef and a dbf
NOTE: currently the path to the used DBF points to "D:TEST"
The used compiler switches are "-memvar+ -undeclared+"
Any comments are welcome.
regards
Karl-Heinz
MEMVARs, PUBLICs etc.
Posted: Mon Apr 29, 2019 9:11 pm
by Chris
Hi Karl-Heinz,
Oh, I completely forgot to add support for those compiler options in the property pages, sorry about that, will do it ASAP. Thanks for your reports, indeed this feature has been tested very little, will log all the issues so they will be taken care of.
MEMVARs, PUBLICs etc.
Posted: Tue Apr 30, 2019 7:03 pm
by robert
Karl-Heinz,
Thanks for the report. Will check this out asap.
Robert
MEMVARs, PUBLICs etc.
Posted: Tue Apr 30, 2019 10:37 pm
by Chris
Robert, I have added a cut down compiler test for that.
MEMVARs, PUBLICs etc.
Posted: Sat May 04, 2019 8:58 am
by Karl-Heinz
Hi Chris,
two notes.
1. In my sample there is the procedure
Code: Select all
PROCEDURE ThisDoesNotCompile()
#IFDEF __COMPILEERROR__
MEMVAR Amount, Address
PRIVATE Amount := 100
#ENDIF
RETURN
i´ve enabled the VO compatible preproccessor behavior and added
#DEFINE __COMPILEERROR__ := FALSE
but It seems the VO8 switch has no effect, because the #IFDEF code is not ignored. BTW. The compiler macro __VO8__ shows correctly .t. if the VO8 setting is enabled.
2. Typed/Untyped Start()
The app must use a typed Start() otherwise it doesn´t compile. Wouldn´t it make sense to allow a untyped Start() if the memvar "mode" is enabled ?
Regards
Karl-Heinz
MEMVARs, PUBLICs etc.
Posted: Sat May 04, 2019 9:56 am
by Chris
Hi Karl-Heinz,
Remove the ":=" from your #define and it should work as expected. Remember, #define is a preprocessor directive (so no :=), while a DEFINE is "executable" code, so you do need the := with them.
About an untyped Start(), I think it's a requirement of the framework that the Start/Main function (the entry point) has one of few specific signatures, so we cannot allow everything. But Robert may correct me if i am wrong.
MEMVARs, PUBLICs etc.
Posted: Sat May 04, 2019 10:47 am
by Karl-Heinz
Hi Chris,
Yes,
#DEFINE __COMPILEERROR__ FALSE // or TRUE
behaves as expected.
Thanks !
regards
Karl-Heinz
MEMVARs, PUBLICs etc.
Posted: Tue May 07, 2019 11:15 am
by robert
Karl Heinz,
I have looked at this and found the problem with the File Wide PUBLICs: they were parsed incorrectly as GLOBALs and not as PUBLICs. That is why they were initialized with NIL in stead of FALSE. (PUBLIC in X# is also an alias for EXPORT, and this caused the confusion). I have fixed that now.
Since there is no "Context" in which they can be initialized they will now be initialized in the same code where Init procedures are called at startup of the app. The file wide PUBLICs are now initialized after all INIT3 procedures have been called.
Robert
MEMVARs, PUBLICs etc.
Posted: Tue May 07, 2019 6:31 pm
by Karl-Heinz
Hi Robert,
In the meantime i´ve found a "workaround"
to create PUBLICs
Code: Select all
FUNCTION Start() AS VOID
Example3()
? "Content of the Public gc4" , gc4
RETURN
PROCEDURE Example3()
// PUBLIC gc4
__MemVarDecl("gc4" , FALSE )
? "content of gc4: " , gc4 // ok, shows FALSE
gc4 := "I´m a public"
RETURN
regards
Karl-Heinz
MEMVARs, PUBLICs etc.
Posted: Tue May 07, 2019 7:06 pm
by robert
Karl Heinz,
You found the right function.
This is fixed now in the compiler as well.
Robert