Ah, that's probably my fault. Newer OSs are quite picky about where programs may write to. In your case you've installed madCollection into the Program Files directory, which is just fine. But madExcept is not really allowed to write into that directory, so the plugin directory is not writable. As a result the OS redirects the write attemps to your Users folder. Which makes sense, but which means that things get screwed up and don't properly work, unfortunately.

I'll put this on my to do list to investigate/change. Probably I need to move the plugin folder to the Users folder somehow. Unfortunately that means the files get scattered all over your harddisk which I really hate. But that's the way Microsoft wants to have it, apparently...

As a temporary workaround, I suppose you could cleanup the Users folder and then add write access to the Plugin folder to your user (or even "Everyone"). Once madExcept is allowed to write to the Plugins folder, everything will (hopefully) start to work as expected.

Hm, i have this "problem" also. Folder where I install all my components is not in Program Files, but in ex. C:\Embarcadero_components\. I have some other version of Delphi installed and tested but only for Seattle it says "failed".

madshi wrote:Ah, that's probably my fault. Newer OSs are quite picky about where programs may write to. In your case you've installed madCollection into the Program Files directory, which is just fine. But madExcept is not really allowed to write into that directory, so the plugin directory is not writable. As a result the OS redirects the write attemps to your Users folder. Which makes sense, but which means that things get screwed up and don't properly work, unfortunately.

Yes, applications are not allowed to write into the "C:\Program Files (x86)\" folder, but this is since Windows Vista. Quit some time ago.

madshi wrote:I'll put this on my to do list to investigate/change. Probably I need to move the plugin folder to the Users folder somehow. Unfortunately that means the files get scattered all over your harddisk which I really hate. But that's the way Microsoft wants to have it, apparently...

That would be fine, if you can fix it. And yes, I agree, things get scattered around. But on the other side, user files shouldn't have ever stored in the "C:\Program Files (x86)\" folder anyway. But until Windows XP it was possible and easy to do, and we also used that folder to store user data in our software. But when we first used our software with CITRIX things went very ugly. And beginning with Vista we had to redesign some parts of our software to make sure no user file will ever end up in "C:\Program Files (x86)\". That's life.

madshi wrote:As a temporary workaround, I suppose you could cleanup the Users folder and then add write access to the Plugin folder to your user (or even "Everyone"). Once madExcept is allowed to write to the Plugins folder, everything will (hopefully) start to work as expected.

I tried that, and I still get the same error messages after double clicking the .mep files. But they are stored in the "C:\Program Files (x86)\madCollection\Plugins\win32" and "C:\Program Files (x86)\madCollection\Plugins\win64" now and there are no files under "C:\Users\[User]\AppData\Local\VirtualStore" anymore. When I force an exception in our applications I don't see any difference in the error report. Once again the question, where do I see the impact of the installed .mep files? Should I see some difference in the "madExcept 4.0.16 settings" dialog in the Delphi IDE?

madshi wrote:...You still need to "check" the plugin there to enable it for your project, and then recompile. It works for me, but I do have madExcept installed in a folder where the user has write access to.

I think as a developer you should not expect that a user installs a software in a folder where the user has write access to, after the installation. This is not the default behaviour in Windows. In my opinion you should change the way files are stored. User files should go to "CSIDL_APPDATA\[Application]" or "CSIDL_PERSONAL[Application]". This would solve the problem.