Why doesn’t the shell animation control tell me the dimensions of the animation it is displaying?


As we saw some time ago, the shell animation control suffers from many limitations because its job is to be a scaled-down animation control instead of one of its more full-featured counterparts.

One customer wanted to know how to load an animation into the shell animation control and then query its dimensions. Well, there is no message that reveals the dimensions of the animation. Why not? Because you should already know.

You can't use the shell animation control a general-purpose animation control because of those pesky limitations. You can only use animations that you yourself authored to conform to the control's rather stringent requirements. And since you authored those animations yourself, you already know what their dimensions are.

If you don't know the dimensions of the animation you're putting into the shell animation control, then how do you know that it meets all the other criteria either? In other words, to know that the animation is suitable for the shell animation control you already had to know far more about the animation than its dimensions.

Remember that the shell animation control supported only what the shell needed it to do when it was introduced in Windows 95. The shell team then figured, "Well, we wrote it, we may as well document it for others to use." Of course, no good deed goes unpunished, because this gift has turned into a liability: Even though Explorer stopped using the shell animation control years ago, the code for the control must remain in the product because it was documented to the public, and along with the code come all the support burdens.

Comments (12)
  1. Pierre B. says:

    The limitations the control imposes and the request to know the size of the animation are of a different nature. The former are understandable limitations due to the simplicity (we assume) of its implementation. No audio, no interleaving. The latter is just a failure of exposing information the control must already have. To be able to render and paint teh animation, it must have its size. It just fail to expose it.

    There are good reasons to want to query it. The most obvious one is to enable writing generic code to handle animation in your application. Now, due to the limitation, you must not only pass around the animation name, you must also track the animation size. Worse: this size tracking is probably handled manually, which makes it more likely to be out-of-0sync with teh animations.

    All-in-all, a valid request for information that the control already has with a reasoanble use case.

    I guess the customer went with the larger, more complex control.

    [Explorer always used the animation in situations where the size was known ahead of time anyway because there were other UI elements arranged around it. And as noted in the last paragraph, the shell common controls supported only the features Explorer needed. Your program presumably knows the size of the animation because it’s going to put the generic animation control somewhere and arrange other elements around it based on the known animation size. So you already have the information; you just need to pass it along to the generic control. -Raymond]
  2. Leo Davidson says:

    There’s probably no need for users of the control to track the information anyway, at least if they set the control’s size to match the animation’s size (maybe plus a border) when setting it up.

    If they do that then they can get the animation’s size later by deriving it from the control’s window rect. The only part that has to know the size is the part that sets the animation and lays out the control, as Raymond says.

    (I’m only guessing as I’ve never used the control myself.)

  3. CGomez says:

    I don’t work for MSFT and know nothing about how they REALLY have to comply with Justice Department consent decrees.

    But I can imagine this type of thing could come up again and again in other situations.

    Some group develops a custom control, API, or interface to get some unit of work done.  That ends up shipping with the OS.  They have no intention of documenting it and releasing it "in the wild" because it’s not that developer-friendly or ready for prime time "generic use".

    Then the complainers come along and say MSFT is hoarding undocumented APIs and stifling competition and demands these APIs be documented and shared.

    It’s no different from m solving my own little problem with a single use bit of code and then deploying it in an application for use with Windows, but then being forced to document that for anyone else to use.

    The kicker, and the point of this article, I presume, comes when the complainers lament that the control "should be better" for some reason… like… you should be able to query the dimension of the animation it is displaying.

  4. Pierre B. says:

    Well, I’m sorry to say that is a method of designing bad UI. I can tell when people use this method of UI layout (i.e absolute position) because their UI react very badly to localization and larger font size. I always use the large font size setting and the number of applications that break or at least look wrong is depressing. 2010, you’d think people would know how to design flexible UI.

    [Well then it’s a good thing Explorer stopped using it years ago. -Raymond]

    In my opinion a non-negotiable requirement for applications is a layout manager. With that in place, you get proper layout, proper response to larger fonts, almost free proper resizing behavior, potential flexible customizable UI (toolbars, etc). Usually this means having a layout that says this button goes to the left of that one, this control resizes only vertically, this one is anchored to the bottom. Once you do this, the layout manager needs to query the controls for their natural size. Hence, the need to query the animation for its size.

    (Yes, Windows tries it best to do thing magically, but it often doesn’t look quite right.)

  5. Absotively says:

    @Pierre B.: What is the difference between having a layout manager (which will of course get things wrong once in a while, because everything has bugs) and having some code to “tr[y] it[s] best to do things magically, but it often doesn’t look quite right”?

  6. Matt Green says:

    It’s almost as if the component interface was designed to be minimal, yet complete!

  7. Leo Davidson says:

    @Pierre B.: I don’t see what difference it makes to doing layout whether or not the control can tell you how big the animation you put in it was.

    If you want the animation to stretch with the layout then you don’t care what size the animation is (and effectively redefine the size when the layout changes).

    If you want the animation to stay a fixed size then you set the control to that size when you give it the animation, and you can then know the animations size (though why you’d want to I don’t know) by getting the control’s size.

    I fully agree that a good, font- and language-sensitive layout system is still lacking these days from almost* all UI frameworks (not sure it’s the OS’s job) but this seems like a red herring to me.

    (* Probably all, but maybe there’s a great one I haven’t used yet.)

  8. Anonymous Coward says:

    Well, Microsoft could turn it into a thin emulation layer over DirectShow and/or make the control redistributable instead of shipping it with windows, although I suspect that due to the size of the component the latter isn’t worth it.

    [But the whole purpose of the shell animation control is to avoid loading DirectShow! -Raymond]
  9. Pierre B. says:

    Absotively: because the code in the presentation manager of Windows (or which ever component actually has that responsibility) doesn’t know the desired layout relationship. Currently, it basically stretch everything the same amount and hope for the best. You can see it in easily half of wizard-style product installers: they’ll have a bitmap at top and it will be badly stretched and pixelated.

    Leo: it’s exactly because you don’t want the animation to stretch that you need to figure out its size at run-time. Yes, you can hard-code it’s size in whatever layout tool or layout file you use, but it’s more work and a lot less flexible (beside, you usually only get the final anim late in the project and the artist may want to change it mid-way). I’m not saying it’s impossible to work without the capability to query the size, I’m saying it can make the UI design more flexible and more designer and coder friendly.

    Otherwise, you could make the same arguments

    It’s already tough enough to follow all the platform guideline (UI spacing, UI layout "best practice" for the current fa, etc.) and try to automate it all so that it’s not tedious for the designer (how many pixels in between buttons? Between control and windows sides?) without having to special-case yet another control because it can’t tell you it’s natural size.

    Anyway, I think we agree on the principles, I was just nit-picking the blanket statement that you should lready know teh size of the animation when doing the layout of teh UI.

  10. 640k says:

    [But the whole purpose of the shell animation control is to avoid loading DirectShow! -Raymond]

    Because the guy who wrote the animation control thought his coworkers was stupids that wrote stupid code.

    Please use your own components/software if you expect someone else to do it.

  11. Because the guy who wrote the animation control thought his coworkers was stupids that wrote stupid code.

    No. Remember this was devised for windows 95. Raymond has been over the various things they had to do to squeeze down memory consumption, including such things as "mini-COM" in the shell, to avoid taking a hot for loading OLE. DirectShow is a heavy component. Would users really be pleased to right click the recycle bin and try to empty it only to have to wait 10-20 seconds just for DirectShow to initialize? Probably not.

    Sure, they could make it a DirectShow wrapper now with no ill effects, but on the other hand, the developers could also use the full blown control with no ill effects either.

  12. me says:

    I suppose this is one of the apis that were exposed as part of the Internet Explorer settlement. I tried, but I really can’t feel sorry about that.

Comments are closed.

Skip to main content