Mailing-List: contact users-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@flex.apache.org
Received-SPF: pass (nike.apache.org: domain of carlos.velasco.blanco@gmail.com
 designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <2095F5EBE04D59409DFCE91FFCEBF7AF3F524AFD@EXMBX05.netplexity.local>
References: 
 <CAEuyW4bYYAE1GbzJUpbWJ_8bWyqmw3j=iXyau-AyZFZzLavkkQ@mail.gmail.com>
	<535BAE27-DE4E-49DA-9D2F-018C387C59DF@vdex.com>
	<CAEuyW4baBJVdHnRYdrgrSE8aPbV_rr6SPYp1eKYVbt8x55iKLw@mail.gmail.com>
	<2095F5EBE04D59409DFCE91FFCEBF7AF3F5249DF@EXMBX05.netplexity.local>
	<2095F5EBE04D59409DFCE91FFCEBF7AF3F524A38@EXMBX05.netplexity.local>
	<CAEuyW4aw3podrzXnsPMKE3kwUpu=AOU00yEWzmnthduCV8zkAQ@mail.gmail.com>
	<2095F5EBE04D59409DFCE91FFCEBF7AF3F524AFD@EXMBX05.netplexity.local>
Date: Wed, 18 Sep 2013 13:32:37 +0200
Message-ID: 
 <CAEuyW4YkUDFSqQ627JsTpPGp1mTk-5afVPYiFo8-1GwWgdPc2w@mail.gmail.com>
Subject: Re: Callout Buttons inside Callout Content
From: Carlos Velasco <carlos.velasco.blanco@gmail.com>
To: "users@flex.apache.org" <users@flex.apache.org>
Content-Type: multipart/alternative; boundary=047d7b874c925535bc04e6a6cba5

--047d7b874c925535bc04e6a6cba5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=E9 : mercredi 18 septembre 2013 13:05
> =C0 : 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=E9 : mercredi 18 septembre 2013 11:08 =C0 : 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):vo=
id
> >     {
> >         // stop here if mouse was down from being down on the open butt=
on
> >         if (mouseIsDown)
> >         {
> >             mouseIsDown =3D false;
> >             return;
> >         }
> >
> >         if (!dropDown ||
> >             (dropDown &&
> >              (event.target =3D=3D dropDown
> >              || (dropDown is DisplayObjectContainer &&
> >
> >
>  !DisplayObjectContainer(dropDown).contains(DisplayObject(event.target)))=
)))
> >         {
> >
> > -----Message d'origine-----
> > De : Carlos Velasco [mailto:carlos.velasco.blanco@gmail.com]
> > Envoy=E9 : mercredi 18 septembre 2013 10:31 =C0 :
> > 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 =3D new loginCallout; public var
> > > pSettingsCallout:Callout =3D 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 =3D 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.
> > >
> > >
> > >
> >
>

--047d7b874c925535bc04e6a6cba5--