| Undesired customizer buttons [message #90632] |
Wed, 11 May 2005 11:01  |
Eclipse User |
|
|
|
Originally posted by: no.ddress.here
The VE customizer support appears to be adding a button panel with OK
and Cancel buttons to the dialog window. Is there any way to turn this
behavior off?
In my experience, the automatic presentation of these controls is
unique. FWIW, section 9.3.1 of the spec does not require these buttons
and seems to suggest that appearance and function of a customizer, other
than appearing in a Dialog window, should be customizable ("The
customizer has complete discretion how it chooses to represent itself
....").
On a more practical level, the logic of my customizer is best supported
by Apply, Refresh, Close, and Cancel buttons, which my customizer code
provides. VE's addition of OK and Cancel buttons is confusing from a
user's point of view.
|
|
|
| Re: Undesired customizer buttons [message #90822 is a reply to message #90632] |
Thu, 12 May 2005 05:52  |
| Eclipse User |
|
|
|
Hi Gerald,
> The VE customizer support appears to be adding a button panel with OK
> and Cancel buttons to the dialog window. Is there any way to turn this
> behavior off?
The buttons should only be added if your customizer is a panel. If your
customizer is a window then we won't decorate it with our own window
(cause we don't need to) and your window can put whatever buttons you
want.
One problem if you do this is how you signal whether you have been
cancelled or not. With the Window we create we know what button was
pushed and can perform a cancel or apply the value, whereas if you have
your own buttons on your own window then we will have to assume that you
are responsible for performing any rollback you might want with a cancel.
Another thing to be wary of with customizers is how the VE knows what
has changed. We will take a snapshot of all properties when the
customizer is launched and get them all again when it is closed and then
compare. If a property has changed then we will generate the correct
code for the set method of that property. What this means is that to
get a myBean.setProperty(value) code gen'd you must actually provide a
new object for that property.
> In my experience, the automatic presentation of these controls is
> unique.
For our tests we compare ourselves against the reference implementation
of a tool as provided by the BeanBox. If we conform to this and the
rest of the tools don't then the spec should be changed.
> FWIW, section 9.3.1 of the spec does not require these buttons
> and seems to suggest that appearance and function of a customizer, other
> than appearing in a Dialog window, should be customizable ("The
> customizer has complete discretion how it chooses to represent itself
> ...").
But the spec allows a customizer to be just a panel. If it is just a
panel and has no buttons then should each customizer panel be
responsible for its own OK and Cancel buttons ? We took the decision
that panels get extra buttons and windows don't. What you have is a
panel with buttons and without sort of crawling the components tree on
your customizer to see it has buttons I can't see how we could determine
this.
> On a more practical level, the logic of my customizer is best supported
> by Apply, Refresh, Close, and Cancel buttons, which my customizer code
> provides. VE's addition of OK and Cancel buttons is confusing from a
> user's point of view.
Cool - make it subclass Dialog instead of Panel.
Best regards,
Joe
|
|
|
| Re: Undesired customizer buttons [message #607744 is a reply to message #90632] |
Thu, 12 May 2005 05:52 |
| Eclipse User |
|
|
|
Hi Gerald,
> The VE customizer support appears to be adding a button panel with OK
> and Cancel buttons to the dialog window. Is there any way to turn this
> behavior off?
The buttons should only be added if your customizer is a panel. If your
customizer is a window then we won't decorate it with our own window
(cause we don't need to) and your window can put whatever buttons you
want.
One problem if you do this is how you signal whether you have been
cancelled or not. With the Window we create we know what button was
pushed and can perform a cancel or apply the value, whereas if you have
your own buttons on your own window then we will have to assume that you
are responsible for performing any rollback you might want with a cancel.
Another thing to be wary of with customizers is how the VE knows what
has changed. We will take a snapshot of all properties when the
customizer is launched and get them all again when it is closed and then
compare. If a property has changed then we will generate the correct
code for the set method of that property. What this means is that to
get a myBean.setProperty(value) code gen'd you must actually provide a
new object for that property.
> In my experience, the automatic presentation of these controls is
> unique.
For our tests we compare ourselves against the reference implementation
of a tool as provided by the BeanBox. If we conform to this and the
rest of the tools don't then the spec should be changed.
> FWIW, section 9.3.1 of the spec does not require these buttons
> and seems to suggest that appearance and function of a customizer, other
> than appearing in a Dialog window, should be customizable ("The
> customizer has complete discretion how it chooses to represent itself
> ...").
But the spec allows a customizer to be just a panel. If it is just a
panel and has no buttons then should each customizer panel be
responsible for its own OK and Cancel buttons ? We took the decision
that panels get extra buttons and windows don't. What you have is a
panel with buttons and without sort of crawling the components tree on
your customizer to see it has buttons I can't see how we could determine
this.
> On a more practical level, the logic of my customizer is best supported
> by Apply, Refresh, Close, and Cancel buttons, which my customizer code
> provides. VE's addition of OK and Cancel buttons is confusing from a
> user's point of view.
Cool - make it subclass Dialog instead of Panel.
Best regards,
Joe
|
|
|
Powered by
FUDForum. Page generated in 0.04275 seconds
Home