Thanks Maurice, I understood it that way. I asked because I don't know the procedure to raise bugs in order to get it resolved.
2013/9/18 Maurice Amsellem <maurice.amsel...@systar.com> > Yes, of course it needs a permanent fix (on DropDownController, see > previous mail). > > The workaround was just intended to help you while waiting for the fix. > > Regards, > > Maurice > > -----Message d'origine----- > De : Carlos Velasco [mailto:carlos.velasco.bla...@gmail.com] > Envoyé : mercredi 18 septembre 2013 13:05 > À : users@flex.apache.org > Objet : Re: Callout Buttons inside Callout Content > > I think this kind of stuff is to be resolved for future SDK releases > rather than letting anyone implement its own workaround, don't you agree? > > By the time, I will try the overriding suggestion and let you all know. > > > 2013/9/18 Maurice Amsellem <maurice.amsel...@systar.com> > > > Hi again, > > > > I have found a workaround: > > > > DropDownController has public variable called hitAreaAdditions that > > contains a list of DisplayObject to be excluded from triggering > > callout close. > > So you could just add CalloutButton2.callout to these hit areas when > > it's open, and remove it when it's closed. > > I have made a simple test, and it's working fine (when clicking Close > > button inside Callout2, only Callout2 is closed). > > > > Note: dropDownController is not accessible from CalloutButton, so you > > will have to override CalloutButton to make it public. > > > > WDYT ? > > > > Maurice > > > > -----Message d'origine----- > > De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] > > Envoyé : mercredi 18 septembre 2013 11:08 À : users@flex.apache.org > > Objet : RE: Callout Buttons inside Callout Content > > > > 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.orgObjet : 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. > > > > > > > > > > > >
