Two ways to programmatically work with a combobox, and still use the change event handler

The project I’m working on required that we have two drop downs, and that they be preselected to the first option.

Sounds good, except that one of the drop downs had a ‘change’ event handler, that would do ‘some stuff’ based on the selection. Obviously just selecting the first item wasn’t a very good solution, if the changes that should take place as a result of that selection didn’t happen.

I tapped Sim, and Tom, since I couldn’t come up with a solution on my own. I looked high and low, near and far, even under a rock or two.

Sim thought it should just work, and even quoted me some doc sentences. Tom didn’t understand my question at first. in the end we ended up with two options, both of which work fine.

This first on is Sim’s solution.

private function onShow():void
{

    listOfSavedSchedules.selectedIndex = 0;
    weekSelecter.selectedIndex = 0;
    var e:ListEvent = new ListEvent(ListEvent.CHANGE);
    e.rowIndex = 1;
    listOfSavedSchedules.dispatchEvent(e);

}

This block of code is in an onShow function which is dispatched each time my visual component is displayed in the app. My first try was to simply change the selectedIndex, that’s not enough, more on that later. What we’re doing is  creating a listEvent (which is what my handler is looking for), setting the rowindex, then firing the ListEvent. When this ListEvent is fired, it is picked up by my ‘change’ handler (below)

private function selectNewSavedSchedule(e:ListEvent):void
{
                var loadThisSchedule:GetSavedScheduleXMLEvent = new GetSavedScheduleXMLEvent(listOfSavedSchedules.selectedItem as SavedScheduleVO);
               
                //we’ll put this ID into a global for this screen, so if they want to delete, we know
                //what they selected.
                selectedSavedScheduleID = loadThisSchedule.savedScedule.savedScheduleID;
               
                CairngormEventDispatcher.getInstance().dispatchEvent(loadThisSchedule);
}

As you can see, the handler isn’t actually interested in the ListEvent, I’m looking into the comboBox for it’s selectedIndex. However I can’t get into the ‘change’ handler without dispatching a change event. So that first work around, solves my problem.

 

Tom had a different idea. I’m not sure I like it as much, but it’s straightforward. I’ll explain my thoughts on the approach shortly, but first the approach itself.

private function onShow():void
{
            selectNewSavedSchedule();
}   

So that’s my onShow again, this time it’s just calling my handler directly, wha? All that’s required is one change to my handler.

private function selectNewSavedSchedule(e:ListEvent = null):void
{
                var loadThisSchedule:GetSavedScheduleXMLEvent = new GetSavedScheduleXMLEvent(listOfSavedSchedules.selectedItem as SavedScheduleVO);
               
                //we’ll put this ID into a global for this screen, so if they want to delete, we know
                //what they selected.
                selectedSavedScheduleID = loadThisSchedule.savedScedule.savedScheduleID;
               
                CairngormEventDispatcher.getInstance().dispatchEvent(loadThisSchedule);
}

The diference? it’s in bold, see it? By telling the method that e can be null, my handler doesn’t care if it receives a ListEvent. So my handler now serves two purposes.

So why don’t I like this last approach? Mainly because it’s less clear. My handler is now forced to never be able to actually rely on looking at ‘e’. I can’t rely on e.currentTarget, etc because e might not exist. Also any changes will need to work with both use cases.

6 thoughts on “Two ways to programmatically work with a combobox, and still use the change event handler

  1. Tom Ortega Post author

    Ahh..but you see. The only reason I suggested it was because you "weren’t" looking at the event. :)

    Obviously if your working with the event, that would be very dangerous and not a nice way to go.

    If you want to plan for the future, then I’d say create a separate function from the handler. One that excutes when that value changes, than call that function from the show and handler function. This way, your event logic never mixes with the change logic.

    1. Cyril

      Creating and firing change events might trigger something else elsewhere, and from documentation change event fire on USER interaction. So I prefer Tom's solution. Except that having a method that receive an event.. or not.. is, as you said, less clear, and might be source of error.

      Apply a bit of refactoring:
      first you should name your handlers "handleXxx" or "onXxx"
      private function onNewSavedScheduleSelection(e:ListEvent):void
      {
      var listFiringTheEvent:ListBase = ListBase(e.target);
      selectNewSavedSchedule( listFiringTheEvent.selectedItem);
      }

      private function selectNewSavedSchedule( selectedSchedule:SavedScheduleVO):void
      {
      your actual code…
      }

      onShow() can now set selectedItem and call selectNewSavedSchedule.

  2. Tom Ortega

    Ahh..but you see. The only reason I suggested it was because you "weren't" looking at the event. :)

    Obviously if your working with the event, that would be very dangerous and not a nice way to go.

    If you want to plan for the future, then I'd say create a separate function from the handler. One that excutes when that value changes, than call that function from the show and handler function. This way, your event logic never mixes with the change logic.

Comments are closed.