You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by "Roger L. Whitcomb" <Ro...@actian.com> on 2011/12/02 19:15:12 UTC
Question about "previewSheetClose"
I need to implement a prompt in my Save As dialogs to confirm if you
want to overwrite an existing file. So, I try to add a
SheetStateListener and begin the prompt in there. That all works,
except that the FileBrowserSheet "rolls up" and then rolls back down
with the prompt showing on top of it. The reason it does that is that
my listener is now third in line. First is the FileBrowserSheet
listener which calls "super" (which is Sheet itself) which starts the
close transition and then it sets the selected file. So, my listener
actually gets called twice: once with the previous selected file (or
null) set and once with the correct file.
So, there are two ugly things:
1) Visually it doesn't look good to have the sheet go away and come back
with the overwrite prompt on it.
2) It is hard to code the logic in my listener to deal with being called
twice.
What I'm casting around for is a way to make my listener be the "first
in line" or have mine take precedence somehow without (necessarily)
having a lot of knowledge of Pivot internals since they may change over
time. I mean that I *could* remove any existing listeners from the list
and make mine the only one and have mine call the other ones if
appropriate, but that seems like a really bad practice, in general. So,
any thoughts as to what's the "right" way to handle this? I think
similar problems could potentially arise with other close/state
listeners as well, although the visual aspects are most clearly seen
with Sheet since it starts the rollaway transition in
"previewSheetClose".
Or am I missing something fundamental here? Thanks.
Roger Whitcomb
Architect, Engineering
Actian Corporation
roger.whitcomb@actian.com <ma...@actian.com>
PHONE +1 650.587.5596
FAX +1 650.587.5550
www.actian.com <http://www.actian.com>
<http://www.actian.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
RE: Question about "previewSheetClose"
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Yep, that does the trick. So, here is the new code in
TerraFileBrowserSkin.java in "previewSheetClose" (transferring to dev
list):
@Override
public Vote previewSheetClose(final Sheet sheet, final boolean
result) {
Vote vote;
if (result
&& !okButton.isEnabled()) {
vote = Vote.DENY;
} else {
if (result) {
updatingSelection = true;
FileBrowserSheet fileBrowserSheet =
(FileBrowserSheet)sheet;
FileBrowserSheet.Mode mode = fileBrowserSheet.getMode();
switch (mode) {
case OPEN:
case OPEN_MULTIPLE:
case SAVE_TO: {
fileBrowserSheet.setSelectedFiles(fileBrowser.getSelectedFiles());
break;
}
case SAVE_AS: {
String fileName = saveAsTextInput.getText();
File selectedFile = new File(fileName);
File parentFile = selectedFile.getParentFile();
if (parentFile == null) {
selectedFile = new
File(fileBrowser.getRootDirectory(), fileName);
} else {
if (parentFile.isAbsolute() ||
parentFile.getPath().startsWith(File.separator)) {
fileBrowserSheet.setRootDirectory(parentFile.getAbsoluteFile());
} else {
fileBrowserSheet.setRootDirectory(new
File(fileBrowser.getRootDirectory(), parentFile.getName()));
selectedFile = new
File(selectedFile.getName());
}
}
fileBrowserSheet.setSelectedFiles(new
ArrayList<File>(selectedFile));
break;
}
}
updatingSelection = false;
}
vote = super.previewSheetClose(sheet, result);
}
return vote;
}
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Roger L. Whitcomb [mailto:Roger.Whitcomb@actian.com]
Sent: Friday, December 02, 2011 3:26 PM
To: user@pivot.apache.org
Subject: RE: Question about "previewSheetClose"
The main problem now appears to be that in my listener the
FileBrowserSheet.getSelectedFile isn't correct when my
SheetStateListener gets called. Because the selected file isn't set
until AFTER the "previewSheetClose" Is called for all listeners. So, I
can't correctly do the "okay to overwrite" check because the correct
file isn't available. See the code in TerraFileBrowserSheetSkin.java at
line 261 and following. So, the skin calls "previewSheetClose" and only
if the Vote is APPROVE will it set the selected file in the embedded
FileBrowserSheet object. And it looks like there isn't an easy way to
determine what the selected file is (based on the logic I just added to
the SAVE_AS case at line 287 and following.
So, I'm wondering if I can't rearrange the logic in "previewSheetClose"
in TerraFileBrowserSkin to set the selection if the okButton is enabled
and then call the "super.previewSheetClose" method, at which time I will
be able to accurately tell whether I want to DENY or not and everything
should work. It just seems wrong to expect that all the
"previewSheetClose" listeners could make an accurate determination if
the selected file isn't even set yet.
What do you think?
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Roger L. Whitcomb [mailto:Roger.Whitcomb@actian.com]
Sent: Friday, December 02, 2011 1:31 PM
To: user@pivot.apache.org
Subject: RE: Question about "previewSheetClose"
Hmm, interesting. When I return DENY, the first time it starts the
rollup and then brings it back down and the prompt shows up. If I
answer "No" to the overwrite prompt and click OK again, then the second
time and following times the rollup doesn't happen. So, let me try to
debug that. At any rate, it works better with DENY than with DEFER so
we're on the right track here. Thanks.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 1:03 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
I think the right thing to do is return DENY. If the sheet still rolls
up in that case, it is probably a bug in TerraSheetSkin.
On Dec 2, 2011, at 3:41 PM, Roger L. Whitcomb wrote:
No, I was returning DEFER. But, as I recall, even if I returned DENY
the rollup still happened. So, TerraFileBrowserSheetSkin registers
itself with a SheetStateListener, then my use of this class also
registers a SheetStateListener. So, when "close" is called, both
listeners get called. TerraFileBrowserSheetSkin gets called first,
which calls TerraSheetSkin via "super.previewSheetClose" (line 268),
which will start the close transition and return Vote.DEFER. Then my
listener gets called and will return DEFER (or DENY). Once the votes
are tallied, the non-APPROVE final vote cancels the close transition
(which has already started running) and then brings up my prompt.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 12:17 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
In your listener, are you vetoing the close event?
On Dec 2, 2011, at 1:15 PM, Roger L. Whitcomb wrote:
I need to implement a prompt in my Save As dialogs to confirm if you
want to overwrite an existing file. So, I try to add a
SheetStateListener and begin the prompt in there. That all works,
except that the FileBrowserSheet "rolls up" and then rolls back down
with the prompt showing on top of it. The reason it does that is that
my listener is now third in line. First is the FileBrowserSheet
listener which calls "super" (which is Sheet itself) which starts the
close transition and then it sets the selected file. So, my listener
actually gets called twice: once with the previous selected file (or
null) set and once with the correct file.
So, there are two ugly things:
1) Visually it doesn't look good to have the sheet go away and come back
with the overwrite prompt on it.
2) It is hard to code the logic in my listener to deal with being called
twice.
What I'm casting around for is a way to make my listener be the "first
in line" or have mine take precedence somehow without (necessarily)
having a lot of knowledge of Pivot internals since they may change over
time. I mean that I *could* remove any existing listeners from the list
and make mine the only one and have mine call the other ones if
appropriate, but that seems like a really bad practice, in general. So,
any thoughts as to what's the "right" way to handle this? I think
similar problems could potentially arise with other close/state
listeners as well, although the visual aspects are most clearly seen
with Sheet since it starts the rollaway transition in
"previewSheetClose".
Or am I missing something fundamental here? Thanks.
Roger Whitcomb
Architect, Engineering
Actian Corporation
roger.whitcomb@actian.com <ma...@actian.com>
PHONE +1 650.587.5596
FAX +1 650.587.5550
www.actian.com <http://www.actian.com>
<image001.jpg> <http://www.actian.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
RE: Question about "previewSheetClose"
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
The main problem now appears to be that in my listener the
FileBrowserSheet.getSelectedFile isn't correct when my
SheetStateListener gets called. Because the selected file isn't set
until AFTER the "previewSheetClose" Is called for all listeners. So, I
can't correctly do the "okay to overwrite" check because the correct
file isn't available. See the code in TerraFileBrowserSheetSkin.java at
line 261 and following. So, the skin calls "previewSheetClose" and only
if the Vote is APPROVE will it set the selected file in the embedded
FileBrowserSheet object. And it looks like there isn't an easy way to
determine what the selected file is (based on the logic I just added to
the SAVE_AS case at line 287 and following.
So, I'm wondering if I can't rearrange the logic in "previewSheetClose"
in TerraFileBrowserSkin to set the selection if the okButton is enabled
and then call the "super.previewSheetClose" method, at which time I will
be able to accurately tell whether I want to DENY or not and everything
should work. It just seems wrong to expect that all the
"previewSheetClose" listeners could make an accurate determination if
the selected file isn't even set yet.
What do you think?
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Roger L. Whitcomb [mailto:Roger.Whitcomb@actian.com]
Sent: Friday, December 02, 2011 1:31 PM
To: user@pivot.apache.org
Subject: RE: Question about "previewSheetClose"
Hmm, interesting. When I return DENY, the first time it starts the
rollup and then brings it back down and the prompt shows up. If I
answer "No" to the overwrite prompt and click OK again, then the second
time and following times the rollup doesn't happen. So, let me try to
debug that. At any rate, it works better with DENY than with DEFER so
we're on the right track here. Thanks.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 1:03 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
I think the right thing to do is return DENY. If the sheet still rolls
up in that case, it is probably a bug in TerraSheetSkin.
On Dec 2, 2011, at 3:41 PM, Roger L. Whitcomb wrote:
No, I was returning DEFER. But, as I recall, even if I returned DENY
the rollup still happened. So, TerraFileBrowserSheetSkin registers
itself with a SheetStateListener, then my use of this class also
registers a SheetStateListener. So, when "close" is called, both
listeners get called. TerraFileBrowserSheetSkin gets called first,
which calls TerraSheetSkin via "super.previewSheetClose" (line 268),
which will start the close transition and return Vote.DEFER. Then my
listener gets called and will return DEFER (or DENY). Once the votes
are tallied, the non-APPROVE final vote cancels the close transition
(which has already started running) and then brings up my prompt.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 12:17 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
In your listener, are you vetoing the close event?
On Dec 2, 2011, at 1:15 PM, Roger L. Whitcomb wrote:
I need to implement a prompt in my Save As dialogs to confirm if you
want to overwrite an existing file. So, I try to add a
SheetStateListener and begin the prompt in there. That all works,
except that the FileBrowserSheet "rolls up" and then rolls back down
with the prompt showing on top of it. The reason it does that is that
my listener is now third in line. First is the FileBrowserSheet
listener which calls "super" (which is Sheet itself) which starts the
close transition and then it sets the selected file. So, my listener
actually gets called twice: once with the previous selected file (or
null) set and once with the correct file.
So, there are two ugly things:
1) Visually it doesn't look good to have the sheet go away and come back
with the overwrite prompt on it.
2) It is hard to code the logic in my listener to deal with being called
twice.
What I'm casting around for is a way to make my listener be the "first
in line" or have mine take precedence somehow without (necessarily)
having a lot of knowledge of Pivot internals since they may change over
time. I mean that I *could* remove any existing listeners from the list
and make mine the only one and have mine call the other ones if
appropriate, but that seems like a really bad practice, in general. So,
any thoughts as to what's the "right" way to handle this? I think
similar problems could potentially arise with other close/state
listeners as well, although the visual aspects are most clearly seen
with Sheet since it starts the rollaway transition in
"previewSheetClose".
Or am I missing something fundamental here? Thanks.
Roger Whitcomb
Architect, Engineering
Actian Corporation
roger.whitcomb@actian.com <ma...@actian.com>
PHONE +1 650.587.5596
FAX +1 650.587.5550
www.actian.com <http://www.actian.com>
<image001.jpg> <http://www.actian.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
RE: Question about "previewSheetClose"
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Hmm, interesting. When I return DENY, the first time it starts the
rollup and then brings it back down and the prompt shows up. If I
answer "No" to the overwrite prompt and click OK again, then the second
time and following times the rollup doesn't happen. So, let me try to
debug that. At any rate, it works better with DENY than with DEFER so
we're on the right track here. Thanks.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 1:03 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
I think the right thing to do is return DENY. If the sheet still rolls
up in that case, it is probably a bug in TerraSheetSkin.
On Dec 2, 2011, at 3:41 PM, Roger L. Whitcomb wrote:
No, I was returning DEFER. But, as I recall, even if I returned DENY
the rollup still happened. So, TerraFileBrowserSheetSkin registers
itself with a SheetStateListener, then my use of this class also
registers a SheetStateListener. So, when "close" is called, both
listeners get called. TerraFileBrowserSheetSkin gets called first,
which calls TerraSheetSkin via "super.previewSheetClose" (line 268),
which will start the close transition and return Vote.DEFER. Then my
listener gets called and will return DEFER (or DENY). Once the votes
are tallied, the non-APPROVE final vote cancels the close transition
(which has already started running) and then brings up my prompt.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 12:17 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
In your listener, are you vetoing the close event?
On Dec 2, 2011, at 1:15 PM, Roger L. Whitcomb wrote:
I need to implement a prompt in my Save As dialogs to confirm if you
want to overwrite an existing file. So, I try to add a
SheetStateListener and begin the prompt in there. That all works,
except that the FileBrowserSheet "rolls up" and then rolls back down
with the prompt showing on top of it. The reason it does that is that
my listener is now third in line. First is the FileBrowserSheet
listener which calls "super" (which is Sheet itself) which starts the
close transition and then it sets the selected file. So, my listener
actually gets called twice: once with the previous selected file (or
null) set and once with the correct file.
So, there are two ugly things:
1) Visually it doesn't look good to have the sheet go away and come back
with the overwrite prompt on it.
2) It is hard to code the logic in my listener to deal with being called
twice.
What I'm casting around for is a way to make my listener be the "first
in line" or have mine take precedence somehow without (necessarily)
having a lot of knowledge of Pivot internals since they may change over
time. I mean that I *could* remove any existing listeners from the list
and make mine the only one and have mine call the other ones if
appropriate, but that seems like a really bad practice, in general. So,
any thoughts as to what's the "right" way to handle this? I think
similar problems could potentially arise with other close/state
listeners as well, although the visual aspects are most clearly seen
with Sheet since it starts the rollaway transition in
"previewSheetClose".
Or am I missing something fundamental here? Thanks.
Roger Whitcomb
Architect, Engineering
Actian Corporation
roger.whitcomb@actian.com <ma...@actian.com>
PHONE +1 650.587.5596
FAX +1 650.587.5550
www.actian.com <http://www.actian.com>
<image001.jpg> <http://www.actian.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
Re: Question about "previewSheetClose"
Posted by Greg Brown <gk...@verizon.net>.
I think the right thing to do is return DENY. If the sheet still rolls up in that case, it is probably a bug in TerraSheetSkin.
On Dec 2, 2011, at 3:41 PM, Roger L. Whitcomb wrote:
> No, I was returning DEFER. But, as I recall, even if I returned DENY the rollup still happened. So, TerraFileBrowserSheetSkin registers itself with a SheetStateListener, then my use of this class also registers a SheetStateListener. So, when “close” is called, both listeners get called. TerraFileBrowserSheetSkin gets called first, which calls TerraSheetSkin via “super.previewSheetClose” (line 268), which will start the close transition and return Vote.DEFER. Then my listener gets called and will return DEFER (or DENY). Once the votes are tallied, the non-APPROVE final vote cancels the close transition (which has already started running) and then brings up my prompt.
>
> Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com| Actian Corp. | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA | +1 650-587-5596 | fax: +1 650-587-5550
>
> From: Greg Brown [mailto:gk_brown@verizon.net]
> Sent: Friday, December 02, 2011 12:17 PM
> To: user@pivot.apache.org
> Subject: Re: Question about "previewSheetClose"
>
> In your listener, are you vetoing the close event?
>
> On Dec 2, 2011, at 1:15 PM, Roger L. Whitcomb wrote:
>
>
> I need to implement a prompt in my Save As dialogs to confirm if you want to overwrite an existing file. So, I try to add a SheetStateListener and begin the prompt in there. That all works, except that the FileBrowserSheet “rolls up” and then rolls back down with the prompt showing on top of it. The reason it does that is that my listener is now third in line. First is the FileBrowserSheet listener which calls “super” (which is Sheet itself) which starts the close transition and then it sets the selected file. So, my listener actually gets called twice: once with the previous selected file (or null) set and once with the correct file.
>
> So, there are two ugly things:
> 1) Visually it doesn’t look good to have the sheet go away and come back with the overwrite prompt on it.
> 2) It is hard to code the logic in my listener to deal with being called twice.
>
> What I’m casting around for is a way to make my listener be the “first in line” or have mine take precedence somehow without (necessarily) having a lot of knowledge of Pivot internals since they may change over time. I mean that I *could* remove any existing listeners from the list and make mine the only one and have mine call the other ones if appropriate, but that seems like a really bad practice, in general. So, any thoughts as to what’s the “right” way to handle this? I think similar problems could potentially arise with other close/state listeners as well, although the visual aspects are most clearly seen with Sheet since it starts the rollaway transition in “previewSheetClose”.
>
> Or am I missing something fundamental here? Thanks.
>
>
> Roger Whitcomb
> Architect, Engineering
> Actian Corporation
> roger.whitcomb@actian.com
>
> PHONE +1 650.587.5596
> FAX +1 650.587.5550
> www.actian.com
>
> <image001.jpg>
>
> This transmission is confidential and intended solely for the use of the recipient named above. It may contain confidential, proprietary, or legally privileged information. If you are not the intended recipient, you are hereby notified that any unauthorized review, use, disclosure or distribution is strictly prohibited. If you have received this transmission in error, please contact the sender by reply e-mail and delete the original transmission and all copies from your system.
>
>
RE: Question about "previewSheetClose"
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
No, I was returning DEFER. But, as I recall, even if I returned DENY
the rollup still happened. So, TerraFileBrowserSheetSkin registers
itself with a SheetStateListener, then my use of this class also
registers a SheetStateListener. So, when "close" is called, both
listeners get called. TerraFileBrowserSheetSkin gets called first,
which calls TerraSheetSkin via "super.previewSheetClose" (line 268),
which will start the close transition and return Vote.DEFER. Then my
listener gets called and will return DEFER (or DENY). Once the votes
are tallied, the non-APPROVE final vote cancels the close transition
(which has already started running) and then brings up my prompt.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com|
Actian Corp. <http://www.actian.com/> | 500 Arguello Street | Suite 200
| Redwood City | CA | 94063 | USA
<http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C
+Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67
7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1
650-587-5596 | fax: +1 650-587-5550
From: Greg Brown [mailto:gk_brown@verizon.net]
Sent: Friday, December 02, 2011 12:17 PM
To: user@pivot.apache.org
Subject: Re: Question about "previewSheetClose"
In your listener, are you vetoing the close event?
On Dec 2, 2011, at 1:15 PM, Roger L. Whitcomb wrote:
I need to implement a prompt in my Save As dialogs to confirm if you
want to overwrite an existing file. So, I try to add a
SheetStateListener and begin the prompt in there. That all works,
except that the FileBrowserSheet "rolls up" and then rolls back down
with the prompt showing on top of it. The reason it does that is that
my listener is now third in line. First is the FileBrowserSheet
listener which calls "super" (which is Sheet itself) which starts the
close transition and then it sets the selected file. So, my listener
actually gets called twice: once with the previous selected file (or
null) set and once with the correct file.
So, there are two ugly things:
1) Visually it doesn't look good to have the sheet go away and come back
with the overwrite prompt on it.
2) It is hard to code the logic in my listener to deal with being called
twice.
What I'm casting around for is a way to make my listener be the "first
in line" or have mine take precedence somehow without (necessarily)
having a lot of knowledge of Pivot internals since they may change over
time. I mean that I *could* remove any existing listeners from the list
and make mine the only one and have mine call the other ones if
appropriate, but that seems like a really bad practice, in general. So,
any thoughts as to what's the "right" way to handle this? I think
similar problems could potentially arise with other close/state
listeners as well, although the visual aspects are most clearly seen
with Sheet since it starts the rollaway transition in
"previewSheetClose".
Or am I missing something fundamental here? Thanks.
Roger Whitcomb
Architect, Engineering
Actian Corporation
roger.whitcomb@actian.com <ma...@actian.com>
PHONE +1 650.587.5596
FAX +1 650.587.5550
www.actian.com <http://www.actian.com>
<image001.jpg> <http://www.actian.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
Re: Question about "previewSheetClose"
Posted by Greg Brown <gk...@verizon.net>.
In your listener, are you vetoing the close event?
On Dec 2, 2011, at 1:15 PM, Roger L. Whitcomb wrote:
> I need to implement a prompt in my Save As dialogs to confirm if you want to overwrite an existing file. So, I try to add a SheetStateListener and begin the prompt in there. That all works, except that the FileBrowserSheet “rolls up” and then rolls back down with the prompt showing on top of it. The reason it does that is that my listener is now third in line. First is the FileBrowserSheet listener which calls “super” (which is Sheet itself) which starts the close transition and then it sets the selected file. So, my listener actually gets called twice: once with the previous selected file (or null) set and once with the correct file.
>
> So, there are two ugly things:
> 1) Visually it doesn’t look good to have the sheet go away and come back with the overwrite prompt on it.
> 2) It is hard to code the logic in my listener to deal with being called twice.
>
> What I’m casting around for is a way to make my listener be the “first in line” or have mine take precedence somehow without (necessarily) having a lot of knowledge of Pivot internals since they may change over time. I mean that I *could* remove any existing listeners from the list and make mine the only one and have mine call the other ones if appropriate, but that seems like a really bad practice, in general. So, any thoughts as to what’s the “right” way to handle this? I think similar problems could potentially arise with other close/state listeners as well, although the visual aspects are most clearly seen with Sheet since it starts the rollaway transition in “previewSheetClose”.
>
> Or am I missing something fundamental here? Thanks.
>
>
> Roger Whitcomb
> Architect, Engineering
> Actian Corporation
> roger.whitcomb@actian.com
>
> PHONE +1 650.587.5596
> FAX +1 650.587.5550
> www.actian.com
>
> <image001.jpg>
>
> This transmission is confidential and intended solely for the use of the recipient named above. It may contain confidential, proprietary, or legally privileged information. If you are not the intended recipient, you are hereby notified that any unauthorized review, use, disclosure or distribution is strictly prohibited. If you have received this transmission in error, please contact the sender by reply e-mail and delete the original transmission and all copies from your system.
>