flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Velasco <carlos.velasco.bla...@gmail.com>
Subject Re: Callout Buttons inside Callout Content
Date Wed, 18 Sep 2013 11:32:37 GMT
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.amsellem@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.blanco@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.amsellem@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.amsellem@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.blanco@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 <jerryhamby@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.
> > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message