I submitted a bug a while back titled KeyboardEvent.keyCode value is decremented by 64 when Control key is down on Mac and it seems to be languishing in the purgatory that is Community status. While the title is pretty self explanatory, what it boils down to is that adding keyboard shortcuts to your Flex application can become quite tricky if you plan on supporting Mac users.
Particularly troublesome is the Q key, whose keyCode is normally 81. Thanks to this bug, Ctrl + Q returns a keyCode of 17. Problem is, 17 is also the keyCode for Ctrl by itself, and for Command by itself. Discerning between the two is more or less impossible, which sucks.
Can I get some vote love from the community?
Yep, in just one short month the best Flex conference around will kick off its fifth installment in San Jose, California. Its almost silly how much I look forward to these things but they are just that good. Great people, great sessions and great parties (where a good lot of the best conversations happen) is just something you can’t pass up. Especially for under $500! Besides, you can talk your company into paying right? I guarantee you will come back a better developer.
I am honored to be speaking at this event again, especially when you look at the unbelievable speaker lineup as a whole. Check out just this small excerpt:
If that’s not a list of industry experts I don’t know what is. In fact, if those people aren’t in your blog reader shame on you. 
So seriously, make it to the event if becoming a better developer and making some new friends is anything you’re interested in. I promise you won’t regret it.
Register Now!
ToolTipManager.toolTipClass doesn't work in Flex 3.0 out of the box. While its intent of allowing you to specify a custom IToolTip implementation is great, ToolTipManagerImpl simply acts as if the property doesn't exist and instantiates an instance of ToolTip. Luckily, the fix is quite easy if you are willing to do a bit of monkey patching. You just have to make a slight modification to the createToolTip() method, making it look like the following:
public function createToolTip
(text:
String, x:
Number, y:
Number,
errorTipBorderStyle:
String =
null,
context:IUIComponent =
null):IToolTip
{
// ***** USE THE PROPERTY! *****
var toolTip:IToolTip =
new ToolTipManager.
toolTipClass();
var sm:ISystemManager = context ?
context.systemManager :
ApplicationGlobals.application.systemManager;
sm.toolTipChildren.addChild(UIComponent(toolTip));
if (errorTipBorderStyle)
{
UIComponent(toolTip).setStyle("styleName", "errorTip");
UIComponent(toolTip).setStyle("borderStyle", errorTipBorderStyle);
}
toolTip.text = text;
sizeTip(toolTip);
toolTip.move(x, y);
// Ensure that tip is on screen?
// Should x and y for error tip be tip of pointy border?
// show effect?
return toolTip;
}
Here is a diff of the base and updated classes.
As an aside, an easier fix is said to exist here, but it doesn't seem to work when calling ToolTipManager.createToolTip() directly, which is what I needed to do. If you are using toolTips normally by just setting the toolTip property I would recommend trying Peter's fix first.
I would also like to go on record that I hate the *Impl naming convention. Despite what Theo says, I like my interfaces with I's. *Impl just seems kludgy and redundant, and it reminds me of AS2.
Recent Comments