Re: Callout Buttons inside Callout Content
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.
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
> 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.
>
>
>
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.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
> 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.
>
>
>
RE: Callout Buttons inside Callout Content
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.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
> 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.
>
>
>
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
> 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
>
> > 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.
> >
> >
> >
>
RE: Callout Buttons inside Callout Content
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
> 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
>
> > 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.
> >
> >
> >
>
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
> 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
>
> > 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
> >
> > > 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.
>
RE: Callout Buttons inside Callout Content
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:carlos.velasco.bla...@gmail.com]
Envoyé : mercredi 18 septembre 2013 13:33
À : users@flex.apache.org
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
> 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
>
> > 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
> >
> > > 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 eac
Re: Callout Buttons inside Callout Content
https://issues.apache.org/jira/browse/FLEX-33742
2013/9/18 Maurice Amsellem
> 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:carlos.velasco.bla...@gmail.com]
> Envoyé : mercredi 18 septembre 2013 13:33
> À : users@flex.apache.org
> 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
>
> > 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
> >
> > > 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
