Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DoubtingThomas]

Because I'll be running MC19 and MC20 for a while... and because I have so many girder commands and batch files and icons set up to use MCxx.exe commands...

I thought I'd try renaming it to MCXX.exe and then change all my girder commands and batch files and icons to call MCXX.exe.  Then could simply copy MC19.exe or MC20.exe to MCxx.exe and all my programs would work no matter what version of MC I was using...

Doesn't work.  Unless the command is named MC20.exe it will not control MediaCenter20.

I'm guessing that the MC20.exe command is actually checking the program file name for the 20 to know what version of MediaCenter to communicate with.

Does anyone have any other idea how to make this work? ??

[Matt]

How about a batch file that takes a launcher path as a variable?  That way all your code stays the same and only the batch file at the front changes depending on the version.

[DoubtingThomas]

How about a batch file that takes a launcher path as a variable?  That way all your code stays the same and only the batch file at the front changes depending on the version.

Not sure I understand.

I suppose I could write a batch file that has internal variable with the version 19 or 20 and then takes command line args and passes them on to the resolved MCxx.exe name.

Is that what you are suggesting?

Of course then a DOS window pops up with each call to the batch file, but I know of ways to suppress that.

[Matt]

I suppose I could write a batch file that has internal variable with the version 19 or 20 and then takes command line args and passes them on to the resolved MCxx.exe name.

Is that what you are suggesting?

Yes.

[DoubtingThomas]

Yes.

Thanks for the idea, implementing it now... it will take work, but once done it will work for MC21++ too.

I tried symbolic links too, didn't work.

[glynor]

Recommendation:

Do it in VBScript instead and use COM.  You can then have it always launch the currently registered MC, and not have to call mc##.exe at all, you won't need to specify the version on the command line, and you won't have to change anything at all when MC21 comes along.

I've meant to do this for quite some time to fix up my Girder setup, which is the main thing that keeps me lagging on old versions of MC for a while (lazy).

Plus, WSF scripts don't show any UI, including the black command window (even minimized).

[DoubtingThomas]

Recommendation:

Do it in VBScript instead and use COM.  You can then have it always launch the currently registered MC, and not have to call mc##.exe at all, you won't need to specify the version on the command line, and you won't have to change anything at all when MC21 comes along.

I've meant to do this for quite some time to fix up my Girder setup, which is the main thing that keeps me lagging on old versions of MC for a while (lazy).

Plus, WSF scripts don't show any UI, including the black command window (even minimized).

Well then I'd have to learn VBScript and COM.  I spent my career programming on UNIX boxes doing mostly back end data processing in C, C++ and later Java.  I had to do some Web development, I hated it, it was all spaghetti code to me.  And LOL... you haven't done it yet either !!!!

[glynor]

I thought of a cool way to do it.  There will be more in a little bit, if I feel motivated this weekend.

[DoubtingThomas]

DOS batch files SUCK.   It automatically changes commas to spaces in command line args.

[AUser]

DOS batch files SUCK.   It automatically changes commas to spaces in command line args.

Either you're doing something wrong or you've found a problem that nobody else has - commas work fine
Unless explorer isn't quoting a filename for instance, tbh the easiest way to get explorer to quote everything is to have a space in the filename or path

Quotes and %~1 (to unquote) are your friends with parameters
Exclamation points (in FOR expansion) and the ampersand character can be tricky though

[DoubtingThomas]

Either you're doing something wrong or you've found a problem that nobody else has - commas work fine
Unless explorer isn't quoting a filename for instance, tbh the easiest way to get explorer to quote everything is to have a space in the filename or path

Quotes and %~1 (to unquote) are your friends with parameters
Exclamation points (in FOR expansion) and the ampersand character can be tricky though

Write a quick DOS batch file and pass A,B as an arg, then see what you have.  You would expect %1 to be A,B.

but no... %1 is A and %2 is B.

If you pass it quoted "A,B" then %1 is A,B

[AUser]

Actually I would expect %1=a and %2=b as that's the documented behaviour (also for semicolons as well as commas)
Sucks, but that's the rules
Quote your params and unquote when needed

[glynor]

Write a quick DOS batch file and pass A,B as an arg, then see what you have.  You would expect %1 to be A,B.

but no... %1 is A and %2 is B.

If you pass it quoted "A,B" then %1 is A,B

Yes, that behavior is exactly as expected. Your expectations are incorrect.

[DoubtingThomas]

Passing a command to a dos batch file like this does not work

MCXX.bat /mcc 12345,6

this does

MCXX.bat /mcc "12345,6"

but when I try to call that batch file from a C++ program using system() it doesn't work for unknown reasons.

So I gave up and wrote a C++ wrapper pgm for MCxx.exe which gets the version number from a config file to know what MCxx.exe to call.  I might have it take a look at the process list to determine which MCxx.exe to call instead of using the config file.

[BryanC]

Can't you just make a

Code: [Select]

MC20.exe /mcc $1 MCXX.bat file and call it using MCXX.bat "command"?

[glynor]

wrote a C++ wrapper pgm for MCxx.exe which gets the version number from a config file to know what MCxx.exe to call.  I might have it take a look at the process list to determine which MCxx.exe to call instead of using the config file.

That was basically my plan, only to look up the current version by connecting to MC via COM when needed.

[DoubtingThomas]

That was basically my plan, only to look up the current version by connecting to MC via COM when needed.

I don't even have a windows compiler... I use cygwin and the "unix" C++ compiler.

I really miss my MSDN account from when I was working.

Gylnor, you know, if your result would be an exe file, you might want to share it with the group.  You and I can't be the only ones that would like it.

My pgm is interlinked into the code for my home automation system, so wouldn't be good as a stand alone pgm.

[glynor]

Done, and included in MCUtilities.  Grab it and let me know how it works out for you.  I'm redoing my scripts all to point to MCcl.exe instead right now.

[glynor]

I just finished redoing all of my scripts to work with MC20, now using MCcl.exe instead of the MC20.exe launcher directly.  It works perfectly.  All of them work exactly as they did, but now to update from MC19 to MC20, I just launch the one I want, approve the UAC prompt that comes up (if I've switched versions), and then do:

Code: [Select]

MCcl --update
I can't tell any performance impact from my systems due to this new "pointer" application.  I suppose, if you are using it for things you might run over and over in very quick succession, it might make a difference.  I should note, though...

If you're doing this, for things like Volume Control and other keypresses that might happen rapidly.... Don't, especially if you're using Girder.  Sending Windows Messages instead performs much better.

Windows Messages are easy to set up in Girder with the SendMessage Action (under Windows):



Use the following Settings:
* Message: 33768
* wParam: The MCC command you want to execute.
* lParam: The optional parameter for the MCC command, if any.

Use SendMessage instead of PostMessage: Enabled (on my system anyway)

Then, click the target button and use:

Match Invisible Tasks: Enabled
Substring Matching: Enabled

ClassName: MJFRAME
Executable: MEDIA CENTER

By the way, you can also enable the Child Class option for certain commands, and filter for Theater View, Display View, and other modes with that, in order to have a command do one thing when in Standard View, and a different thing in Display View.

[DoubtingThomas]

Thanks.

An problem with using Windows message as I see in your example is that it's tied to a MC version.

I don't use volume control with Media Center, I let my audio preamp do it.  So no problem for me.

[glynor]

An problem with using Windows message as I see in your example is that it's tied to a MC version.

Nope.  That's part-of the beauty.  It works as long as you target the right application.

In Girder, this is easy.  That's why I put:

Then, click the target button and use:

Match Invisible Tasks: Enabled
Substring Matching: Enabled

ClassName: MJFRAME
Executable: MEDIA CENTER

Note, in Executable, I said "Media Center" not "Media Center 20.exe".  With that, and Substring Matching enabled, it works right through versions, because "Media Center 20.exe" and "Media Center 19.exe" both match "Media Center*".  Internally, girder just searches active processes, selects the proper one using whatever search you've provided, and then gets the hWND address, which is what is used to actually do the SendMessage.

But, Windows Messages can only do so much.  They can call MCC commands easily enough.  But you can't do the regular Command Line switches you can use through MC20.exe or whatever.  And, if you're going to script it not through something like Girder with native SendMessage support, then it is no good, and you'd be better off just using MC20.exe or whatever (because you'll need to look up the hWND address yourself, which is nightmarish, and still have the overhead of launching a new process to do the SendMessage).

So... In essentially all cases except using Girder (or something like it) to send MCC commands, then MCcl.exe is a great solution.

[DoubtingThomas]

Nope.  That's part-of the beauty.  It works as long as you target the right application.

In Girder, this is easy.  That's why I put:

Note, in Executable, I said "Media Center" not "Media Center 20.exe".  With that, and Substring Matching enabled, it works right through versions, because "Media Center 20.exe" and "Media Center 19.exe" both match "Media Center*".  Internally, girder just searches active processes, selects the proper one using whatever search you've provided, and then gets the hWND address, which is what is used to actually do the SendMessage.

But, Windows Messages can only do so much.  They can call MCC commands easily enough.  But you can't do the regular Command Line switches you can use through MC20.exe or whatever.  And, if you're going to script it not through something like Girder with native SendMessage support, then it is no good, and you'd be better off just using MC20.exe or whatever (because you'll need to look up the hWND address yourself, which is nightmarish, and still have the overhead of launching a new process to do the SendMessage).

So... In essentially all cases except using Girder (or something like it) to send MCC commands, then MCcl.exe is a great solution.

Nice, I never knew Girder could do that.  My version of Girder is still the way old free version, but it looks like it has the dialogs to do that too.

[DoubtingThomas]

MCPlayIfNotPlaying.exe

LOL... I've written the same thing...