Not too long ago, Adobe launched Flash Player 10. Hooray, party! But not everything is well in this new flashplayer. I believe this is the first flash player which actually breaks old flash apps. This is because Adobe tightened the security with this new version even further.  Now, I am aware that security is necessary for a plugin like flash. But there’s one measure I can’t figure out.

Any browse or save as dialog can only be triggered by user input (keyboard or mouse(click)). And this makes sense, you don’t want an ad to popup thousands of ‘browse’ windows. But I cannot see why this same security measure is taken for doing a multipart request. Why sould user interaction be needed to upload, say a bytearray, to the server. This bytearray could easily be generated from a bitmap(data), so no browse for file window is needed.

This error came up in an application which displays a small photo. The user can upload a photo to the server. This server is somehow not capable of resizing images, so the uploaded image is downloaded to the flash again, resized in flash and send as a bytearray to the server again.

This worked perfectly in FP < 10, but now, there has to be some interaction to do the second upload. We worked around this by having a small popup asking the user if the uploaded picture is the correct one. Works also, but it’s just a work-around, not a solution.

I talked about this issue with James Ward of Adobe, and he also didn’t see why this security has been taken. So, I’ve created a feature request in the bug system of adobe, located at https://bugs.adobe.com/jira/browse/FP-978. Please vote if you think this is a ridiculous security measure and should be removed!

Thanks!

Today I encountered some strange behaviour when using the [ArrayElementType] tag. I had a piece of code which looked like this:

package {
	import mx.collections.ArrayCollection;
	[Bindable]
	public class MetaData {
		public var ac:ArrayCollection
		[ArrayElementType("nl.flexperiments.test.TestObject")]
		public var ac2:ArrayCollection;
	}
}

more…

I just ran into another strange behavior of flex. Lets say you have a VBox, with an image inside. When the user clicks the image, it should do some stuff, but when the user clicks (mousedown actually) the VBox it should start dragging. You would expect that when you click the image, both events are fired. This is true when you don’t invoke the dragmanager. If you call the dragmanager, it cancels out all further mouseEvents, thus preventing the code of the image clickhandler to execute. more…

Damn I hate the new flex builder. Flex Builder 2.0 wasn’t good, but the new Flex Builder is just plain rubbish! I wish adobe didn’t bought macromedia, I’m sure MM wouldn’t release such a crappy product and have the guts to call it a complete new version. FB3 doesn’t even deserve the name beta, let alone final!

more…

Flex / Flash has a neat feature: doing math for you.

So when you want to know what 0.1 + 0.2 is, you don’t need your calculator, just use flex. The result: 0.30000000000000004.

WTF is that about?

I’m currently trying to find out a fix for this. ATM the only workaround is doing a

var x:Number = 0.1 + 0.2
Math.round(x*10) / 10

How hard is it to add to two numbers and give the correct result?

or of course

var x:Number = (0.1 + 0.2).toFixed(1)

Works for actionscript as well as JavaScript

By the way, it’s not only 0.3 which is causing problems. more…

I recently discoverd another bug in Flex 2.0.1 / ActionScript 3.0. You cannot trust the enabled property of some components. Especially listbased components like datagrids. When you set the enabled property of a datagrid to false, it still responses to doubleclicks and happily fires it’s events. Probably not what you want. The solution is fairly simple though:

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"  >
	<mx:DataGrid
		id="contentitemGrid"
		doubleClickEnabled="true"
		mouseChildren="{contentitemGrid.enabled}" />
</mx:Canvas>

By disabling it’s mouseChildren property, the clickevents of the datagrids children (the items) aren’t fired anymore, so the doubleclick is ignored.