When using Multi DLLs in an application, do I need to complete the Global Properties in all modules, or only the Data DLL?
I think I understand following the responses from RchdR & Carl Barnes. I am using ABC.
I guess I was hoping for an answer I was not going to get, that every thing would be in the Data DLL/App, but I do understand that that was wishful thinking. I do have a number of 3rd party templates which I have found since asking, that need to be in both the Data app and any app using them.
This is all a big learning experience, and I thank you both for taking the time to respond to me.
How is your app broken up into DLL’s at the moment?
Edit.
If you want to discover this for yourself, I would suggest firing up the debugger, set a break point on the EXE start if the debugger is not already set to halt on entry, and step through. You will be able to see the code that gets called from the different DLL’s in the debugger.
Some of the Program.exe global embeds get called, then data.dll global embeds, and then AppSection.dll when called from the Program.exe main menu.
You asked “in all Modules” but I think you mean “in all APPs” as Modules are individual CLWs.
Yes, every DLL /App stands alone and needs it’s Global Properties set up.
But just for what Templates, 3rd Party, or Classes that APP uses. E.g. if all Reports are in one App then only that App would need CPCS or RPM setup (if you use those tools).
A related question is what Global Properties (Templates, 3rd Party, or Classes) do you setup in the Data DLL App… It’s typical to setup Everything in the Data DLL and as Exported. In all other APPs (that use the thing) you set it up as External.
E.g. if you use jFiles JSON in a few Apps you set it up on the Data App as Exported and the only the Apps to hst use it as External.
When I have a serious project with many Apps I often create an App Extension Template for just that project and add it to all Apps. That let’s me do some things across all Apps with a template change and recompile.
A screen capture of what you are talking about would help.
If you think about it for a bit, you’ll see this is not really possible.
An APP is a self contained unit, with global template settings and then local procedures etc.
Local templates use global template settings (a lot). But theres no scope for the local procedures in one app to read (the template values in) another app.
If there was some imaginary “template settings include file” that would then lead to the problrm that different “kinds” of apps contain different values for settings. So one app has “export classes” ticked on, the others off. One might Generate All File Declarations. Most won’t.
And any app could export say classes and hence presumably templates.) How would one app know which settings to import?
Sure some suitably complex and complicated system could be figured out. But it would be much harder to get right than the existing approach.
(We’re talking about template settings here, runtime code already has multiple ways of sharing settings between apps at runtime.)
Yes. You need to tell every app that it is a dll and that some procedures and data are defined elsewhere.
e.g. The data dll holds the code and data for the files and some other stuff.
The dll’s that use those files and stuff need to be told that those things are actually somewhere else, and where they are.
Once you’ve done it once you’ll realise it’s actually pretty easy
