Alight everyone. Let me explain some of the changes.
The starting up of EG has been changed. This is going to be used by improvements/additions made to EG in the future. There was a bug in EG but it really wasn't a bug. go figure on that one. But the issue was there is a module that is included with EventGhost and it resides in the lib27/site-packages folder. and this module was loaded/used by many of modules in the eg/WinApi folder and that folder is what houses as you can probably guess most of the connection specific goodies to Windows. and what was taking place is if we wanted to use some of the code located in that folder we would have to have it set up so that whatever it is we wanted to do would have to be done more then 1/2 way through the loading of EventGhost because that is when the /lib27/site-packages folder was added into EG so the cFunctions module could be imported. If WinApi was imported before that time all kinds of errors would happen because it would try to load the cFunctions module and it wouldn't be able to locate it. and this is going to be a problem in the future. So through some work and shuffling things about we were able to make it so that the first thing EventGhost does is set into place the locations that are necessary to give us the ability to load the WinApi. and it also allowed us to move the rest of the EG locations like the plugins directory and the config directory to right before the meat and potatoes of EG starts to load.
We were able to solve a couple of smallish bugs which almost no one probably ever knew about because they were very specific use case problems. One of them being that EG was never really 100% portable. The definition of portability means that everything is contained to a specific location. and what was taking place before is that EG would always create a folder in ProgramData and not remove it. So now if you specify an alternate configuration file through the use of the -configFile command line switch EG will now set the user plugins folder to be the same as the core plugins folder and it will not create the /ProgramData/EventGhost folder anymore. this is a nice feature because if you wanted to put EG onto a USB drive and plug it into someone's computer you can run EG from the USB drive and it will not alter anything on the HDD of the computer. This make it truly portable.
There is one bump that we discovered after RC3 was released and we honestly do not know if this is a bad thing or potentially a good thing as of yet. But if you have a second instance of EventGhost as an example on your desktop and you have the folder it is in called TestEventGhost if you run it it will not use the ProgramData/EventGhost folder. instead it will create a new one called ProgramData/TestEventGhost. the folder name that is created in the ProgramData folder will always be the ame name as the folder where EG resides. so if you change the install location from c:\Program Files (x86)\EventGhost to c:\Program Files (x86)\JimmyCrackedCorn then the ProgramData folder will be \ProgramData\JimmyCrackedCorn. I let everyone know this because if you have plugins that you installed that had the .egplugin extension those in the past would have been put into the \ProgramData\EventGhost\plugins folder. so if you have a second installation of EG and the containing folder of the program is not named EventGhost it will not see these plugins. This can be a good thing if you want to have to sets of plugins one for each of the installations. so this is an up in the air thing. But please let us know which way you want to go on this. we can fix it. we simply do not know if it is a bad or a good thing because it can go either way.
but if you are looking for plugins that you installed make sure you check the ProgramData folder that has the same name as the containing folder for the instance of EventGhost you are running.
We also exposed the EventGhost API through a named pipe. this has helped us to correct COM errors that could arise when using any of the command line switches while EventGhost was running and also solved permissions problems. An example of a permissions problem would be if you have EventGhost running as administrator and you double clicked on an egplugin file to install it but you were logged in as a user. there would be an error because you are not able to run EG as an Administrator and as a User at the same time. But through the use of named pipes we are able to simply tell the EG that is running to install the plugin.
This to has created a side effect. and that side effect is if you are running EG as an administrator and then you use the -restart switch as a user the new EG that start running will be as a user and not an Administrator. This is simply solved either by using runas if you are there to key in the admin password or by starting the cmd window as an administrator. but if you are restarting EG programmatically you will need to have whatever software start a command line and pass the following to it.
Code: Select all
powershell.exe -Command '$username = "YOUR_COMPUTER_NAME\YOUR_USER_NAME";$password = "YOUR_PASSWORD";$args = "-restart";$credentials = New-Object System.Management.Automation.PSCredential '-ArgumentList @($username,(ConvertTo-SecureString -String $password -AsPlainText -Force));Start-Process "YOUR_PATH_TO_EVENTGHOST\eventghost.exe" -ArgumentList $args -Credential ($credentials);'
be sure to change the following and if there are additional command line parameters you wish to use then add them after -restart
YOUR_COMPUTER_NAME
YOUR_USER_NAME
YOUR_PATH_TO_EVENTGHOST
because of this we are going to add a -username and -password to the command line switches. this way you will be able to start EG as any user you want. This is currently under development I am trying to find a way to achieve this without the use of powershell.
But the addition of the named pipe is a large addition to eventghost the name of the pipe is
and anything that is in EG is accessible through this pipe. You are not able to set variables directly but if you create a function and that function accepts parameters then you can set the variables through the use of the function.
here is the layout of the information that you need to use. the pipe connection has to be set as a message pipe. and the information that is going to be sent needs to be a string. the message format is as follows
function/method/class, data to be passed
the message is split into 2 parts the first part is what you are trying to call. and the second part is any information you are wanting to pass. if the command does not need any data to be sent to it you can either simply pass the command or you can send the command followed by a ", ()" without the quotes
as an example if you wanted to send a command down the named pipe to show eventghost it would be
eg.document.ShowFrame, ()
because there are in parameters that need to be filled with this command you simply put ()
or if you wanted to open the add plugin dialog
eg.document.CmdAddPlugin, ()
maybe you want to check to see if EG needs to be saved. The pipe will return data if there is data to be returned so be sure you set the pipe up to receive information after sending a command even if you do not use the data sent back.
eg.document.IsDirty, ()
or if you wanted to tell a specific plugin to do something
eg.plugins.System.ChangeMasterVolumeBy, (-2.0,)
the pipe also accepts keyword arguments as well
eg.plugins.System.ChangeMasterVolumeBy, dict(value=-2.0)
or
eg.plugins.System.ChangeMasterVolumeBy, {'value': -2.0}
and to use it to set variables you would need to set up a python script that gets triggered by Main.OnInit that contains something like the following.
Code: Select all
def Some_Function(param1, param2):
eg.globals.param1 = param1
eg.globals.param2 = param2
eg.globals.some_function = Some_Function
and the pipe command
eg.globals.some_function, ('this is', 'a test')
and this will make eg.globals.param1 to be 'this is' and eg.globals.param2 to be 'a test'
through the use of the named pipe we are able to now use the -hide command line switch when eg is already running and it will minimize it. as well as the trigger event works as expected. I think there is a change to the trigger event specifically the payload data. it used to always make a list with a string in it. now it will function like it is supposed to and correctly set the payload data. so if you pass {'key': 'value'} the payload will no longer be ["{'key': 'value'}"] it will now be a python dict.
There was also an issue with the Clipboard getting broken when you exit EventGhost. We have solved this issue as well. I am unsure if this problem through the Windows Versions. but i do know it was an issue in Windows 10.
The depreciation warning when using the Broadcaster plugin is now gone.
USBUIRT plugin not being able to learn IR has been solved.
OK this is another major change. way back when in the days of Windows XP, eg.WinApi.SoundMixer was used to control anything relating to the sound on your computer. when newer OS's came about a module called VistaVolEvents was added to eventghost. but this module was added directly to the System plugin. and if Windows was newer then XP then it would use the VistaVolEvents. the issue with this is the eg.WinApi.SoundMixer basically became a dead stick. and you lost the use of the convenience functions built into it. So we have moved the use of VistaVolEvents into the eg.WinApi.SoundMixer and it has become active once again. It automatically determines the Windows version and if it should use the VistaVolEvents or not. it will do all of the nitty gritty calculations for you for setting things like the volume
There was also an issue with how EG read the information coming from windows about Power Settings this has now been fixed. this was a real bonehead mistake i made when I modified the System Plugin to produce more events based on what the power settings were and if you were on battery or not. I do apologize to the people that experienced any problems with this.
