Hi all.
We have an issue where profiles are lost between versions of the software. We have different versions of the software, each with a version number at the end of the executable name (e.g. MyProg21.exe, MyProg22.exe) and we feed SiOpen the app name MyProg.
The issue with the profiles being lost and not passed between versions is solved by the addition of the new executable to the configuration file via the <ExecutableName> tag (https://www.3dconnexion.com/forum/viewt ... =19&t=9469).
Is it possible at first run of the new MyProg**.exe to add the new executable name via the SDK, or is the recommended method is for us to edit the configuration file directly?
Thanks
Add <ExecutableName> via the SDK
Moderator: Moderators
Re: Add <ExecutableName> via the SDK
Hello sparkerNM,
I do plan on adding support for wildcards in the ExecutableName, soon in fact. But it isn't there now.
You have two choices at the moment:
1) Add each ExecutableName
2) Use a default file. If you let the driver use a default file, you of course lose the ability to make any special predefines for your application. The driver will create a cfg for your app in %APPDATA%, but I'm not sure if it includes the ExecutableName. If it does, then yes, it will not work for a new exe. The new exe will start from the default again.
I do plan on adding support for wildcards in the ExecutableName, soon in fact. But it isn't there now.
You have two choices at the moment:
1) Add each ExecutableName
2) Use a default file. If you let the driver use a default file, you of course lose the ability to make any special predefines for your application. The driver will create a cfg for your app in %APPDATA%, but I'm not sure if it includes the ExecutableName. If it does, then yes, it will not work for a new exe. The new exe will start from the default again.
Re: Add <ExecutableName> via the SDK
Thanks for the quick reply.
We are currently only using the default file, our application just handles events, doesn't manage any of the properties. It is the config in %APPDATA% that we tried manually editing to add the ExecutableName and that solved the issue with the profiles being overwritten.
But we can't do this manually so I was just wondering if there was a cleaner way for us to register a new exe to an existing profile, or if we will have to write something that reads and edits the config directly ourselves (which I'd rather avoid in case you ever need to change the location/name/structure of that file)?
Just in case you know of a better solution, I'll explain our actual issue in a bit more detail:
If we open repeatedly the same version of our application (say MyApp21.exe), then if you leave the connexion properties app open, you can see it almost instantly pops-up with the settings for My-App (the name we pass to SiOpen) and previous changes are loaded fine. However, if you open a different version of MyApp, then you see briefly that the properties app states the executable name (MyApp22.exe) and changes to My-App once the application has loaded.....during this time though it seems to have thought that it was opening a new program for the first time and has loaded the default settings. The settings that were previously associated with My-App are now lost and replaced with the defaults. From this point on we can continue using MyApp22.exe perfectly fine, but as soon as we go back to MyApp21.exe, then our settings get overwritten with defaults again.
We are currently only using the default file, our application just handles events, doesn't manage any of the properties. It is the config in %APPDATA% that we tried manually editing to add the ExecutableName and that solved the issue with the profiles being overwritten.
But we can't do this manually so I was just wondering if there was a cleaner way for us to register a new exe to an existing profile, or if we will have to write something that reads and edits the config directly ourselves (which I'd rather avoid in case you ever need to change the location/name/structure of that file)?
Just in case you know of a better solution, I'll explain our actual issue in a bit more detail:
If we open repeatedly the same version of our application (say MyApp21.exe), then if you leave the connexion properties app open, you can see it almost instantly pops-up with the settings for My-App (the name we pass to SiOpen) and previous changes are loaded fine. However, if you open a different version of MyApp, then you see briefly that the properties app states the executable name (MyApp22.exe) and changes to My-App once the application has loaded.....during this time though it seems to have thought that it was opening a new program for the first time and has loaded the default settings. The settings that were previously associated with My-App are now lost and replaced with the defaults. From this point on we can continue using MyApp22.exe perfectly fine, but as soon as we go back to MyApp21.exe, then our settings get overwritten with defaults again.
Re: Add <ExecutableName> via the SDK
You are probably seeing a cfg the driver made just by seeing your executable but before you called SiOpen. You want to avoid that by providing better information. Otherwise it might be using a cfg that just does mouse and keyboard emulation, not sending 3D mouse events.
You can write your own default file into %PROGRAMDATA%/3Dconnexion/3DxWare/Cfg. This will get used instead of our default.
You can update that when you release a new version (add a new ExecutableName).
I'd have to check how particular it is about matching the ExecutableNames in each.
You can write your own default file into %PROGRAMDATA%/3Dconnexion/3DxWare/Cfg. This will get used instead of our default.
You can update that when you release a new version (add a new ExecutableName).
I'd have to check how particular it is about matching the ExecutableNames in each.
Re: Add <ExecutableName> via the SDK
Indeed, that is what we assumed, unfortunately the driver then continues to use that default config rather than re-loading the existing My-App config after SiOpen. If the user then changes their settings again (which they instantly do because everything feels wrong) then the old config is overwritten.
It appears to create a relevant default config for us but can you clarify how we provider better information?
The problem is that it is not that simple to directly edit that config file.
If we were to try and edit that config file from MyApp, then it would be too late, the driver would already have created its new default and the change to add the new ExecutableName is likely to be overwritten.
If the config already exists, then we could edit the config file during installation to avoid that problem, however if the user installs 3Dconnexion devices after MyApp installation then the config would never have existed and we are still stuck with the same issue.
To avoid that issue then we could write our own config file during installation if one doesn't exist, however this means an even stronger reliance on you never changing that file and its layout.
I'm afraid I can't see a particularly robust way to proceed.
Just to confirm, there is no API call to add a new ExecutableName and/or reload the configurations.....or solve the issue in a different manner?
It appears to create a relevant default config for us but can you clarify how we provider better information?
The problem is that it is not that simple to directly edit that config file.
If we were to try and edit that config file from MyApp, then it would be too late, the driver would already have created its new default and the change to add the new ExecutableName is likely to be overwritten.
If the config already exists, then we could edit the config file during installation to avoid that problem, however if the user installs 3Dconnexion devices after MyApp installation then the config would never have existed and we are still stuck with the same issue.
To avoid that issue then we could write our own config file during installation if one doesn't exist, however this means an even stronger reliance on you never changing that file and its layout.
I'm afraid I can't see a particularly robust way to proceed.
Just to confirm, there is no API call to add a new ExecutableName and/or reload the configurations.....or solve the issue in a different manner?
Re: Add <ExecutableName> via the SDK
The default and user cfg signatures have to match. The signature, currently, also includes the ExecutableName elements.
If your installer adds a cfg file to %PROGRAMDATA%/3Dconnexion/3DxWare/Cfg (not %PROGRAMFILES%... - you shouldn't edit PF), you can change its signature to add the new ExecutableName. But you also have to add it to the signature in the user file (%APPDATA%/3Dconnexion/3DxWare/Cfg). Do this in your installer. I use PowerShell to do this sort of editing. It has very nice XML support.
Your user probably has to bounce the driver to pick up the new signature. I suppose your installer could do that also. Just kill it. It will restart when your app starts.
I only tried this on an application that calls SiOpen before it opens its window. YMMV.
Yes, you do rely on me not changing the format of the cfg files. But if I do, I'll increase the CfgFormatVersion which will ignore your old cfg file.
I'll be implementing MyApp*.exe soon. In that case, yes, your PD file won't be necessary, and will likely cause a problem, since I will score a specific-ExeName match higher than a wildcard.
If your installer adds a cfg file to %PROGRAMDATA%/3Dconnexion/3DxWare/Cfg (not %PROGRAMFILES%... - you shouldn't edit PF), you can change its signature to add the new ExecutableName. But you also have to add it to the signature in the user file (%APPDATA%/3Dconnexion/3DxWare/Cfg). Do this in your installer. I use PowerShell to do this sort of editing. It has very nice XML support.
Your user probably has to bounce the driver to pick up the new signature. I suppose your installer could do that also. Just kill it. It will restart when your app starts.
I only tried this on an application that calls SiOpen before it opens its window. YMMV.
Yes, you do rely on me not changing the format of the cfg files. But if I do, I'll increase the CfgFormatVersion which will ignore your old cfg file.
I'll be implementing MyApp*.exe soon. In that case, yes, your PD file won't be necessary, and will likely cause a problem, since I will score a specific-ExeName match higher than a wildcard.