Print

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

[glynor]

So, here's the deal:  My wrapper class for MC knows how to connect to a running instance of MC if it is running, and how to launch it if it isn't.  It also keeps track of this, so that if it was the one that opened MC, it re-closes it when it is done, but leaves it open if it was already there when we started.

That's all fine and good.  I always leave the Library Server running, in any case, so it works fairly well.

The problem is this:

My "check" to see if MC is currently running doesn't tell me if it was running in the Foreground (or, at least, in a visible window of some kind) or if it was just in Library Server mode down in the tray.  This isn't a big deal if you never mess with the running MC window or tell it to "restore" from the tray (to display something or whatever), but if you do, it would be nice to have it know how to "put it back the way it found it" when you are all done.

Is there an easy way to check MC (via COM Automation or something) and find out if it is currently running in the tray vs. Windowed (or Theater View or whatever)?

I've looked into implementing pinvoke GetWindowPlacement, but this looks ugly and I might have trouble figuring out if it is in Theater, Fullscreen, or whatever.  I really, in this case, only care if it is in Tray mode vs "anything else".  But, frankly, for other uses it would be nice to be able to query the current "view state" of an instance of MC.  I'm not seeing anything in the COM Automation stuff, but maybe I'm blind or missing it?

Any ideas?

[Matt]

I think the program should be doing this for you.

Ideally we'd count external references to MJAutomation objects and go back to "no UI" mode if you close while there are external references.  Does that make sense?

I suppose this could get us in trouble if you release the main automation interface but hold references to other interfaces.

[glynor]

I suppose this could get us in trouble if you release the main automation interface but hold references to other interfaces.

My wrapper wouldn't ever do this, since it holds a static copy of the main automation interface open in a singleton class (and releases it when you close the application or manually ask it to release it).  I did this to keep multiple threads and crap from ever accidentally opening more than one for no good reason, and in any case, you can't run (normally) more than one "copy" of MC simultaneously, so there is no reason to grab more than one copy of the main automation interface.

It would be convenient if MC handled this for you and I didn't have to worry about it.

For now, I have it working fine except the edge case where:

1. MC was previously running in Library Server (tray) mode (so therefore, you'd want to return it to that state when done).
2. You do something via the Automation interface that causes MC to come to the foreground (like play a file or whatever).
3. You then dispose the automation interface (exit the app or whatever).

In this case, it leaves MC running in Standard View (because it checks to see if it should "close", says no, and then leaves it open, but doesn't know that it is in a different state than when we started.  I actually discovered it accidentally because I was just running a test of your new Command Line option you added (to show the View).

This really is an edge case, though.  It doesn't seem like the end of the world because if you're running something that brings it to the foreground, it seems like the user would probably be sitting at the console anyway (otherwise, what's the point of playing something or showing them a view).

However....

[glynor]

Once I started thinking about it, there are other cases where it would be handy to know what "mode" MC was in currently.

So, for example, in my app, I have an option to hide all tooltip bubbles on the tray icon, so that it can run completely in "silent mode".  I figured that if this is something you'd be scheduling to run automated, some people wouldn't like it if the tooltip popped up "randomly" while you were watching a movie or whatever.  So, I added an option to completely hide all tray icon tooltips.

But, wouldn't it be cool if I could also check to see if Display View or Theater View was active, and then hide them by default?

Also, if you're going to do something like activate a particular view, you wouldn't want to do it if the user is mid-playback or in Theater View, where it might screw up their experience (at least not without warning).

I've looked into using P/Invoke to check to see if MC's main form is visible or not, and that shouldn't be too hard to do from managed code (the Win32 API IsVisible call is just a simple bool which auto-marshals to the proper managed type).  But if I want to check anything else about the Window State, it looks like a giant pile of trouble that would probably end up requiring a bunch of separate wrapper classes, user-defined types, and structs (and it might even be simpler, in the end, to write a small C/C++ application that would do the API calls and report the results you want back via COM).  It's annoying that .NET still doesn't have access to the (seemingly simple) User32.dll API calls for Window State for non-managed apps, but there we are (I found a bunch of references to this on MSDN from years ago with Microsoft people assuring you that this would all be sorted out in the next few years as .NET matured).

Sigh...  There's a lot to like about C# (it is certainly fast-to-develop and modern), but it does still feel half-finished in a few dark corners.