Problem with include file 1

[Nifrabar]

Hi!

In my start.prg I put:
#INCLUDE myIncludeFile.H

Than, to check in development environment:

If Version(2) <> 0
=messagebox(ccMyConstantVar)
Endif


The include file is in the searchpath.

Sometimes VFP complains with error : variable ccMyConstantVar is not found.

Than I tried :
#INCLUDE "myIncludeFile.H" i.s.o. #INCLUDE myIncludeFile.H

That seemed to help...
But again after a while same error.
The anoying thing is that it seems to be spurious.


Than I tried just after
#INCLUDE myIncludeFile.H
=inkey(.2).

This way there is some delay before the messagebox pops up.

This now seems to help.
Anyone met this problem before?

-Bart

 

[RickBorup]

Sometimes VFP complains with error : variable ccMyConstantVar is not found.

From what you've said, I assume you've defined ccMyConstantVar in myIncludeFile.h with something like

#DEFINE ccMyConstantVar "foo"

If that's true, then you're getting that error message because ccMyConstantVar is not a variable, it's a defined constant.

Defined constants are preprocessor directives that tell the VFP compiler to substitute the value for the constant's name at compile time. Defined constants have meaning only at compile time, and only within the program that's being compiled. Thereafter, they are literals.

For example, if you write a program that #INCLUDEs myIncludeFile.h and does a MESSAGEBOX on ccMyConstantVar, two things happen: First, the #INCLUDE statement is equivalent to placing the #DEFINE statement itself at that point in the program. Second, the compiler substitutes the value of ccMyConstantVar, which is the string "foo", in place of the name ccMyConstantVar at compile time.

#INCLUDE myHeaderFile.h
MESSAGEBOX( ccMyConstantVar)  && Shows "foo" at runtime

At runtime, this is equivalent to

MESSAGEBOX( "foo")

Defined constants are evaluated at compile time, not at runtime. That's why you can't reference ccMyConstantVar elsewhere as if it were a memory variable.

 

[Nifrabar]

RickBorup,

Thanks for this explanation.
Now a Q remains: why gives my code spurious faults as results than while also often this goes well?

-Bart

 

[RickBorup]

Help me understand what you meant when you said

Than, to check in development environment:

If Version(2) <> 0
=messagebox(ccMyConstantVar)
Endif

In what program did you place this code, and does that program have #INCLUDE myIncludeFile.h in it?

 

[Nifrabar]

RickBorup,

All what is in this thread takes place in the development environment. The exe-version never complains.

#INCLUDE myIncludeFile.h is in my start.prg

just to check if I could use the Constants, also in the start.prg:
If Version(2) <> 0
=messagebox(ccMyConstantVar)
Endif

-Bart

 

[Mike Lewis]

Bart,

You might find it more reliable to reference the Include file from the Default Include File entry in Tools / Options / File Locations. Or from _INCLUDE.

In that case, you would set the option to point to the actual .H file, rather than a PRG that contains a #INCLUDE.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

Including an H file in your start program isn't sufficient. You have to include it in every PRG, VCX and SCX.

Tamar

 

[Nifrabar]

Mike and Tamar,

I agree for sure thet the include file must be in every .prg .vcx or .frm.
But nevertheless I don't understand why (spurious) in my start.prg (without having some delay by inkey(.2)) the error comes up.

-Bart

 

[RickBorup]

Bart,

We have to infer a couple of things from what you've posetd. It sounds like start.prg is the main program in an application, and that when you say "the exe-version never complains" you're talking about running the EXE generated by building the project. This makes sense, because building the EXE compiles the PRG, and the compiler substitutes the value of ccMyConstantVar into the compiled code at that time.

However, it isn't clear how you're running start.prg in the development environment. Are you running the compiled EXE from the command window, for example? Whatever you're doing, there is some code running that, when compiled, did not recognize the defined constant and is therefore trying to treat ccMyConstantVar as a memory variable. If you can supply additional details maybe we can figure this out.

 

[Nifrabar]

RickBorup,
Your explanation headed me to a solution.

In my main.prg the code starts with

IF VERSION(2) <> 0 && Ontwikkelomgeving
	CD "D:\BartSr\VFP\Projects\Begraafplaats"
ENDIF 

CLEAR ALL
CLOSE DATABASES ALL 
CLOSE TABLES ALL 

#INCLUDE "CEMETRY.H"
IF VERSION(2) <> 0 && Ontwikkelomgeving
	=INKEY(.2)
ENDIF
=MESSAGEBOX(ccAppName)

Once a project is build than according your explanation the constants which are defined in the .H file will have the defined values substituted.

In my develop-environment I do start the application by hitting the run-button of the project-manager.
I believe here is the key to my problem; the main.prg will not always be compiled if no changes has been made to the main.prg.

My solution which I definitly expect to work is to add a 2-line piece of code in a seperate prg.

COMPILE main.prg
DO main

This way main.prg is forced to be compiled always.
What's your opinion on that?
-Bart

 

[RickBorup]

In my develop-environment I do start the application by hitting the run-button of the project-manager.
I believe here is the key to my problem; the main.prg will not always be compiled if no changes has been made to the main.prg.

OK, now we're getting somewhere. < smile > Here's what's happening: When you select main.prg in the project manager and click the Run button, VFP silently compiles the program but cannot find the #include file if it's not along the current path. When this happens VFP creates an error file with the same name as the prg. Look for main.err in the same folder as main.prg and open it in Notepad. You should see something like this:

#INCLUDE "CEMETRY.H"
Error in line 8: File does not exist.

The solution is to specify a full path or at least a relative path for the header file in the #include statement. For example:

#INCLUDE include\cemetery.h && if file is in "include" subdirectory

You do not need to do an explicit COMPILE command. VFP automatically compiles the program if the .fxp is missing or if the .fxp is older and SET DEVELOPMENT is ON, which it is by default.

 

[Nifrabar]

Rickborup,
Just one last question. Thereafter I feel I know why I got my errors:
In my prg I set the path to, among others, the .h file location.
But do I understand you well that as the compile is taken place before the .prg actually is executed the .h file was not found and therefore the prg complains?

-Bart

 

[RickBorup]

In my prg I set the path to, among others, the .h file location.
But do I understand you well that as the compile is taken place before the .prg actually is executed the .h file was not found and therefore the prg complains?

Yes, that's correct. Setting the path to the location of the .h file in the prg has no effect on the compiler because the program is compiled before the SET PATH statement in the prg is run. What matters is that the path includes the location of the .h file at compile time, or alternatively that the #include statement has a full path or a relative path the compiler can resolve.

The reason you may have been seeing what you described as spurious results is the path is set the first time you run the program. Assuming the path was not set before you ran the program for the first time, the first compile would fail to find the .h file and you would get the runtime error. However, if you did not reset the path between runs, then subsequent compiles would find the .h file and there would be no runtime error.

 

[Nifrabar]

RickBorup,

Thanks for your patient in explaining.
This error 'followed' me already very long time but as the runtime version never complained I did not take the time to solve it. And yes, agreed, mostly the error came up at first run of .prg

Star for you!

Thanks,
-Bart

 

[RickBorup]

You're welcome, Bart. Thanks to you for continuing to provide information until we figured this out.

-Rick