On events

I’ll occasionally post a few tales from the development of Potlatch for those of a more technical inclination.

Potlatch makes very heavy use of Flash’s built-in events. Some of these are fairly simple mouse events. Each MovieClip (a “sprite”), for example, has events including onPress, onRelease, onRollOver and onRollOut. Potlatch uses these to tell when you’ve clicked on a way, or dragged the map, or clicked a button.

Fine so far.

Flash also has really useful events for textfields. Potlatch uses onSetFocus, onKillFocus and onChanged. So, when you’re typing a tag name or value, every keypress triggers an onChanged event; when you click in the value, that triggers an onSetFocus – and possibly an onKillFocus for the textfield you were in before.

The tricky bit is that sometimes these events don’t fire in quite the order you expect.

Take the blue autocomplete menus. If you select an item in one of these, Flash fires an onPress event for the menu, just as you’d expect. But it also fires onKillFocus for the textfield that you’re editing – and it does that before the onPress event.

The result is that Potlatch sees that the textfield has lost focus; looks in the textfield; probably sees it’s empty; and thinks “oh, the user is leaving the textfield with the value empty, that means they want to delete the tag”… and deletes the tag. So when onPress fires immediately afterwards, there’s no tag any more to put its autocomplete value in.

This is the sort of thing that is really, really horrid to debug, trying to work out which order things are firing in. I eventually fixed it by adding a new onMouseDown event for the whole of Potlatch, which simply notes a mouse-click – and this, happily, fires before both onKillFocus and onPress. So the onKillFocus event now checks for this; if it figures “yes, the user has just clicked the mouse”, and the mouse is currently over the autocomplete menu, it just returns without doing anything.

(This fix is one of the new things in 0.8!)

Another case. When you press “+”, Potlatch adds a new blank tag, and helpfully selects the ‘key’ field for you. Except if Flash had its way, it would then promptly populate the key field with the string “+”. I figured “+highway=trunk” is probably not a useful OSM tag, so there’s now a couple of lines of code to say “if it looks like the user has changed the key to +, they probably don’t mean it”.

So apologies if your super-duper private tagging scheme uses + as a key, because Potlatch won’t let you enter it.

Incidentally, there’s some relevance here to the is-the-iPhone-getting-Flash-or-not discussion. Performance? Not a problem – AVM2 is reputedly pretty fast on ARM, and hey, it works on the much less powerful Chumby. Choking the iPhone? I don’t think so – Safari on Mac already restricts Flash CPU time if it’s not frontmost anyway. Politics? Yes, almost certainly. But the big development problem as I see it is that events like onMouseUp don’t easily translate to iPhone touch events, and a lot of Flash apps are built entirely around these events. I’ll be really interested to see how Adobe gets around this.