I have a question on the use of the option ConfigDir. The most suggestions I see in the Clarion newsgroups etc. is just the plain /ConfigDir which makes that the settings directory is placed in the bin directory.
However don’t like that the settings are a sub folder in the bin directory. In stead I like the place where Clarion defaults to place the settings being %AppData%\SoftVelocity\Clarion.
I only want different sub folders for the 11.0 and 11.1 installs. As most suggest just the plan ConfigDir, is there any compelling reason not to use for example: /ConfigDir=%AppData%\SoftVelocity\Clarion\11.1
Just be aware that not all installers may support your redirection easily or equally.
As you can see in the attached screen capture, our installers allow you to specify that the install be with either /ConfigDir (and no specific folder) or with a specific path added.
Definitely do some testing with your use of it to make sure things end up where you think they will and tied to each other correctly.
You don’t want a scenario where you end up with some things being in C11 and others in C11.1.
Another place to watch out for is where example apps are installed.
Not all installers differentiate between C11 and C11.1 there either.
Thank you for pointing that out. So if the installer doesn’t offer to use the offer to use the ConfigDir path is might be better to register the template manually.
Well I am used to check for differences in my Clarion install before and after I installed a new template. So if something happens in the C11 environment while it supposed to happen only in C11.1 I will find. This is a habit of me since the < C6.3 days where some third party suppliers made a mess of where they install files.
It’s been a few years since I worked through the nuances, but I think that is probably your best path.
If you install without registering the templates during the install, then the files end up where you tell them to go (Clarion11 vs Clarion11.1 for example).
Then if you launch Clarion with the /ConfigDir option it is running against that context and whatever you register or do in that session should be stored in the right place.
It’s probably one of the least used features of our installers, but back when we took the time to build out a generic system that we could use with all of them we decided to put in the effort to support it directly for those who wanted to use it.
The days of the early Clarion version installers were challenging to say the least and I can recall more than one that put files where I did not expect them to go.
That is one good thing that came out of the move to C7+ IMHO. Pretty much all of the 3rd party vendors decided to expand the earlier standards and stick with the new ones.
Writing a custom SetupBuilder script that could detect BOTH the old and new standards and install against them was not fun
Even today when you use our custom install mode to “dump” a set of install files to a location of your choice we have to identify some of the file sets by folders using the old 3rd Party names so that developers know where to put them.
While we actively support C9 through C12 most of our code works fine with the older versions of Clarion. Our new QuickBooks wrapper or the updated vuFileTools for example were tested all the way back to Clarion 5.5.
Quite frankly I’ve never understood why 3rd party installs inside of a particular build of Clarion.
The only reason I can imagine is if there a variation for some version specific of version of clarion.
I do get that you might want to automatically register the template into a version. But if that’s the case, why not offer a list of versions to auto register
Why 3rd party installs are inside the folder structure of Clarion really depends a lot on the specific template.
Most of ours are generic enough that they work with any version of Clarion without any internal branching. All of our templates written in the last decade or so work that way.
But there are some (that we acquired from other developers) that have files that are very much tied to the version of Clarion and this can mean branching in the template logic as well as version LIB or DLL specific files.
While the LIB files are typically generated with a name that can be picked up by the template so that the right one is used, the DLLs typically carry the exact same name. Plus there is usually no difference in the DLL for version 1 of a product than version 2.
So having a version of a template installed inside the folder scope of a version of Clarion makes sense.
I can easily have version 4 of something installed with Clarion 10 and version 5 installed with Clarion 12 (despite the same filenames) without a DLL conflict.
Another issue would be making sure that the .RED files were properly setup so that Clarion would find the right files and there are cases where the 3rd party templates build on other vendor files, so the potential for a lot of dysfunction and angst troubleshooting why something doesn’t work exists in any effort to try and put them elsewhere.
Auto registering to multiple versions has a nice ring to it, but most developers probably don’t actively work in more than one or two versions. In fact the people who would benefit the most from that would probably be template developers and most of us have more important work to do.
IIRC Friedrich and I talked about an installer that could install to multiple versions of Clarion in a single pass years ago, but it would have been a lot of work with little reward and lots of risk for a niche market.
At the end of the day I’m just glad that we do have a 3rd party standard and that most vendors follow it.
Some 3rd party ships with DLLs built with Clarion so would always need to be built for the Major Version and sometimes for a specific release build. Two I know for sure are CPCS Reports and RPM.
