Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Do FunctionName.prg
Message
From
13/05/2021 13:09:33
 
 
To
13/05/2021 09:25:54
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01680170
Message ID:
01680392
Views:
47
>>Finally, even if there's no performance penalty, procedure files have other negatives, including making it hard to find stuff at design-time (which includes that they can make Thor's Find Definition fail). For me, the worst is that under some circumstances, changes in a procedure file don't show up when you're testing in the IDE. I've been bitten by that a lot.
>
>That really depends on how you organize things. If you have a large projects with hundreds of functions it does not make any sense to load them in the project manager. It makes sense to put them into a single prg library if they are used within the context of the library purpose. It makes it a lot easier to redistribute and hides away functions that are never used outside of that context. Nowadays I'd load everything into classes, but if I'd have a library that has to do with FTP, containing dozens of functions that are used from one main function within that same procedure file, I just don't want to see that stuff in the project manager.
>

I don't open the Project Manager most days. I only use it when I need to build an APP or EXE. So I don't care how many files are in a project. OTOH, I don't have any reason to want to have dozens of routines that aren't used in the project, because that will bloat the EXE. The worst procedure file I ever encountered was 3MB and had over 1600 routines in it. No way that wasn't carrying lots of extra weight.

That reminds that another negative about procedure files is that you might have two routines with the same name (in the same file or different files) and not realize it. Which one gets used depends on the order they appear, if they're in the same file, or the order in which you SET PROCEDURE, if they're in different proc files. When every routine is a PRG, that can't happen unless you keep your PRGs in multiple folders.

I actually have less of an issue with what you describe, a proc file that's more or less a class, though if there's any shared data, it should be a class. But I regularly come across applications that have large procedure files containing dozens of routines from all over the application. Basically, someone learned about procedure files before FP2, and just kept using them when they were no longer needed.

Tamar
Previous
Reply
Map
View

Click here to load this message in the networking platform