Joeflash’s Enigmacopaedia

Rounded Clipping for Fx4 BorderContainer

Posted in Flex, Flex 4 by Joeflash on the March 17th, 2010

A few days ago someone in the Flex 4 prerelease forums posted an interesting question: how do you create a rounded clip area for a spark container? Not knowing the answer off the top of my head, I thought this would be a good opportunity to teach myself some specifics about creating custom container components in Flex 4.


First I tried the obvious, which was to set up two elements and make one the mask of the other, like so:

  1. <!-- maskee -->
  2. <s:Group id="cpmaskee" width="400" height="250" top="20" left="20"
  3.          mask="{cpmask}">
  4.     <!-- this is the content -->
  5.     <mx:Image source="@Embed('wallpaper-halo-3-01.jpg')" x="-100" y="-100"/>
  6. </s:Group>
  7. <!-- mask -->
  8. <s:Graphic id="cpmask" top="20" left="20">
  9.     <s:Rect width="400" height="250" radiusX="20" radiusY="20">
  10.         <s:fill>
  11.             <s:SolidColor color="0xCCFFCC"/><!-- can be any color -->
  12.         </s:fill>
  13.     </s:Rect>
  14. </s:Graphic>

Which resulted in a nice rounded mask over the content:


But this was not quite what I wanted. The entire image was still being rendered, only not visible through the mask. So the edges of the image needed to be clipped regardless of whether the corners were rounded. And to be able to see a rounded border.

Simple Monkeypatch to fix ToolTipManager.destroyToolTip RTE

Posted in Flex, Flex 3 by Joeflash on the March 13th, 2010

So I’m coding a custom tooltip which stays visible when you click on the target (more on that in a future post), so I need to manage the tooltip behaviour with ToolTipManager.createToolTip rather than the UIComponent’s tooltip property, or tooltip events. Ben Clinkinbeard’s monkey patch for ToolTipManagerImpl came in real handy for this.

From this “always on” tooltip, I have a button which asks the user for confirmation before performing the action, after which I dismiss the tooltip. Problem is, an RTE “The supplied DisplayObject must be a child of the caller” always ensues.

Until I realized that calling when a tooltip is showing always dismisses the currentToolTip. So calling ToolTipManager.destroyToolTip on a ToolTip which had already been “dismissed” would of course generate an RTE.

Shouldn’t the ToolTipManagerImpl class be smart enough to figure this out without bugging me with an RTE? Shouldn’t it check first to see if there are children present to remove before attempting to remove them? There may be other situations in my app where I may not always be aware of whether my tooltip is located in the toolTipChildren list.

So, taking a cue from Ben’s monkeypatch, I scrolled down to the next function, and monkeypatched mx.managers.ToolTipManagerImpl.destroyToolTip():

Original code:

  1. public function destroyToolTip(toolTip:IToolTip):void
  2. {
  3.     var sm:ISystemManager = toolTip.systemManager as ISystemManager;
  4.     sm.topLevelSystemManager.removeChildFromSandboxRoot("toolTipChildren", DisplayObject(toolTip));
  5.     // hide effect?
  6. }

Monkeypatched code:

  1. public function destroyToolTip(toolTip:IToolTip):void
  2. {
  3.     var sm:ISystemManager = toolTip.systemManager as ISystemManager;
  4.     if(sm.topLevelSystemManager.toolTipChildren.numChildren){//patch to avoid RTE//
  5.         sm.topLevelSystemManager.removeChildFromSandboxRoot("toolTipChildren", DisplayObject(toolTip));
  6.     }
  7.     // hide effect?
  8. }

In addition to correcting my errant destroyToolTip call, this solved any future unknown RTE’s around that issue.

Alternately, if you don’t want to monkeypatch the ToolTipManagerImpl class, you can wrap your destroyToolTip call in a try/catch error block.