Ad blocker detected:
Our software and support is 100% free. This website is not.
You can donate in 2 ways, by turning off your ad blocker or by pressing the Donate button.
************ NOTICE ************
UPDATE YOUR BOOKMARKS!!!
We have an issue that there is no way around as of yet.
I have done all I can to try and prevent this from happening.
We are going to be losing the .com, .org and .de domains.
We have not been able to contact the original author of EventGhost
(the person that owns those domains) to redirect them to the new web server.
I set in motion when we first moved a redirection from the old server to the new server.
I also put in markers so that search engines would see this change and update any pointers
they have. We still have the .net domain for the production site. and the .rocks for the test site.
For the past few months you have been getting redirected to the .net site if you used one of the 3
domains mentioned above. I just wanted to tell everyone so they can make any changes needed.
In Windows 10, I'm not getting events from Snarl. I do get them if I set Snarl to run as administrator, but most of my Snarl extensions don't work in this mode. I'm assuming this occurs because I'm running EventGhost as administrator, but a ton of programs won't launch from EG if I run it normally. Is there a workaround?
I believe Windows 8 employs the same security model. Do you have access to Windows 8?
The best workaround I was able to come up with myself is disabling UAC entirely (via the "EnableLUA" registry hack), which works 100%, but the trade-off is that you can't run Windows Store apps with UAC disabled. Not the biggest deal in the world for me, but I'd still like to find a solution without caveats.
Then all that remains, I guess, would be to add a "Run as Administrator" checkbox to the Start Program action, thereby not requiring you to run EventGhost as Administrator in the first place. Feasible?
With the Windows security model being what it now is, there definitely needs to be a built-in way to do this. I've seen far too many threads on here where "just run EventGhost as Administrator" is the solution, and apparently that now carries too many caveats to be useful advice.
I had a look at your workaround, and needless to say, I'm deeply uncomfortable with storing my password in plain-text. If you could figure out how to reduce this to a checkbox in the Start Program action (without requiring a password), that would be a great service indeed for all EG users.
It sounds like this will allow elevated programs to run if user is an administrator, without enabling "Run as Administrator". As an added bonus, setting "uiAccess" to true will allow hotkeys to interact with elevated programs. Currently, if you try to press one of your EG keyboard macros with Task Manager focused, for example, EG doesn't receive notification that the macro was pressed.
For this to work, the executable will also need to be signed. You can obtain a free certificate from Let's Encrypt when it launches in the coming weeks. In the meantime, a self-signed certificate can be used for testing purposes.
Thank you for the detailed instructions.
I'll certainly try.
However, it has no relevance to issue a new release (yet) if each user would need to generate a self-signed certificate.
Perhaps I understood correctly.
The ShellExecuteEx change doesn't require a cert, so I recommend pushing that one out as soon as possible, but you're correct that the manifest portion doesn't warrant a release until Let's Encrypt launches and you can get a cert.
After a quick read-through of the code, I'd like to make one small suggestion: It appears as though the only thing CreateProcess can do that ShellExecuteEx can't is setting priority. I recommend stripping out CreateProcess and the useShellExecute option entirely and simply setting process priority after execution with SetPriorityClass. There's no sense in giving users the option to stick with CreateProcess if it provides no tangible benefit.
Lookin' good on this end. ShellExecuteEx appears to be the perfect solution to this long-standing issue.
It's important that useShellExecute be removed before release, as it'll screw up configs if you remove it later. If it turns out that people end up needing CreateProcess for some reason (which, based on what I've read today, seems unlikely), the option can always be re-added in the release after.
One final suggestion: Convert Windows Command to ShellExecuteEx and add a "Run as Administrator" checkbox to its options as well. Be sure to work from the version of Windows Command I posted here. If you'd like, I'd be happy to test both modified files before release.