Listing all the activated SET PROCEDURE files 1

[dkean4]

I am making use of SET PROCEDURE files a lot and I need, at times, to know is one particular "SET PROCEDURE" file has been SET already. Alternatively, what are the implications of reloading SET PROCEDURE with the ADDITIVE option on top of an loaded or SET file? Consider this:

SET PROCEDURE TO clockfuncs.prg
SET PROCEDURE TO Assets.prg
SET PROCEDURE TO JS_Abstracts.prg
SET PROCEDURE TO HTML_Vocabulary.prg
SET PROCEDURE TO NodeJS_NPMs.prg
SET PROCEDURE TO Python_Lib.prg
...

Now, not knowing that the Assets.prg file is set already I issue:

SET PROCEDURE TO Assets.prg

Furthermore, is there a simple command to list all the functions and procedures in a particular "SET PROCEDURE" file? I could not find anything so far.


TIA





Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[yahiadal]

?SET('PROCEDURE')

you should use the additive key when using more than one procedure files

yahya

 

[Mike Lewis]

Yes, ?[tt] SET("Procedure")[/tt] will give you a comma-separated list of all your active procedure files. If you want to get them into an array, use[tt] ALINES()[/tt]. If you want to get them into a cursor, use [tt]STRTOFILE()[/tt] and then [tt]APPEND FROM[/tt].

To answer your other question, if you [tt]SET PROCEDURE .... ADDITIVE[/tt] and then do the same again with same file (loading "on top of"), that works fine. In my tests, I can see no performance or memory penalty in doing so.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Although there is no performance penalty in opening the same procedure file multiple times, it would make for cleaner programming to avoid doing so. There are several approaches you could to take instead.

One approach would be to open all your procedure files at the same time, at the start of your program. Then forget about them. Leave them open throughout the session so that the procedure can be executed as and when needed. (This is my own preferred method, although I rarely have more than two procedure files in a given application.)

If you really want to open a procedure file on an ad hoc basis, perhaps for use in a single object or function, then do so, but close it again when you have finisehd (using [tt]RELEASE PROCEDURE[/tt]). But note that if you open the same file multiple times (using [tt]ADDITIVE[/tt]), then [tt]RELEASE PROCEDURE[/tt] will close all instances, which is probably not what you want.

The other alternative is not to use procedure files at all, but rather to hold each routine in a separate PRG, the name of which matches that of the procedure or function. That way, you won't need to think about where the routine resides. You just call it in the usual way. (There are pros and cons to this approach. I suspect that Tamar will jump in here, as I know she has views on this subject.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

[pre]Function addProc
Lparameters lcProcedure
Local llReturn
If Not Upper(lcProcedure) $ Upper(Set("Procedure"))
Set Procedure To (lcProcedure) Additive
Else
llReturn=.T.
Endif
Return llReturn[/pre]

 

[Olaf Doschke]

You don't need those statements in the compiled version anyway, so don't put too much effort in maintaining a handling of setting and releasing PRG files. Same goes for class libs. I have a routine, that grabs all file locations from the PJX file for both PRG and VCX and puts them into a meta data dbf. That is scanned at startup to make all SET PROCEDURE and SET CLASSLIB calls. Done. I avoid cases where two PRGs implement different versions of the same procedures or classes, I avoid double names overall, and the amount of memory this takes is quite unimportant. At runtime I do use newobject() for classes located in external VCX or APP files as extension for anything compiled into the main EXE, but I don't need to manage adding and releasing memory for procedure or class definitions. All internal class usage can be by CreateObject() or object.AddObject(), if objects are not already put on forms at design time.

Bye, Olaf.

 

[dkean4]

yahya

Yes, I was speeding through. Thank you for the reminder, friend.

SET PROCEDURE TO clockfuncs.prg ADDITIVE
SET PROCEDURE TO Assets.prg ADDITIVE
SET PROCEDURE TO JS_Abstracts.prg ADDITIVE

Indeed... SET() Ah what is wrong with me. I am getting old. Thank you so much...

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[dkean4]

Mike Lewis

To answer your other question, if you SET PROCEDURE .... ADDITIVE and then do the same again with same file (loading "on top of"), that works fine. In my tests, I can see no performance or memory penalty in doing so.

I saw no problems myself, but that did not stop me from worrying if some memory stack was inflating etc... Good to hear that you have dealt with that already. Thank you for letting me know.

The other alternative is not to use procedure files at all, but rather to hold each routine in a separate PRG, the name of which matches that of the procedure or function. That way, you won't need to think about where the routine resides. You just call it in the usual way. (There are pros and cons to this approach. I suspect that Tamar will jump in here, as I know she has views on this subject.)

These are topical sets of routines. They work with one another as a set in each SET PROCEDURE. I keep them in tables and combine them on the fly. If I loaded all of them it would massacre the memory and I am not sure how it could weed through 100,000 routines without affecting performance. Most of the procedures will not be used most of the time. I do not want to bloat the application. It is already a hog in the in opening of databases. So, I designed a manager for the procedures being combined, invoked to ascertain sufficiency.

Also, I was talking about reloading the exact same SET PROCEDURE twice, not slightly different ones.

All your points are excellent. Thank you for thinking with me on this, Mike.

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

>weed through 100,000 routines
I don't think you mean that literally. Unless you build a memorial of all VFP code ever written .

If so, in regard of the procedures/functions the strategy to have one per PRG, using the PRG filename as procedure/function name and just having the core procedure in a PRG (starting directly with LPARAMETERS, the compiler you can start a PJX with an empty list of programs, just have your main and other project specifics and build to only pull in the PRGs called. I never used or found this strategy necessary, though.

Bye, Olaf.

 

[Mike Lewis]

Dennis, surely you didn't really mean you have 100,000 routines? How is that remotely possible?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dkean4]

Olaf

I have spent time thinking about using Classes to harness the code, but as you know, from my previous posts, I created PROCEDUREs and FUNCTIONs on the fly in an Editor of my own making in VFP. The class generation seems to me to take more effort to organize, but I could be wrong. Classes can be written in code too. I need to look into it some more. Currently I am operational and able to use the dynamic editor effectively. I wrap it with a structure I call "Goal Designer" and that has an advantage of allowing me to reuse low level functions before their goal is honed for specific tasks. That allows me to isolate functional design to a higher level. I have not thought this through enough and will use your comment for inspirational thinking.

Thank you for lending your thoughts, Olaf.


Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

>Classes can be written in code too. I need to look into it some more.
Making them known to VFP is covered with SET PROCEDURE, too - or simply including them in the EXE.

Files with class definitions have no similar concept as the single proc/func PRG files have, unless you revert to only VCXes with each one class, but even then the builder/compiler won't "discover" the VCX files by a mere CREATEOBJECT("class"). So the libs have to be organized in some way no matter if PRG based or "visual" VCX class libs and classes.

I don't even know if the PJX is a concept you'd like to get rid of for your re-bootstrapped VFP IDE/Editor, you could skip the project manager overall, especially since it ain't available at runtime and do your own manager of a PJX. But that faces the next problem: BUILD isn't available outside the original VFP IDE, it's just built into VFP9.EXE and not VFP9R.DLL,

The only thing you have available at runtime is COMPILE, and that only updates VCTs with object code and creates FXPs from PRGS, COMPILE DATABASE also is available for DBC, but nothing creating DLLs or EXEs or even just APPs.

Bye, Olaf.

 

[dkean4]

Olaf,

>weed through 100,000 routines
I don't think you mean that literally. Unless you build a memorial of all VFP code ever written .

It is an estimate. Actually I have thousands of routines, many of which I have written myself, over the years... Look in your own closet and start counting, Olaf. You will be amazed at what comes out. Not all are candidates for use, but I am working on automation which will let the PC do coding of some functions without my supervision. 100,000 is a conservative estimate.

I always appreciate your advice, Olaf. Thank you!

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[dkean4]

Olaf

>Classes can be written in code too. I need to look into it some more.
Making them known to VFP is covered with SET PROCEDURE, too - or simply including them in the EXE.

Files with class definitions have no similar concept as the single proc/func PRG files have, unless you revert to only VCXes with each one class, but even then the builder/compiler won't "discover" the VCX files by a mere CREATEOBJECT("class"). So the libs have to be organized in some way no matter if PRG based or "visual" VCX class libs and classes.

I don't even know if the PJX is a concept you'd like to get rid of for your re-bootstrapped VFP IDE/Editor, you could skip the project manager overall, especially since it ain't available at runtime and do your own manager of a PJX. But that faces the next problem: BUILD isn't available outside the original VFP IDE, it's just built into VFP9.EXE and not VFP9R.DLL,

The only thing you have available at runtime is COMPILE, and that only updates VCTs with object code and creates FXPs from PRGS, COMPILE DATABASE also is available for DBC, but nothing creating DLLs or EXEs or even just APPs.

Bye, Olaf.

Olaf, what I am doing presently is working great. I can edit code, modify it any time I wish, run it with, EXECSCRIPT(), Compile it, use Macros, SET PROCEDURE etc... No limits so far! I have speech recognition and can issue commands to VFP from Chrome... I get the impression that you are telling me that my options are dismal!

It is working great so far. And I so appreciate your and the other guy's insights.

Once again, thank you all very much and my apology for my terrible forgetfulness of things I once knew, which evaporated over the years. It is awesome to be in touch with all you kind people.

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[dkean4]

Mike Lewis

Dennis, surely you didn't really mean you have 100,000 routines? How is that remotely possible?

In Machine Intelligence the user does not code everything. In fact I only code patterns, which are written in VFP code of a sort. The MI codes and wires the rest. And as time passes it starts to recognize the patterns and adopt them without asking the user. I do not intend to spend the rest of my life coding VFP. But MI can also help me with other scripts/languages, once it becomes efficient with pattern recognition. To become an effective full stack developer one needs to help himself. VFP is a goldmine for Automation, Mike, as you no doubt know.

3 years ago I automated a conversion of Bootstrap code from version 2.0 to 3.0 and I was given 6 months to get it done. I used an early version of this VFP application and converted all the code in a matter of days. It took me a week to get the patterns perfected for VFP to take over. Now, I have speech recognition and an interactive editor to basically talk to it in English, edit the verbal commands and watch it assemble and run the code. It took one blink of an eye to convert each JavaScript file.

So, 100,000 Procedures/Functions is not hyperbole. But it does seem insane at first look, I guess.

VFP is still king, though with a white beard!

Cheers

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Mike Lewis]

Dennis,

What you are doing sounds amazing. You have my admiration.

(And I like the remark about the white beard.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dkean4]

Mike Lewis

Thanks for the admiration, but it is done because of desperation, Mike! How many more languages/scripts do I have to learn already? My head is so full and ready to explode. I can study every day of the year and no sooner I learn one, Five more come up to replace it. Then you have to memorize all the syntax and carefully type avoiding misspelling etc... You know the insanity!

The crazy thing is that with our present day technologies man's mind is burdened with what processors can do best. Every new App ups the ante for man to expand his intellectual capacities and the programming is getting getting less and less intelligent on its own.

For me, with this engagement, VFP reverses those roles. Time for the computer to get smarter, not me. My head hurts already... and I am not getting any younger... my memory is proof of that.

I feel privileged to have you guys as helpers and friends...

Kind regards

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[TamarGranor]

As Mike said, I'm highly opposed to procedure files. In my view, they give you nothing and they cause problems. In the November 2017 issue of FoxRockX, I present a tool for taking procedure files apart and creating individual PRGs for each function. That article explains why I hate them.

Tamar

 

[dkean4]

Tamar

I'm sure that you have good reasons for hating it. The procedure files actually create a necessary boundary, for me, to outline the idea of sufficiency when I fire a command. Because these high level commands will be designed by the machine, eventually, the best way to make sure that they are safe is to impose some intuitive criteria. Sufficiency works for me very well. The SET PROCEDURE and its internal structure (Admix of functions, procedures within a Data Environment) in fact operate as a single procedure file but with manifold pathways and the DB supplies the persistence, which is imperative here. So, I really see them as single PRGs which each complete a Goal or Task 100%. You can think of them as little farms with workers, cows, sheep, a garden etc...

I considered doing it with individual PRGs, years back, but my code needs to stew some things with far more freedom. The conditional commands (DO CASE, IF, etc...) force me to create extra long routines and debugging them is hell. Accidental recursion is not that frightening for me because I am used to worrying about it. I do not remember the last time I had to fix one. In fact when I created a bunch of SET PROCs it became obvious that there are minimums and compartments for each little farm assets, functions, and decision making. They become isomorphic, taking on a universal structure which facilitates design.

Maybe I will need to rethink all this later. But I am rolling at this time and turning back is rather daunting.

Great site though. Nice UX/UI. I will look at it again.

Thanks for your heads up, Tamar.

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci