Is there a way to detect when the parent of a control is about to
change? I am aware of the ParentChanged event but that happens too
late. I don't see any ParentChanging event.
Thanks,
Mike
Just what is causing the parent to change?
Is there a way to detect when the parent of a control is about to
change? I am aware of the ParentChanged event but that happens too
late. I don't see any ParentChanging event.
Am 22.01.2010 16:52, schrieb Mike:
Why exactly does it happen too late? What do you want to achieve?
There is some clean up work that I need to do before the control is
removed. If I wait for the ParentChanged event, the parent will be
null and I get errors.
Mike said:There is some clean up work that I need to do before the control is
removed. If I wait for the ParentChanged event, the parent will be
null and I get errors.
If the control is being removed by code, then can't the code that
removes it then perform the cleanup?- Hide quoted text -
- Show quoted text -
AFAIK, you can't get the notification you want.
Without more specifics, it's unclear as to what details you have that
are dependent on the parent, nor why you're not able to rely on the code
that is actually changing the parent. These may or may not be design
problems.
But purely from the practical side of things, it seems that you will
need to retain a reference to the parent control elsewhere, so that you
still have access to it after the Parent property changes.
Pete- Hide quoted text -
- Show quoted text -
Mike said:Saving the property elsewhere does not solve my problem since the
object that looks for the parent is in a 3rd party assembly.
Anyway,
thanks for the answer to the original question. I will have to see if
I can find a different approach.
That makes little sense to me. _Whatever_ the code that "looks for the
parent", that would be the code that would save the old value. No
matter where that code is, it can do it.
Well, I strongly suspect that you've got a more fundamental design
problem. So my advice would be to look more carefully at whatever
strategy you're trying to implement now, to try to identify a simpler,
more conforming approach that would work better.
My experience has been, when I find that the API or framework I'm using
doesn't support some specific usage scenario I'm trying to implement,
it's usually because whatever design I've come up with that requires
that usage scenario is flawed.
Pete
Mike said:It doesn't make sense to you that I can't change the code in a 3rd
party assembly? Can you explain how to change code that you don't have?
No. What doesn't make sense to me is that the 3rd party assembly would
have this requirement, and yet it should somehow expect the problem to
be solved in your own code.
Frankly, there's been so little actual information given regarding the
design that you seem to be trying to implement, even the basic
requirement that you need to know about the change of parent before it
happens is left unjustified, and as I said most likely represents a
design flaw, rather than something that really needs to be addressed.
But inasmuch as _some_ code seems to think it needs to know the old
parent when the parent has been changed, _that_ is the code where you
would keep the old parent. It's not like even if you could detect the
incipient change of parent in your own control that that would somehow
fix the third-party code to which you refer. If that third-party code
needs to know about the incipient change, it would have to be modified
to address that.
Just as you appear to be incredulous that I don't understand that you
can't change the code in a third-party assembly, I am incredulous that
you seem to think you can solve a problem found in code in a third-party
assembly by changing code in your own assembly.
Frankly, it's likely that both of us simply don't understand what the
other is talking about. In my case, I have an excuse: you haven't
actually posting anything even approximating a concise-but-complete code
example that illustrates the actual problem. It's not possible for me
to fully comprehend the problem you're trying solve without a much more
complete and precise description of the problem.
As long as you insist on simply stating your own chosen implementation
specifics, rather than the overall problem, the best any of us can do is
point out that no, there's nothing in the Control class that would
automatically notify you when the parent of a Control instance is
_about_ to change.
There are LOTS of ways you could know that information, either before or
after the change of parent, if you are the owner of the code for the
control for which the parent is changing, or if you are the owner of the
code that cares about the old value of the parent. Otherwise, you're
probably out of luck.
And in any case, I stand by my previous assertion that the fact that you
are trying to do something that is according to you apparently
impossible, strongly suggests you have a more fundamental design problem
that needs fixing. Not everyone is well-suited to hearing that kind of
advice, and I apologize if you're one of those people. But that's the
advice that seems most useful from where I'm sitting.
Pete
I apologize in advance if I've missed something, I'm a little fuzzy on what
the problem is here. I'm not sure if the control being removed from the form
is your code, or if you need for your control to know when its components
are begin removed. I readily admit that late on Friday my brain may not be
functioning on all cylinders. :-D
In the first case, could your cleanup code go into your destructor function
for the control, or could you implement a Dispose method? Those are goingto
be called for a control being removed from a form. I'm wondering if it's
possible to get your clean up done without having to know specifically that
(or if or when) the control is coming off the form.
If your own control needs to know when a control in its control collection
is being added or removed, one option would be to create a class that
inherits from Control.ControlCollection, which shadows the Add and Remove
methods, adding event calls. Another class could be created that inherits
from Control, which shadows the Controls property with an instance of the
new class, rather than the standard one. Finally, your control could be
written to inherit from this new Control class, rather than the standard
one.
Sometimes I find that it helps to redefine the problem; maybe there's some
other way to accomplish the ultimate goal.
On Jan 22, 4:00=A0pm, Peter Duniho <[email protected]>
wrote:
Well, if you read my original post you will notice I was not asking
anyone to resolve my overall situation. I asked a simple question and,
as usual, people kept asking "why ya wanna do that?" instead of
answering the question. This forced me to provide more details but I
didn't want to sit here writing a 2-mile long post explaining every
detail of the problem. I don't mind people trying to provide extra
help. What I mind is when people assume your approach must be wrong
and don't even address your question.