https://issues.apache.org/jira/browse/FLEX-33742
2013/9/18 Maurice Amsellem <[email protected]> > Go to https://issues.apache.org/jira/browse/FLEX , log in and raise a > ticket. > > Then post the ticket number on this thread. > > Regards, > > Maurice > > -----Message d'origine----- > De : Carlos Velasco [mailto:[email protected]] > Envoyé : mercredi 18 septembre 2013 13:33 > À : [email protected] > Objet : Re: Callout Buttons inside Callout Content > > 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 <[email protected]> > > > 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:[email protected]] > > Envoyé : mercredi 18 septembre 2013 13:05 À : [email protected] > > 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 <[email protected]> > > > > > 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:[email protected]] > > > Envoyé : mercredi 18 septembre 2013 11:08 À : [email protected] > > > 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:[email protected]] > > > Envoyé : mercredi 18 septembre 2013 10:31 À : > > > [email protected] : 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 <[email protected]> > > > > > > > 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. > > > > > > > > > > > > > > > > > >
