Procs used from cache

[vfp7guy]

Can anybody give a little more explanation on VFP's execution of procedures/functions from previously-used copies in cache as opposed to reloading the <procname> with each "SET PROC TO <procname>".

For example, in a system with 200 SCXs spread across 30 EXEs that are connected via a master menu program, and each SCX has a "SET PROC TO <procname>" in its LOAD, am I right in assuming that if that <procname> is still in cache from being used a minute ago in one of the calling EXEs, that the newly-called SCX/EXE may use the cached version instead of the version that was compiled?

What I am trying to get at is this: If you have a master EXE that can call 20 EXEs, all with the same "SET PROC TO <procname>" in the SCXs, but you modify one function in that <procname> that is only used in 2 of the called EXEs, do you need to rebuild ALL EXEs, or can you get by with only rebuilding the main EXE and the 2 EXEs that use that particular function in <procname>?

I would appreciate any input that can help me understand exactly how VFP behaves when it comes to using existing cached code as opposed to using all the code from the most recently used EXE. TIA.

 

[Mike Lewis]

VFP7Giu,

each SCX has a "SET PROC TO <procname>" in its LOAD, am I right in assuming that if that <procname> is still in cache from being used a minute ago in one of the calling EXEs, that the newly-called SCX/EXE may use the cached version instead of the version that was compiled?

I don't know for sure, but I would think it's safest to assume that to be the case.

From what you are saying, it sounds as if your proc files exist as free-standing PRGs, rather than being bound into the EXEs. If so, CLEAR PROGRAM might solve the problem, although I'm not sure if that's available from within an EXE.

Also, I wonder if your overall approach is really sound. Wouldn't it be better to move the functions and procedures from the proc file into methods of the form? After all, procedure files are really a hang-over from the old non-OOP world.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[vfp7guy]

Thanks for the reply Mike.
Yes, much of the system originated back in the early FoxPro days with SPRs and such. It is pretty well all VFP native code / methods now, but we have still left some procedures / functions that are used in most SCXs in a common PRG. The positive side of this is only having to change 1 source location rather than a few hundred identical methods, but the downside now is the possibility on having to rebuild ALL projects, even if the particular revised function isn't used in every project.

We did recently take one function and make it into a DLL, but experienced a few problems at a few client sites with some new network permissions issues when an object is created from that DLL. Note that this new problem has only arisen since our distribution of our latest upgrade using VFP9 as opposed to VFP8.

 

[TamarGranor]

The positive side of this is only having to change 1 source location rather than a few hundred identical methods, but the downside now is the possibility on having to rebuild ALL projects, even if the particular revised function isn't used in every project.

The happy medium between these two is putting the code into methods of your base form class. Then you only have one place to change them and you only need to rebuild affect apps.

Tamar

 

[chrowland]

Assuming your 20 exe's are separate projects, you can exclude the procedure files from them and include the procedure files in the main menu executable. Then when one of them is changed, just recompile and deploy the main executable. The other 20 exe's do not have to be touched.