Bug

Flex / AIR / DataGrid / itemEditor bug?

If you are using DataGrid in a Flex/AIR application, the chances are you will at some stage hit the following RunTime error…

TypeError: Error #1010: A term is undefined and has no properties.

.. with a traceback indicating the error occurred within DataGrid.as. At which point you will stare at your own code for a while and wonder why.

In my circumstance I pinned this down to clearing the contents of the data provider and repopulating when there is an item renderer active on the DataGrid. A use-case that probably doesn’t come up that often in web-based Flex apps, since if the user clicks another control to trigger an update, the item renderer is exited at that point and the edit committed prior to the dataprovider changing.

In an AIR app, we have native menus available to us. When the user employs native menu selection, the item editor remains active. If that menu option triggers a repolpulation of the data provider (use-case example File>Open), we then get the error.

The workaround is pretty simple. A call needs to be made to destroyItemEditor() on the DataGrid instance before repopulating it’s data. In a simple application this is no great problem. But if you’ve gone to the effort of using something like the PureMVC framework to separate Data Object from View Components, the data object isn’t supposed to have any knowledge of the view. So in my case thefix is quite crude – when issuing the open command, a notification to destory item editors will be issued so any view component that uses them may destroy their editor prior to the repopulation.

My contention is that it should be the responsibilty of the DataGrid to destroy the item editor if the dataprovider updates.

I have this logged as a bug with Adobe (SDK-15280), along with sample code demonstrating the issue. Feel free to review and vote for the bug if you are in agreement with my point and comment further therein if you disagree or have better suggestions to offer.

Posted by creacog in AIR, Bug, Flex 3, Flex Builder, 0 comments

flex, mac, external browser

Ted Patrick has been quite prolific of late at publishing little productivity hints and tips. I think this one from a couple of weeks ago is worth echoing and noting the workaround for the problem it raises on a Mac.

We are setting up Builder to launch the help pages into an external browser. The key advantage of which being that the code samples can then be copy/pasted. On a Mac there is a recognised bug in eclipse that if you choose Firefox as the external browser, and it is NOT your normal system default browser. Basically Eclipse attempts to launch a second instance of Firefox which will generate the “Only one copy of Firefox can be open at a time” dialogue…

Firefox close dialogue

So to get around this, you have two options.

Option 1, if you have Firefox as your default browser for the entire system, simply choose “Default system Web browser” in the Eclipse preferences panel.

Option 2, if you want to keep something else set as your system default browser e.g. Safari, but would use Firefox for displaying Flex Builder help, you need to either edit or create a new external browser entry using a command structure as per comment 5 on the eclipse bug sheet. Essentially the following settings work…

  • Location: /usr/bin/open
  • Parameters: -a firefox %URL%

Flex Builder > General > Web Browser >Edit external browser

Posted by creacog in Bug, Eclipse, Flex, Flex 2, Flex 3, Mac OS, 1 comment

a little fireworks CS3 bug

Well in my opinion incorrect user-interface behaviour rather than a bug. I just used Adobe’s report a bug form, but ironically my Safari crashed when I hit the submit button, so I’ve currently got no idea if this went forward.

The issue concerned is not new and not really a big deal, but I just had to process a pile of images and it bit me so many times I had to get it out of my system by writing about it…

The interpretation of the tab key within the properties panel for certain selected tools is in my opinion incorrect and is inconsistent with established convention.

Example 1: Marquee tool selected:

1. Set the style to Fixed Ratio or Fixed size
2. Double-click the marquee width property
3. Type with desired width.
4. Hit tab

At this point I’d expect the focus to tab across to the Marquee height property. But it doesn’t. It sets the focus on the marquee width property and selects it. I need to hit Tab a second time to get to the height property.

I’ve been caught by this so many times. It is impossible to learn to accommodate to this odd behaviour because in every other application I have ever used, tab takes focus to the next input field.

Example 2 : Eraser tool selected:

This shows more clearly the logic which has been implemented.

1. Double-click the value of the Size property
2. Type a new value
3. Hit tab

Again, instead of tabbing to the next input field (Edge) the focus remains at the Size property – value selected.

4. Double-click the Edge property
5. Type a new value
6. Hit tab

At this point instead of tabbing to the next field (Opacity), you tab back to the Size property!

In summary, it seems the implemented behaviour is that the first use of tab within a field-set of the properties panel always tabs to the first item of that field-set, the tab sequence is thereafter obeyed until you leave the field-set. I feel the behaviour should always be to tab from the current field to the next.

I’m a programmer rather than graphics dude and I use Fireworks infrequently. So many times I’ve typed a width, tab, then a height only to find I’ve just overwritten the width with the height – no big deal – but a tad annoying!

Posted by creacog in Adobe, Bug, CS3, Fireworks, 1 comment