I just notice that AbstarctContainer#insert has a TODO about this issue.
Page does not expose a removeControl currently so we throw the
exception. If we add a Page#removeControl
method we could remove the Control from the Page instead of throwing the
exception.
Still this won't resolve Ricardo's use case as the Button will be
removed from the Page and thus not be processed.
Bob Schellink wrote:
Hi Ricardo,
Think you should file a JIRA, we need to resolve this for 1.5 final.
The exception acts as a sanity check. For example if you add the
button to the
Form and Page, what should button#getParent return? Page or Form? So on
one hand having the exception helps protect against mistakes, and on
another
it removes flexibility.
In your case would it not be possible to create two separate buttons
instead?
They can both invoke the same listener.
kind regards
bob
Ricardo Lecheta wrote:
Hi all,
This exception breaks two of my applications.
I believe this doesn´t happen with click 1.4...
There are some use cases that is difficult to do with Click.
Let´s say I have a Form and Table.. In the table some "Edit" button.
When
the user clicks in the edit button
I need show a new button in the Form. This button must appears only
when the
user is editing the form.
And after that, the user can normally submit the form... or click in
this
new button.
If the user clicks in this button, it must call it´s listener method of
course.
But now I have a problem because it is not in the Form, since I´m in
other
request......
So I was used to let this kind of control as public,
so it is always added to the control list to be processed. But now if
I do
that click throws this exception.
This is a very difficult use case to do... is it possible to not
throw this
exception ?
regards,
