Well I thought my articles covering off sizing a component in the IDE were at an end. That was until I got a comment from Justin Levi regarding resizing a component via the component inspector panel, he posed the following:
Great examples. Have you ever found a way to size the component container based on component inspector parameters? I don’t know if it can be done. I’m working on a grid component where it would be very useful to have the design view update based on the grid rows and columns.
Now if I am interpreting Justins question correctly then the answer is yes and no. If I’ve completely missed his point then this article may still provide a few useful bits of information for component developers and users…
The issue here is that the bounding box used to define the initial size of our component instance on the stage will not resize if we change the components dimensions via the component inspector panel. Now apart from being a bit unsightly it can present a few interaction issues when using the component during development.
For example imagine if you will that we have a component that is placed on the stage with a default width and height value of 100 x 100. Now if we use the Free Transform Tool (FTT) to alter the dimensions we are actually changing the size of the component symbol on the stage (as we can with any symbol or graphic within the Flash IDE).
However, if we try to reproduce this via the inspector panel, while we can indeed set the width and height of our component, we cannot alter the component symbols actual stage size in the IDE. This doesn’t mean that the component will not resize to reflect these changes – if they have been produced in line with the Macromedia framework then they will indeed change.
Now here is where the problem arises, the component may have changed but its stage presence hasn’t. By this I mean that while the component will appear to be, say 300 x 300, the actual stage size (i.e. the part you can actually interact with via the mouse allowing you to move it etc.), will still only retain its default size as defined in the symbol. In this example it would be 100 x 100 (see the image below). This doesn’t affect the component when published, it will have the correct dimensions of 300 x 300.
Now if you can live with this, and in my opinion this should be raised as a feature enhancement, then yes you can use the component itself to update its size. Why does it work this way? Well from what I can see the symbol that is dragged onto the stage is just a object that links to the Live Preview (SWF) part of the component. Therefore if you change its size the component automatically updates to accomodate the changes.
However as the Live Preview is just sitting inside the container that is the symbol instance it has no direct hook to the IDE and therefore cannot update the display to get the IDE to redraw its assets and thus change the size of the actual symbol to that of the components new dimensions. I could be talking absolute nonsense ofcourse. If any of the Adobe engineers would like to chip in and give a clearer overview of this please feel free.
If you want to see it in action you can grab the relevant files from the downloads page
You might have noticed that the Flash IDE usually masks the area of the component at authortime. Anything outside the area that Flash thinks the component is in gets masked. Sometimes this mechanism fails (I’ve not found any pattern to this failure) and the authortime component can exceed the bounds of this mask. So, removing this mask would be part of the solution, but it would also allow components to “pollute” any part of the stage at design time. The big problem here is getting Flash to listen to the changes in the component. I’ve tried every possible avenue on this problem and concluded that it is impossible. Flash communicates to the component, but the component is unable to communicate to flash. For instance, there are times when changing one parameter might affect another. It would be nice to communicate this back to the params panel and potentially to other parts of the IDE (for size and positions), but is currently impossible.
As a side issue, ever noticed that at authortime, components actually live on their own “stage” and no matter where the component is on the main stage, if you trace it’s _x and _y, they are always 0,0. They also only have access to their own “private” library, not the library of the project they are placed in… this makes skinning in live preview completely impossible. It appears that MM have partially addressed this issue with the “skins” for the FLVPlayback component, but adapting this mechanism to any other purpose has proved fruitless. It is a completely unextensible mechnism ONLY for skinning the FLVPlayback.
I think that due to MM’s component implementation, changing the way these thing work would be much trickier than is seems at first glace. Components at authortime live in a sort of inpenetrable sandbox. It would be interesting to know exactly why MM chose this to be the case.
I’m so glad you replied to my comment! I really was banging my head against the wall for quite some time trying to figure out a work around and came to the same conclusion that it just can’t be done. I am going to submit this feature be added in the next release. Seems like it could be somewhat useful for component development.