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.
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 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.
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 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.
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.
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 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.
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 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.
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 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
Re: Callout Buttons inside Callout Content
https://issues.apache.org/jira/browse/FLEX-33742
2013/9/18 Maurice Amsellem maurice.amsel...@systar.com
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 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
