Function not seen by a Build

[stanlyn]

Hi,

I'm getting several build errors like this... (some in forms and some in .prgs...)

Program s:\projects\vfp\stanlyn\dri_dev\server\programs\welcomeuser.prg has the following errors:
Proc./Func. SHOWLOADCLERKSPRINTERMESSAGEBOX - Undefined

The function is actually located in the MasterProcs.prg file and does NOT error when the app runs in dev mode, and probably will not error as an exe. These errors are in the .err file at the end of a build.

Now, what do I put in the welcomeuser.prg that informs the builder where the function is?

VFP9sp2

Thanks, Stanley

 

[Mike Lewis]

You need to include an EXTERNAL statement in the files that reference the function. Something like:

EXTERNAL SHOWLOADCLERKSPRINTERMESSAGEBOX

The VFP Help file will give you more details.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[stanlyn]

Hi Mike,

I read the details and I get:

EXTERNAL PROCEDURE SHOWLOADCLERKSPRINTERMESSAGEBOX

I added it to the prg as listed in the .err file and ran a new build. After the build, the same item is still showing in the .err file.

Not sure what is going on here... I expected the build error report to remove those entries where I added the external command. The whole idea is to have a clean build report... (right?)

Thanks, Stanley

 

[Olaf Doschke]

The EXTERNAL command needs to point to the file that really contains the missing procedure/function, otherwise that missing reference is not resolved and the build still reports the error, as it still can't verify a definition will exist at runtime.

This for example happens, if you have sections where you SET PROCEDURE or SET CLASSLIB based on meta data instead of hardcoded calls, so the compiler doesn't know where to look for that function, procedure, class or whatever that is.

EXTERNAL FILE c:\somepath\some.prg
or
EXTERNAL FILE c:\somepath\some.vcx

With some.prg inclluding the definition of SHOWLOADCLERKSPRINTERMESSAGEBOX will help there to really get rid ofg the build error. You're still responsible for the SHOWLOADCLERKSPRINTERMESSAGEBOX being available at runtime, the build does only check it's within the external files, it does then skip to check, if at some point you do SET CLASSLIB, SET PROCEDURE to it.

Bye, Olaf.

 

[Mike Lewis]

There are two separate ways of using EXTERNAL that are relevant here.

First, you can use it to point to the specific file that contains the referenced procedure. In that case, you use EXTERNAL FILE, and give it the actual filename, including the extension.

However, contrary to what Olaf has posted, my understanding is that you don't include the path to the file. If you do, it will be ignored. Instead, you have to ensure that the file is in the current search path. (Olaf, let me know if you think I'm wrong about that.)

The other way of using it is to say EXTERNAL PROCEDURE and then specify the name of the procedure (not the file that contains it).

I would try both of these before going any further.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike,

I'm not shure, whether that's wrong or right, but it can easily be verified by adding a SET PATH containing the file in question.

I just made some tests with EXTERNAL FILE only and that wasn't very en lightening. Build seems also to be taken into account, what is still in memory, eg once the build was successful without any error, I could also remove EXTERNAL FILE and it still woul work. I am not sure why that is the case.

Another way would be to add a section #IF .F. ... #ENDIF into main.prg containing all the missing definitions as dummies.

You still need to be aware of what is missing from the point of view of the compiler and ensure it's available at runtime.

For example if it's stored procs, it's also sufficient to add the dbc to the project, even excluded. VFP will then see the procedure called is within the dbc.

The essence is: If VFP can see where some class,procedure, array etc is during build, you have no missing definition reported. How you achieve that doesn't matter, as long as you're sure it always will work at runtime. It's one of the downisdes of VFP being dynamically typed in contrast to strongly typed languages.

Bye, Olaf.

 

[stanlyn]

This is also failing the build which would be fine in production...

file is "welcomeuser.prg"...
Do 'ShowLoadClerksPrinterMessagebox' IN 'MasterProcs'

The procedure CALL "ShowLoadClerksPrinterMessagebox" which is in "welcomeuser.prg" is located in my masterprocs.prg file.

I've tried all these iterations and all have failed the build:
1. EXTERNAL SHOWLOADCLERKSPRINTERMESSAGEBOX
2. EXTERNAL PROCEDURE SHOWLOADCLERKSPRINTERMESSAGEBOX
3. Do 'ShowLoadClerksPrinterMessagebox' IN 'MasterProcs', origionally it was "Do 'ShowLoadClerksPrinterMessagebox'"
4. EXTERNAL FILE 's:\projects\vfp\stanlyn\dri_dev\server\programs\MasterProcs.prg'
5. EXTERNAL FILE 'MasterProcs.prg'
6. EXTERNAL FILE 'MasterProcs'

Please note that this is only failing the build. It works fine in the dev env.

What else can I try?

Stanley

 

[stanlyn]

Also, I have a

Do 'ShowMsgBox'

that is not showing up in the builds .err file that resides in the same prg file. Same issue, as the ShowMsgBox function actually is in the MasterProcs.prg...

Only difference I see is the long procedure name vs a short name. ShowLoadClerksPrinterMessagebox vs ShowMsgBox

Any limits?

 

[stanlyn]

Solved........

My fault, ShowLoadClerksPrinterMessagebox in the masterprocs file was actually ShowLoadClerksPrinterMsgbox

Looks as if I had made part of the changes the last time I worked on it (over a year ago) and did not finish it for whatever reason...

Anyway, so sorry for wasting everyone's time.... It was the last message where I reported that one of the functions was ok and others were not, so I explicitly searched for them, and there were none. I searched for part of the name and found them with the messagebox shortened to msgbox.... I removed all references to external, shortened the names and build is now happy...

Thanks, Stanley