Restricted FOXPRO commands (DO NOT USE in Activevfp)

Topics: Developer Forum
Aug 22, 2013 at 7:13 PM
Its come to my attention that certain commands in FoxPro will cause Activevfp to stop working or behave with strange bugs.

Please help me with this list.
  1. set procedure to filename.prg
Instead use: set procedure to filename.prg additive
Aug 22, 2013 at 7:24 PM
Edited Aug 22, 2013 at 7:59 PM
It's in the Documentation already:
"Centralizing Foxpro code for re-use:

Custom or existing VFP Functions, Procedures, Methods can use the traditional ways to centralize VFP code:

(but I'm sure the wording or the placement is somehow not right for you. Oh yeah, I forgot it's supposed to be our fault YOU didn't read the Documentation, look at the examples, or ask specific questions)

And ALL the examples in the Demo code......
Aug 22, 2013 at 8:10 PM
Claude its a pre-processor idea that you simply run your PRG's through and HUGE
mistakes will be auto corrected.

Einstein would approve
Aug 22, 2013 at 8:31 PM
abigdreamer, did you even look at the Help file of VFP about set procedure? Let me quote this for you.
Issuing SET PROCEDURE TO without any file names closes all open procedure files. Use RELEASE PROCEDURE to close individual files.

When you execute a procedure, the procedure files are searched if the procedure isn't located in the currently executing program.

For more information about procedure files, see PROCEDURE Command and DO Command.

If a COM dynamic-link library (DLL) which uses SET PROCEDURE TO is instantiated more than once, the Init method of the second instance may fail with one of the following messages:

OLE error code 0x80004005: Unspecified error.

OLE error code 0x80020009: Exception occurred.

To instantiate an OLEPUBLIC class, Visual FoxPro must be able to find all the code for the class. There is an internal SET PROCEDURE/SET CLASSLIB to detect all the related code; if you try to change this setting, an error occurs. To prevent this, use SET PROCEDURE TO with the ADDITIVE keyword.
I'm pretty sure you know that aVFP run as a COM object right?
Aug 22, 2013 at 9:06 PM
I obviously didn't read this part of the documentation because I certainly would not have wasted weeks of work

I just assumed that it was a FOXPRO back end and FoxPro commands would work.

Big mistake on my part. Like huge.

You can't treat it like a FoxPro app on the back end. You have to treat it like a special app that has
commands that don't work and cause failure.

In an obvious world these commands would PREVENT the activevfp code base from even working so
idiots like me that don't read the documentation would still be ok.

This is why I suggested a PRE Processor or Code that is ran somewhere that prevents GOTCHA code from
even being written.