Pages: 1
Print
Author Topic: XMetaL Macros and UAC  (Read 2545 times)
ada
Member

Posts: 22


« on: February 16, 2015, 12:28:43 PM »

Hello,

We are currently running XMetaL 6.0, soon to be 9.0. Our company is running Windows 7 for end users. With Windows 7 comes the added security of User Access Control that prevent many programs from being executed without elevated permissions. When we were on Windows XP long ago. For example, if I had to update the users xmetal60.ini file. I would use the On_application_close to fire off a .bat or cmd script that would copy the updated .ini file from a network drives to the users local drive. This made updating files to each users directory easy. However, with User Access Control implemented, one can't run these scripts automatically without elevated permissions so I can no longer do this. Has anyone else run into this problem and if so what is the recommended way to resolve this issue?

Thanks.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2580



WWW
« Reply #1 on: February 16, 2015, 02:38:00 PM »

The work to make the XMetaL Author "UAC-savvy" was started with 6.0 SP1 and completed by the release of version 7 (the time that Windows XP SP2 / Vista began to enforce Microsoft's rules about locking down the C:\Program Files directories to anything but an installer).

Configuration files (such as xmetal90.ini) are now written to and read from this folder, which is read/write for the current user's account:
%appdata%\SoftQuad\XMetaL\

I'm not sure about the timing of On_Application_Close for deploying an INI file. I suspect that if it was working in your old instances it might continue to work with the new version, but since the INI file is written out when XMetaL Author is shutting down there likely will be some conflict there. To get that to work I think you might need to try to launch the .bat file and include some kind of delay in there so that your copy is performed after XMetaL Author finishes shutting down.

What kind of settings are you putting into the INI file that require them to be updated frequently? There may be a better solution to what your scripts are doing.
« Last Edit: February 16, 2015, 02:52:01 PM by Derek Read » Logged
ada
Member

Posts: 22


« Reply #2 on: March 04, 2015, 05:39:27 PM »

Hello Derek,

I am aware that XMetaL looks at the %appdata% folder to check for configurations files first and I have had no problems copying files to that location. I actually have stopped using the on_application_close but rather started using the on_application_open to call a bat file to run sliently when the users opens the application. This will get most of the configuration files including the .ini file to work well. However, I have a few custom .DLL files that we have created which add some functionality for our users to XMetaL. The DLL files currently only work when they are copied into the C:\Program Files (x86)\XMetaL 6.0\Author. I have not been able to get them to work in the %appdata% folder. Any recommandations on being able to get those DLL files into the C:\Program Files (x86)\XMetaL 6.0\Author directory without problems with UAC?

Thanks,
Ahmed
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2580



WWW
« Reply #3 on: March 04, 2015, 06:39:15 PM »

In this case it really sounds like you should be creating an installer.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2580



WWW
« Reply #4 on: March 04, 2015, 06:50:26 PM »

This information may be useful: https://msdn.microsoft.com/en-us/library/aa372468%28v=vs.85%29.aspx
It mentions Vista, but it really is applicable to UAC in general I think.

If you create a proper installer your it should be possible to allow limited users to run it using "elevated priveleges" (as above). An added benefit is that you can also run your uninstaller to undo what your installer changed. This will allow XMetaL Author's uninstaller to run cleanly (remove everything it installed). If your installer changes any files our software installs (files that it "owns") your installer should back up our file first (giving it a new file extension is easiest) then add your own copy. Your uninstaller can then delete your file and restore the backup copy by restoring the file extension. Your uninstaller should also remove any files or folders your installer created. If anything is left behind or altered (which is common with manual changes to the system) then the XMetaL Author uninstaller will leave those files and folders in place.
« Last Edit: March 04, 2015, 06:53:43 PM by Derek Read » Logged
Pages: 1
Print
Jump to: