New version here: http://rainmeter.net/forum/viewtopic.php?p=92974#p92974
Sorry for the delay! Your message scared me so bad, I left town for a week! (Just kidding, I had some family and business matters to attend to.)
Anyway, way back when I first made this plugin, we were using VS2012 and I did not compile the plugin with the correct settings. In fact, I ran into the same issue with my HotKey plugin a while back.... (I probably have other plugins that have the same problems...)
All should be fixed now, and hopefully this issue hasn't affected too many people out there.
-Brian
It is currently April 26th, 2024, 1:44 pm
RunCommand
-
- Developer
- Posts: 2684
- Joined: November 24th, 2011, 1:42 am
- Location: Utah
-
- Rainmeter Sage
- Posts: 7171
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.1
Probably not, just me Like Balotelli used to say : "Why always me?"All should be fixed now, and hopefully this issue hasn't affected too many people out there.
I'll be happy to use the fixed plugin, you did a great job with it.
Just a question (not a request or anything like that) : would be possible for your plugin to execute several instances of the same command in one "thread"? I know I'm not crystal clear (or semantically correct) here, but I'll explain : I have several WMI queries which, in normal conditions, run at the same time (e.g. several instances of <cmd.exe>/<conhost.exe>). Wouldn't be possible to "integrate" them into one - that is, having a single pair of <cmd.exe>/<conhost.exe> running all the "secondary commands" (aka the WMI queries)? I know that these are not Windows application to support all the fancy stuff, but it was just a question...
Other than that, I noticed that sometimes, one or two instances of <cmd.exe>/<conhost.exe> are "left behind" (they're not being closed properly and they're still running). This doesn't happen so often to be a "problem", but just wondering if you know why it happens in the first place.
-
- Developer
- Posts: 2684
- Joined: November 24th, 2011, 1:42 am
- Location: Utah
Re: RunCommand 1.1
You could try placing the commands in a batch file, and executing that from RunCommand.Yincognito wrote:would be possible for your plugin to execute several instances of the same command in one "thread"?
Another solution may be to use the command prompts conditional symbols.
command1 & command2 : Runs command1, then command2
command1 && command2 : Runs command1 and if successful, command2
command1 || command2 : Runs command1 and if not successful, command2
For example:
Code: Select all
[Command1]
Measure=Plugin
Plugin=RunCommand
Parameter=wmic os get lastbootuptime & wmic path win32_utctime get month, day, year, hour, minute, second, dayofweek, quarter, weekinmonth
Hmmmm, this really shouldn't happen unless the command being run expects input of some kind, or has hung on its own. I would suspect the later. You could always force kill command after a number of seconds to catch any hung programs, but be careful to leave enough time for the program to finish.Yincognito wrote:I noticed that sometimes, one or two instances of <cmd.exe>/<conhost.exe> are "left behind"
-Brian
-
- Rainmeter Sage
- Posts: 7171
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.1
Yeah, I knew that, but it's not suitable for me, as I don't want to use additional files. It is nevertheless, a good option.You could try placing the commands in a batch file, and executing that from RunCommand.
WOW! I never thought this could be done! Brian, you're a treasure - thank you, that's exactly what I needed!Another solution may be to use the command prompts conditional symbols.
Yes, I also believe it's the latter. I tried killing the possibly "alive" commands with various degrees of success, but just after the [!CommandMeasure "Run"] - now I know what I was doing wrong : I should have put a counter, so that it would delay the "killing spree"I would suspect the later. You could always force kill command after a number of seconds to catch any hung programs, but be careful to leave enough time for the program to finish.
-
- Posts: 1740
- Joined: November 13th, 2012, 9:53 pm
Re: RunCommand 1.1
Brian wrote:
All should be fixed now, and hopefully this issue hasn't affected too many people out there.
it will affect them again as soon as the download one of my skins that come with the old version. :/
during install of a skin there is no way to tell whether a plugin that comes with the skin is older or newer than the currently installed one.
i'll update my skins but that will take a while.
-
- Developer
- Posts: 22630
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: RunCommand 1.1
One thing a user can do, but it's not going to be something intuitive to anyone, and would be something you would just have to tell them to do is:moshi wrote:
it will affect them again as soon as the download one of my skins that come with the old version. :/
during install of a skin there is no way to tell whether a plugin that comes with the skin is older or newer than the currently installed one.
i'll update my skins but that will take a while.
Copy a "new" version of the RunCommand.dll file from %APPDATA%\Rainmeter\Plugins and put it in Program Files\Rainmeter\Plugins.
Rainmeter will "prefer" a copy of a plugin .dll that is in Program Files over one in %APPDATA%, in effect prefer a "built-in" plugin over a "3rd-party" plugin of the same name.
Since all .rmskins will install any copy of the .dll they contain to %APPDATA%, they can then avoid overwriting a new one with an old one, without having to be super-careful when they install skins to watch for and uncheck the "replace" box during the install.
The good thing here is that I really believe that a very small percentage of folks are going to have any problem with the old version. The vast majority of people are already going to have VS2012 on their systems, either from other software, or from an older version of Rainmeter itself.
The bad thing is that until and unless we get RunCommand into the Rainmeter "build", so it is distributed with Rainmeter, this can and will crop off from time to time when older skins are installed.
I am very uneasy about this. Not so much about RunCommand in particular, but the entire issue as it relates to 3rd-party plugins. This is very poorly thought through right now, mostly due to the fact that for a long time, there just were no 3rd-party plugins to speak of. However it seems to be taking off a bit, and this "version" issue is going to bite us in the butt, sooner as likely as later.
-
- Developer
- Posts: 2684
- Joined: November 24th, 2011, 1:42 am
- Location: Utah
Re: RunCommand 1.1
That is true, only if they do not have the 2012 C++ redistributable. It might be a good idea to make a note on customize.org/deviantart if anyone complains about it. You can point them to my first in this thread if needed.moshi wrote:it will affect them again as soon as the download one of my skins that come with the old version. :/
I think this is problem that we should try to solve at some point. At least a warning to the user that there may be problems when installing an older version of a plugin over a newer version. Not sure if we should *force* the failure of installing a older plugin since there may instances when the older plugin works better. Anyway, it is just a thought at this time.moshi wrote:during install of a skin there is no way to tell whether a plugin that comes with the skin is older or newer than the currently installed one.
-Brian
-
- Rainmeter Sage
- Posts: 7171
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.1
^^^Yes, I think this would be a better solution than the "note" variant.
Although ... this would require users to update the plugin, which means old versions of the plugin would have similar issues in the same conditions. And since skins all over the internet are "shipped" with the plugins at the time of skin building, it would also require the skins to be "updated" as well.
I told you this might happen The thing is...either way you put it, there is some sort of "disadvantage":
a) if you hadn't built a VS2013 version of the plugin, users would have had problems on a 100% "clean" system, like the one in a VM or a perfectly fresh install (the thing I experienced).
b) after building the VS2013 version of the plugin, the skin developers would have to update their skins or write a note/warning regarding VC++ runtime somewhere (the thing moshi is experiencing).
Of course, this would happen in some relatively isolated cases, but there's no way to avoid either a) or b), at least for the moment. In my case, I didn't delete the note I wrote before you released the new 1.1 version, although I upgraded the plugin. Just in case.
-
- Posts: 1740
- Joined: November 13th, 2012, 9:53 pm
Re: RunCommand 1.1
those are going to be deleted the next time one runs a Rainmeter install.jsmorley wrote:
One thing a user can do, but it's not going to be something intuitive to anyone, and would be something you would just have to tell them to do is:
Copy a "new" version of the RunCommand.dll file from %APPDATA%\Rainmeter\Plugins and put it in Program Files\Rainmeter\Plugins.
Rainmeter will "prefer" a copy of a plugin .dll that is in Program Files over one in %APPDATA%, in effect prefer a "built-in" plugin over a "3rd-party" plugin of the same name.
-
- Developer
- Posts: 22630
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: RunCommand 1.1
Ah, yeah, you are right. I didn't pay attention to the fact that the install first deletes the entire Plugin folder, rather than just replacing old files with new ones.moshi wrote: those are going to be deleted the next time one runs a Rainmeter install.
Oh well...
We simply MUST fix this "version" issue with 3rd-party plugins.