It is currently March 28th, 2024, 10:28 pm

RunCommand

Share and get help with Plugins and Addons
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: RunCommand 1.1

Post by Brian »

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.... :oops: (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
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: RunCommand 1.1

Post by Yincognito »

All should be fixed now, and hopefully this issue hasn't affected too many people out there.
Probably not, just me :D Like Balotelli used to say : "Why always me?" :confused:
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.
If my message scared you so bad that you left town for a week, then maybe if someday we meet in person, you would leave the galaxy or something - that way humankind we could finally have some interstellar travelling 8-)
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: RunCommand 1.1

Post by Brian »

Yincognito wrote:would be possible for your plugin to execute several instances of the same command in one "thread"?
You could try placing the commands in a batch file, and executing that from RunCommand.

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
Note: You may need to be careful if the different commands output have different encodings.


Yincognito wrote:I noticed that sometimes, one or two instances of <cmd.exe>/<conhost.exe> are "left behind"
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.

-Brian
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: RunCommand 1.1

Post by Yincognito »

You could try placing the commands in a batch file, and executing that from RunCommand.
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.
Another solution may be to use the command prompts conditional symbols.
WOW! I never thought this could be done! Brian, you're a treasure - thank you, that's exactly what I needed!
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.
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" ;-)
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: RunCommand 1.1

Post by moshi »

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.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: RunCommand 1.1

Post by jsmorley »

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.
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.

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.
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: RunCommand 1.1

Post by Brian »

moshi wrote:it will affect them again as soon as the download one of my skins that come with the old version. :/
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: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 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.

-Brian
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: RunCommand 1.1

Post by Yincognito »

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.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
moshi
Posts: 1740
Joined: November 13th, 2012, 9:53 pm

Re: RunCommand 1.1

Post by moshi »

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.
those are going to be deleted the next time one runs a Rainmeter install.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: RunCommand 1.1

Post by jsmorley »

moshi wrote: those are going to be deleted the next time one runs a Rainmeter install.
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.

Oh well...

We simply MUST fix this "version" issue with 3rd-party plugins.