Update 02-04-08: This was an April Fools prank.
Sorry everyone!
By now most people have probably heard the news of a significant security flaw discovered in the Adobe Flash Player. The vulnerability was discovered during the CanSecWest security conference, where Shane Macaulay used the flaw to hack into a laptop running Vista SP1and execute arbitrary code.
Part of the terms of the conference was that the details of the vulnerability would not be disclosed until Adobe had a chance to patch them, so we were all left to speculate based on the far reaching security updates coming to the Flash Player in April.
That is, until now! Adobe has now released this video, where some key details of the exploit are explained. Check it out!
As I mentioned in my previous post, I recently upgraded my PHP installation to PHP 5, and the process caused me a lot of grief. I’m trying to document my experiences here so that in the future other people will hopefully be saved the pain that I went through.
The Problem
Once I had my PHP scripts running, I quickly noticed was that every time I stored a value into the session object, that value would be gone by the time the next next request to the script came through.
I did a lot of tests to eliminate any possibility that there was nothing else in the system which might be clearing the session variables or overwriting them etc. Eventually I tracked it down to the fact the php.ini file contained a path where session data would be stored, and similar to the previous issue I had with PHP, it was again DOS style file paths which were causing the problem.
(more…)
Recently I upgraded my PHP installation to PHP 5. The process was fraught with issues for me, but hopefully posting what I learnt here will help other people get back up to speed faster than I did.
The Problem
The first thing I noticed after installing PHP is that every time I tried to access a PHP script, whether through my browser or from a Flex application, I would get a 404 error.
This problem really baffled me for a long time until I discovered that the problem comes from PHP referencing itself with IIS using a DOS path which means the PHP executable cannot be found.
(more…)
I’ve been involved with several projects in the past where the Flex Charting components have been used to show information to the user. However I have always struggled to get the DateTimeAxis in particular to behave correctly and have often had to resort to using a CategoryAxis instead in order to get a deliverable product. A quick look around the blogsphere shows that I am not alone in this either.
(more…)
A few weeks ago I wrote about a solution I had found for making flash paper assets behave correctly inside Flex applications. I have been using this solution within my current Flex project, and it works quite well in simple cases. In some more complex cases it simply didn’t work however, and I spent a lot of time tacking down the solution.
The problem can occur when you manipulate the FlashPaperLoader component at runtime (e.g. resize and/or change source). Often when things are changing, the FlashPaperLoader swf isn’t initialized and ready to receive the calls through external interface. This means it can’t relay the sizing instructions to the FlashPaper.
(more…)
Anyone who has ever tried to load a FlashPaper document within a Flex application knows that it’s not as simple as one would hope. I was struggling to make my application appear correctly for several days before I came across the solution, and I hope by posting it here that more people will be able to find it too.
(more…)
In my last post, I explained how it is possible to invoke a function ‘inside’ an object which it was not declared inside. This is means that within that function, the key word ‘this’ points to the object you are currently running inside. I am using this functionality within my current project to make highly configurable/reusable components, but I have recently come across a pretty major limitation that I wasn’t expecting.
Using the ‘call’ function of the Function class, it is possible to change the object which will be referred to by the keyword ‘this’. However, despite the fact that your code now refers to things through the keyword this, you can only access public properties and functions of that object. This makes the functionality pretty redundant, because you can’t do anything with this that you couldn’t do more intuitively another way. (more…)
I seem to be coming up against problems regularly on my current project for some reason. It’s probably because I am extending many of the basic flex components to allow for intelligent databinding. My new controls will automatically implement a two way data binding to the selected item/index of their data provider collection. This makes building data driven applications very very easy, but it relies on all of the components to behave as documented, particularly their events need to fire as expected.
The fact that Flex components should dispatch ‘change’ events only due to user interaction, and not to programatic changes, has long been part of the Flex conventions and is true for all of the built in Flex components… except the CheckBox control.
It cost me most of the afternoon, but I can confirm that the CheckBox component dispatches a change event when the ’selected’ property is programatically set. I looked in the Flex Bug and Issue Management System and found that this bug has been found and logged against Flex SDK M2 (the Moxie beta). Ironically it was logged as a backwards compatability issue, even though it is broken in Flex 2.0.1 Hotfix 2. This issue will be fixed in the next release of Moxie, and I don’t think it’s worth logging it against Flex 2.0.1 aswell.
It’s frustrating that I’m comming across these issues, but it’s cool that the bug tracking system is so open and they guys at Adobe are so quick to respond to bugs and requests.
I still love Flex
UPDATE: Adobe Confirmed that there was an error and have corrected the documentation
The Adobe Live Docs for the TextInput and TextArea class clearly document that the change events coming off these controls bubble. Ie. they have bubbles = true. A bubbling event is very convenient because it means you can listen to the parent of the changed control and hear the event rather than having to listen to the control itself.
I wanted to use this functionality on a form I am building in flex where I want to detect if the form needs to be saved (ie. any of the data has been changed). If the events behaved as documented then it would be easy to listen to the panel which holds my form components and get all change events. Unfortunatly, after much testing and confusion, I now know that the events do not infact bubble. Silly me for trusting the documentation.
While trying to figure out where my events were going, I read through the source code of the TextInput class. Here’s what I found on line 1990:
// Stop propagation of the original event
// and dispatch a new one that doesn’t bubble
event.stopImmediatePropagation();
dispatchEvent(new Event(Event.CHANGE));
So far from dispatching a bubbling event, they actually explicitly stop it from bubbling.
The simple work around for this is to extend the TextInput class, catch the change event and dispatch it again as a bubbling event. I notified the Adobe guys that the documentation is wrong, but I’m suprised that someone else wouldn’t have encountered this before.