Based on the documentation, I added some code to catch the window event and update environment variables. Since the notification is based on window messaging, it will only work in MDI mode, where the main window is a constant.
Thanks for the effort
It just so happens that we are about to deploy our first SDI version and step away from MDI
Does this new plugin version cause problems when deployed with SDI or does notification just not work?
I did put checks to see if the runtime is MDI or not, but to be honest, I did not test at all.
Technically the feature could be extended to SDI, you just need to designate a window to receive the system notification.
I will test it tomorrow
So if I would have a window that is always there, and I could give it as parameter, the process that owns the window could get the refreshed environment variable? I could then store it as shared object or so, to use it in other processes?
Right now I am not sure how to make it work, but I don’t thing shared objects or 4D processes play a part. The plugin must get a handle of a window created by 4D, catch the event, then throw it back to the WindowProc used by 4D. It must also remove itself when the window is closed.
The new version still works in my 4D engined SDI application
What I still don’t get, but maybe you do (but no worries if you don’t) :
Every time I want the value of the environment variable I call _wgetenv via your plugin
One would say that it than gets the actual value, but for some reason it is getting the value of a “copy environment” (based on Windows documentation for _wgetenv).
Until now the only way to get the new version is to quit 4D, and start it up again
In some tests executed by my colleague it seems that also a restart with OPEN DATA FILE(Data file) does not suffice
As I understand correctly one has to implement some kind of catching window events and update the variables. I think this is strange, but I am no expert in Windows OS.
For now, thank you very much for your help ,
The system and user environment variables are stored in the registry. When you edit them from Control Panel > Advanced system settings > Environment Variables, you effectively edit the registry.
When you launch 4D.exe, the environment is copied to a global variable called _wenviron. The plugin or _wgetenv_s reads and writes this global variable, not the registry.
The code I added yesterday installs an “event handler” on the MDI window, in order to be notified each time an app changes the environment variables stored in the registry. It looks up the registry and calls _wputenv to update the 4D copy of _wenviron. So now, if you launch 4D, edit the values in Control Panel, you will now get updated values. You do not need to quit and relaunch 4D.
_wenviron is created and passed, along with command-line arguments and the application full path, when you actually launch 4D. OPEN DATA FILE does not quit the application, so _wenviron remains the same.
The problem with SDI mode is that there is no permanent window like in MDI mode. So the plugin needs to uninstall/reinstall the event handler for whatever window that is available for the job. _wenviron itself is global variable for the 4D.exe process, so there is no need for inter-process communication or even inter-window communication.
Unless the developer could set a hidden permanent window, maybe in a “silent” process?
An SDI application should automatically quit when there are no running dialog windows left. A hidden windows would prevent that. The app may disappear from the task bar, but keep running in the background; surely you wouldn’t want that.
Something like a “register this window” command would be better. If you are really interested in a solution and promise to give feedback, I can write a function.
I am interested, and promise to give feedback
Only, the tests on Citrix, where our problem is, are done by my colleague, so I don’t know how long it takes to get this feedback
Also, I need to think about how and where I put this function