assertTrue is the professional blog of Luke Bayes and Ali Mills

Workaround for Safari Blocking Flash Initiated Pop Ups

Posted by: Ali Mills Thu, 23 Aug 2007 04:59:00 GMT

Uncontrolled browser pop ups suck, and I’m very thankful for pop up blockers. There are times, however, when you want controlled pop ups. It’s these times – the times when a user initiates the call to action – when the browser’s pop up blocker should let them through. Browsers are pretty good at managing this when the user initiated action starts in HTML, and most also do a good job when the action starts in a SWF. There’s at least one big exception – Safari.

The standard path in Flash to open a browser pop up is to use ExternalInterface to call a JavaScript function in the wrapping HTML page that contains a window.open call. This path works in all the browsers I tested in except for Safari, which leads me to believe this a Safari bug.

Luckily, if you want to open browser windows from a SWF in Safari there’s a workaround other than disabling the “Block Pop-Up Windows”! Check it out:

The workaround works by:

Read more...

Tags ,  | no comments | no trackbacks

Issues with Embedded Fonts in Flex Modules

Posted by: Ali Mills Fri, 08 Jun 2007 18:18:00 GMT

We’re working on a modular application in Flex and until recently were having issues with embedded fonts in modules. The main issue was that we wanted fonts embedded in the main CSS to be available in the loaded modules, and we were having a heck of a time getting this to work.

Some research led me to Alex Harui’s post about how to use embedded fonts in modules and late-load the embedded font. Alex’s example demonstrates Flex 2.0.1’s new runtime CSS approach and uses the StyleManager class.

We’re not, however, interested in loading the CSS at runtime (although we reserve the right to change our mind, because it’s a really handy thing to be able to do), so I modified Alex’s example to more closely represent our application structure with hopes of finding my mistake. After the modification, it became clear that I wasn’t making a mistake, but that I had run into a bug. Can you spot it? Here’s the code…

Read more...

Tags , , ,  | no comments | no trackbacks

Flex Builder 2.0.1 DataGrid Woes...

Posted by: Luke Bayes Sat, 13 Jan 2007 01:11:00 GMT

Ali and I were just working on our super-secret project that’s written using Flex 2 and we came across a pretty surprising problem.

We have a DataGrid that slides out of the way and back again. If the application is compiled on his machine, the DataGrid header disappears after being collapsed to less than 2 pixels of width, while it works fine when compiled on my machine.

We finally figured out that he has installed Flex Builder 2.0.1 while I’m still on the good old Flex Builder 2.0… Looks like some kind of fun injection!

Essentially the rule is that if you’re using the latest Flex Builder build (2.0.1), don’t ever let your DataGrids get smaller than 2 pixels wide.

Read more...

Tags , , ,  | 7 comments

No Try..Catch from EventDispatchers in ActionScript 3.0?

Posted by: Luke Bayes Tue, 17 Oct 2006 20:59:00 GMT

Wow…

I was just doing some work on event handling with AsUnit 3.x and discovered something pretty strange. It seems that if an event handler throws an exception, there is no way to catch it from the initiating thread. For some reason, if an exception makes it to the EventDispatcher, it just passes right through all encountered catch/finally blocks and goes right up to the player as an uncaught exception.

Just copy the following code into a new ActionScript project in FlexBuilder and make it your default application to see this in action:

package {
    import flash.display.Sprite;
    import flash.errors.IllegalOperationError;
    import flash.events.Event;
    import flash.events.EventDispatcher;
    import flash.events.IEventDispatcher;

    public class EventDispatcherTest extends Sprite {

        private var dispatcher:IEventDispatcher;

        public function EventDispatcherTest() {
            runTests();
        }

        public function runTests():void {
            dispatcher = new EventDispatcher();
            dispatcher.addEventListener(Event.CHANGE, someHandler);
            try {
                // Uncomment this line to see the catch work...
                //someHandler(new Event(Event.CHANGE));
                dispatcher.dispatchEvent(new Event(Event.CHANGE));
            }
            catch(error:*) {
                trace("Exception has been caught!");
            }
        }

        private function someHandler(event:Event):void {
            trace("someHandler called");
            throw new IllegalOperationError("AnyException");
        }
    }
}

This will throw an exception up to the player with a call stack that looks like this:

Error: AnyException
    at EventDispatcherTest/EventDispatcherTest::someHandler()[...EventDispatcherTest\EventDispatcherTest.as:31]
    at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
    at flash.events::EventDispatcher/dispatchEvent()
    at EventDispatcherTest/runTests()[...EventDispatcherTest\EventDispatcherTest.as:22]
    at EventDispatcherTest$iinit()[...EventDispatcherTest\EventDispatcherTest.as:13]

You can see from the call stack that the exception actually passed through the “runTests” method – but didn’t get caught!

I’m really not sure what to make of this, but I think we’re about to have to roll our own event management!

Those of you using AsUnit 3.x should know that because of this issue, the old recommended way of testing event handlers in AS 2 by throwing an “AssertionPassedError” won’t work in AS 3.

Anyone else run into this? Perhaps there is something simple that we can do differently to avoid this behavior?

Tags , ,  | no comments

AS3 Bug When Nesting 'if' Within 'switch'

Posted by: Ali Mills Tue, 29 Aug 2006 05:33:00 GMT

Luke and I ran into an ActionScript 3.0 bug today when nesting an if statement within a switch. It looks like the compiler has problems referencing object properties when this happens. The following code demonstrates what we found:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
package {
    import flash.display.Sprite;

    public class SwitchBug extends Sprite {
        public function SwitchBug() {
            var num:Number = 1;
            var firstNumber:Number = num;
            var secondNumber:Number = num;
            tryNumSwitch("go", firstNumber, secondNumber);

            var now:Date = new Date();
            var firstDate:Date = now;
            var secondDate:Date = now;
            tryDateSwitch("go", firstDate, secondDate);            

            // this method causes a crash
            tryCrashingDateSwitch("go", firstDate, secondDate);
        }

        private function tryNumSwitch(val:String, firstNumber:Number, secondNumber:Number):void {
            switch(val) {
                case "go":
                    if(firstNumber == secondNumber) {
                        trace(">> tryNumSwitch successful !!");
                    }
            }
        }

        private function tryDateSwitch(val:String, firstDate:Date, secondDate:Date):void {
            switch(val) {
                case "go":
                    if(firstDate == secondDate) {
                        trace(">> tryDateSwitch successful !!");
                    }
            }
        }

        private function tryCrashingDateSwitch(val:String, firstDate:Date, secondDate:Date):void {
            switch(val) {
                case "go":
                    // the compiler crashes on DATE.milliseconds call
                    if(firstDate.milliseconds == secondDate.milliseconds) {
                        trace(">> tryCrashingDateSwitch successful !!");
                    }
                    // uncommenting the trace below fixes the situation
//                    trace("Fixed");
            }
        }
    }
}

Oddly, adding a trace (or any line of code) after the if statement fixes the issue.

Tags ,  | 2 comments