Author Topic: Separate new SLICKEDITCONFIG_BETA environment variable for Beta products?  (Read 936 times)

mjdl

  • Senior Community Member
  • Posts: 141
  • Hero Points: 16
  • SE 23.0.2 hotfix 2 x64 Windows 10 v1903
Just an idea: I normally set the SLICKEDITCONFIG environment variable (on Windows 7 x64) to point to my choice of a config directory, in which I then manually set up folders via backup & autosave file options dialog. If circumstances dictate another temporary config folder, the command-line option or explicitly setting the environment variable to another value in a command-line console does the trick.

For those of use who'd like to try the Beta products, but keep them entirely separate to the usage of the current released version, I'm wondering how difficult it would be to make the Beta products select the value (if set) of a new environment variable SLICKEDITCONFIG_BETA rather than the usual SLICKEDITCONFIG? These two config folders would be entirely separate, i.e. config upgrades between versions would not copy any data between them, so the internal invocation Slickedit logic would not change after the point at which the config folder value has been determined.

Tim Kemp

  • Senior Community Member
  • Posts: 536
  • Hero Points: 90
How about just launching SlickEdit with a batch file? That way you can set SLICKEDITCONFIG wherever you want and select the version of SlickEdit too. You can have a beta batch file and a released batch file.

mjdl

  • Senior Community Member
  • Posts: 141
  • Hero Points: 16
  • SE 23.0.2 hotfix 2 x64 Windows 10 v1903
Well, of course that's the simple and obvious solution and one which I use! But my problem is that I've managed too often to launch the Slick beta executable from the command-line without the prophylactic batch file protection, thus making all kinds of unwanted changes to whatever config folder is currently valid.

But on second thought: if I install the beta without letting it alter the system PATH value *and* set up the vs-beta batch file to set both the Slick beta config folder and prepend the Slick beta executable folder to the PATH, then I'm not likely to make the mistake.

O.K., thanks for making me think a bit further on this...

jporkkahtc

  • Senior Community Member
  • Posts: 1851
  • Hero Points: 179
  • Text
I like this, but a slight variation.
Keep SLICKEDITCONFIG as is.
Add
    SLICKEDITCONFIG_V21
    SLICKEDITCONFIG_V21_0_0_3
The idea is that Slick would look for the most version specific instance
    SLICKEDITCONFIG_V21_0_0_3
then start backing off
    SLICKEDITCONFIG_V21_0_0
    SLICKEDITCONFIG_V21_0
    SLICKEDITCONFIG_V21
    SLICKEDITCONFIG
one piece at a time until it finds a match.

This would let you have a different config for each version if you like.

The downside is that you might get surprised when you have
    SLICKEDITCONFIG_V21_0_0_3
defined, but install an update, which is looking for
    SLICKEDITCONFIG_V21_0_0_4
and doesn't find it, but instead finds
    SLICKEDITCONFIG

Maybe, limit it to just major version numbers?