Flex and Flash Developer - Jesse Warden dot Kizz-ohm

A blog on software development, technology, games & movies.

About

This is the blog of Jesse Warden, a Rich Internet Application Architect. He specializes in using Flex and Flash to create Rich Internet Applications.

There’s a known issue with Alert’s in Flex, using the application level alert, or Alert.show. When you do:

function initApp()
{
        ref = Alert.show("test",
              "",
              Alert.OK,
              this,
              Delegate.create(this, onAlertClose),
              null,
              Alert.OK);
}

function onAlertClose()
{
        ref.deletePopUp();
}

The Alert’s background will stay around. In my investigations, he’s an mc in a very low negative depth. Removing him forcely messed up my app. Matt Chotin then recommended using a doLater. Upon doing so, it fixed my problem. I guess the invalidation routines co-chillin’ deep in the depths of UIObject remove the rect. ::shrugs::

At any rate, if you do this instead:

function onAlertClose()
{
        doLater(this, "killPopup");
}

function killPopup()
{
        ref.deletePopUp();
}

It works good.

Took me 3 days to work through that mess; here’s to you not having to do so.



3 Responses to “Flex Chronicles #5: Alert Drama”

  1. Thanks for writing these. I feel like I’m in the trenches w/ you as I’ve recently dove into the the sea of Flex development.

    What is the benefit of using that type of alert vs using alert(’My message’, ‘my title’);

    Joe Martinez

  2. The application level ‘alert’ function does 2 things differently than the static ’show’ function of the ‘Alert’ class:

    - first, and most important, it returns 0 upon success, some other number if it did not. This means that the only way to dismiss the alert is by user interaction. I need to have the option of dismissing the alerts via code, hence me using the Alert.show, which returns a reference to the alert created vs. an error code.
    - secondly, it removes the parent parameter, and swaps the icon and defaultButton parameter locations to be in a more programmer-friendly order

    JesterXL

  3. Good to know. Thanks.

    Joe Martinez

Leave a Reply