Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Parent class inside exe, subclass in subfolder
Message
From
22/10/2018 06:26:10
 
 
To
22/10/2018 05:27:06
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2008 R2
Database:
MS SQL Server
Miscellaneous
Thread ID:
01662676
Message ID:
01662710
Views:
49
>>Hi Dragan, check using:
>>
>>SET CLASSLIB TO ClassLibraryName [IN APPFileName | EXEFileName] [ADDITIVE] [ALIAS AliasName]
>
>Just to report that this would probably have helped (even though I would have to have a long list of classes declared like that) if the trick I tried didn't work.
>
>And the trick was to have that one scx back into the project. Fox seems to find classes to createobject() etc among the already opened classes, but those in a .scx must be in the path as stored in the classloc field. Now I don't really like having this form inside the exe, as it needs to be distributed with the rest of the stuff in the folder and not with the main exe, so I'll probably just save it as class and instantiate it from it, i.e. kill the scx altogether.
>
>This was an exhausting exercise, because I had to keep checking that it works standalone, so it was build exe, quit, rename the source folder, run, rename back, fix, build...

Dragan, my explanation explains what I went through regarding common classlibs and might not be exactly the same as your situation, but I think the common point might be that the first time you instantiate a VFP classlib is that becomes the 'classlib of record' that all other instantiations use statically.

That's right. Have the common classes instantiated in the main EXE or somewhere early in the calling order and they become the class of record to be used by all the calling projects/apps that are called below the EXE. As far as the classloc field goes I believe (I no longer have the code to look at) each project, including the Main EXE, had the same folder structure (PRG, Forms, Libs, etc.)

In my situation before we re-factored, we had one EXE and many project/APP files that were called by the EXE. Each APP file had included an unknown version of the common classlibs, but that can cause a problem is when you build each APP and deploy them that they might have a slightly different version of the common classlibs. We would fix and deploy APP files as needed. But, then again comes the problem of first instantiation where which ever common classlib gets loaded into memory first is the static classlib of record for all the other project/apps to use.

So, we re-factored to instantiate the common classlibs in the main EXE into either public or private variables that were persisted for the duration of code execution. We didn't need to include any forms in our Main EXE. We also had a Set Classlib to in the main EXE. So, now the static classlib of record is under control of the Main EXE. When changes were made in the common classlibs we would have to Get Latest from Source Control and rebuild the Main EXE and deploy that. We no longer had to get latest from Source Control and rebuild each project app of which there were over 100. Although, I did write some SourceSafe OLE Automation to get latest and build app for each project/app.

One note to add is that we were not able to exclude the common classlibs from each separate Project/APP because then when you worked on the particular Project/APP in the VFP IDE critical classlib PEMs would not be able to be found. So, for each project the app file did bake in a version of the common classlibs as bloat code or the app file would not build. But, when the code in the APP would instantiate a common class it would magically find the first one that was instantiated in the main EXE.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform