Hi,
I have checked the source code, and the bug is in
DropDownController.systemManager_mouseDownHandler(), which makes an incorrect
assumption.
It assumes that if a mouse down occurs OUTSIDE of the callout, then the callout
should be closed.
This is true, unless the mouse down occurs INSIDE ANOTHER Callout, in which
case, it should be ignored.
See code below.
What do you think ?
/**
* @private
* Called when the systemManager receives a mouseDown event. This closes
* the dropDown if the target is outside of the dropDown.
*/
mx_internal function systemManager_mouseDownHandler(event:Event):void
{
// stop here if mouse was down from being down on the open button
if (mouseIsDown)
{
mouseIsDown = false;
return;
}
if (!dropDown ||
(dropDown &&
(event.target == dropDown
|| (dropDown is DisplayObjectContainer &&
!DisplayObjectContainer(dropDown).contains(DisplayObject(event.target))))))
{
-----Message d'origine-----
De : Carlos Velasco [mailto:carlos.velasco.bla...@gmail.com]
Envoyé : mercredi 18 septembre 2013 10:31
À : users@flex.apache.org
Objet : Re: Callout Buttons inside Callout Content
CalloutButton instances are to be closed using the closeDropDown() method which
is causing the problem. Calling it for one instance is closing all instances. I
think it was programmed that way thinking there would never be
2 CalloutButton instances opened at a time, but It really happens when you use
CalloutButtons inside the contents that are displayed when an instance of
CalloutButton is opened.
Should it be thought as a bug????
2013/9/17 Jerry Hamby <jerryha...@vdex.com>
> Carlos,
>
> This may or may not be of some help, but this is the way I control
> Callouts:
>
> I build a class to handle all opening and closing of callouts. I call
> it the "CalloutMaster".
> I create a property var to store the reference to each open callout,
> if you have 2 callouts open then you would have 2 separate properties
> for reference.
>
> example:
> public var pLoginCallout:Callout = new loginCallout; public var
> pSettingsCallout:Callout = new settingsCallout;
>
> I then can kill one or both of the reference at a time.
>
> CalloutMaster.getInstance().mKillLoginCallout();
>
> public function mKillLoginCallout():void{
> if(pLoginCallout){
> pLoginCallout.close();
> pLoginCallout = null;
> }
> }
>
> There may be easier ways, but this works well as an overall callout
> control. This also works nicely if you are dealing with mobile devices
> and need to handle the closing or resizing during a orientation
> change.
>
> Jerry
>
>
> On Sep 17, 2013, at 4:09 AM, Carlos Velasco wrote:
>
> > When using a callout button inside the callout content of a
> > different callout button I am having an undesired effect.
> >
> > Calling the dropdown method of the child callout button (the one
> > placed
> at
> > the callout content) is closing its callout content (as desired) but
> > also closing the parents callout content.
> >
> > Is there a way of avoiding that behaviour?
> >
> > Thanks in advance.
> > Carlos.
>
>
>
