curious syntax-error (problem solved) 1

[EinTerraner]

What in the three devil names is wrong?
I've an custom-class and there are 2 defined properties




both are type of Character and ist's the ASC(250) Char

if i try to use the one named SepChar it gives me


but if i use the 2nd one named "Seperator" then it works without Syntax error

Ok no problem... i can live also with the name Seperator. but i'd like to understand WHY?

 

[atlopes]

Most probably, SepChar is being #DEFINEd somewhere in your application.

You can check this by issuing

#UNDEFINE SEPCHAR

just before the statement that is raising the error.

 

[Mike Lewis]

This is a compile-time error. It would be interesting to know what happens if you ignore the error and proceed with the build. What error do you then see when you run the program?

Mike

 

[mjcmkrsr]

Hi,

SEPARATOR is a tool bar specific object with very limited PEMs (see Help File). My question: what is SEPCHAR? Object or Variable? And what is it supposed to do?

hth

MarK

 

[Chriss Miller]

MarK. a user defined property. The class is based on "custom", that was specified.
So it has nothing to do with the native separator control class.

The problem also is not with the separator property but the sepchar property.

I can't reproduce the problem with a sepchar property name alone, but indeed atlopes idea can be the resason. If you have SEPCHAR defined as somehthing like "-" or '.' then this code

#define sepchar "-"

LC_SepC = This.SepChar

is processed by the precompiler to

LC_SepC = This."-"

And of course that has a syntax error.

The definition could be in an included header file of your class, too, not just a literal #define in the code.

 

[mjcmkrsr]

Hi,

EinTerraner

---

... but if i use the 2nd one named "Seperator" then it works without Syntax error

Hence he considers SEPERATOR and his SEPCHAR equivalent. Meanwhile he should tell us what his intentions are.

MarK

 

[Chriss Miller]

Syntax error free code is the #1 intention.
And #2 understanding what led to the syntax error in compilation of that code.

EinTerraner just stumbled on a self induced problem, not so obvious. Maybe it turns out another mechnaism causes that syntax error, too, you never know. But the #define constant hypothesis is demonstrably explaining it, isn't it? The simplicity of the search&replace of constants in code (case insenseitive, by the way, as VFP is case insensitive anyway) makes it a constant danger. You can take that literally or figuratively.

The naming convention recommendation is to define constants names all upper case, so #Define SEPCHAR "-". But even that will replace a property name SepChar in code with "-", This ambiguitiy of constant names can't be defended against, you have to keep an eye on not using constant names as property names, too, when the constant is present due to direct defines, direct includes or indirect includes. It's worse, because even a proeprty This.SepCharacter would be preprocessed to This."-"acter, so when constant names are just parts of property names or code in general, they get substituted into the code before that is compiled, as long as constant definitions are seen by code, constants are scoped to where they are defined, of course, not generally global.

I could imagine the history of how this evolved: First there was the constant SEPCHAR defined in some header file included in almost any code of a project to have a separator character you could easily redefine in one contral place by changing the constant. Everything works fine, but it seems too rigid to rely on a constantonly, maybe instead define a class that provides different ways to get at the right separator character for the special case involved, context sensitive, for example. One of the ingredients (maybe just for backward compatibility to the constant) is a property that simply has the separator character value. Fine, if that's the case and you changed all places previously using the constant SEPCHAR to use that class property, then the only thing missing is getting rid of the constant definition, problem solved. I bet it's not really the situation, though, I'm not even sure whether there is that constant involved in the problem, just because it can explain the syntax error doesn't mean it is definitely the reason.

It could also be a constant #Define SEP 9 for september the 9th month, but it could also be a completly different mechanism, it could be a hardly spotted point or comma in the line of code that's covered by the error messagebox, it could be anything else, too.

 

[atlopes]

It's worse, because even a proeprty This.SepCharacter would be preprocessed to This."-"acter, so when constant names are just parts of property names or code in general, they get substituted into the code before that is compiled.

Chris,

The VFP compiler only replaces whole defined words in [] delimited strings or regular code statements (I couldn't figure out if you were stating this or otherwise).

CLEAR

#DEFINE SEPCHAR    -

LOCAL TestDummy AS Dummy

m.TestDummy = CREATEOBJECT("Dummy")

? m.TestDummy.SepCharacter

? "SepCharacter"
? [SepCharacter]

? "SepChar acter"
? [SepChar acter]

DEFINE CLASS Dummy AS Custom

    SepCharacter = "/"

*    SepChar = "/"            && this line would raise an error if uncommented

ENDDEFINE

 

[Chriss Miller]

Thanks, atlopes. I don't know why I didn't test and thought it would be worse.

That makes constant substitutions a little less dangerous. Still, it poses a constant danger you could reduce with a prefix only used in contant names, for example. But that's not applicable when using already provided header files like FoxPro.h or third party components.

 

[EinTerraner]

Most probably, SepChar is being #DEFINEd somewhere in your application.

You can check this by issuing

YOU ARE THE HERO

it worked usually since >15 years... until cpl weeks ago.

I had to rebuild/reintergrate a older function to read and acess ancient datafiles created before the €uro replaced the european currency. So I also had to include a older headerfile ".h". There was the

#define    IsExe        JUSTEXT(SYS(16,0)) == "EXE"
#define    IsSrv        UPPER(ALLTRIM(GETWORDNUM(SYS(0),1,"#"))) == PUB_SRVNAME

#define    DosChar    "„”Ž™šáø"
#define    WinChar    "äöüÄÖÜß°"
#define    TelStrip    "<>()[] -/"
....
<cpl dzd more #define-lines here>
....
#define    SepChar   "¶"

defiined. But a few dozend lines below other definitions. Therefore i did not see and/or ignored the line after cleaning up the multiple definitions.

 

[Chriss Miller]

By the way, the COMPILE command will not only list error messages of all errors, they are always preceded by the source code containing the error.

So this little demonstration shows SEP is replaced by 9, SepChar not. Anyway, you can see what the precompiler did. Only for lines that become erroneous, though.

Local lcPrg
Text To lcPRG
#Define SEP 9
Local Sep, Sepchar
EndText
StrToFile(lcPRG,'my.prg',0)

Compile my.prg
Modify Command my.prg nowait
Modify File my.err