Detecting when parent is about to change

[Mike]

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

 

[Joe Cool]

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?

 

[Mike]

Just what is causing the parent to change?

Any time the control is added to or removed from a control/form.

 

[Herfried K. Wagner [MVP]]

Am 22.01.2010 16:52, schrieb Mike:

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.

Why exactly does it happen too late? What do you want to achieve?

 

[Mike]

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.

 

[Joe Cool]

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?

 

[Peter Duniho]

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.

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

 

[Mike]

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 -

That would require that every person using my control needs to know to
do that. I'd much rather do something automated.

 

[Mike]

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 -

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.

 

[Peter Duniho]

Saving the property elsewhere does not solve my problem since the
object that looks for the parent is in a 3rd party assembly.

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.

Anyway,
thanks for the answer to the original question. I will have to see if
I can find a different approach.

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]

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

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?

 

[Peter Duniho]

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

 

[Mike]

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

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.

The bottom line is that I am dealing with a 3rd party product that
might have a crappy design (I don't know since I don't have the code).
I have contacted them about the problem and they offered a solution:
do the clean up before removing the control. I think that's inadequate
and I am still pursuing it but that's all I have from them right now.
I was simply trying to find a way to automate their suggested fix.

You may have been offended by my comment but look at what you wrote
again. You said you didn't understand why the code couldn't be changed
- wherever it is. If you were questioning the design of the 3rd party
product, it sure wasn't clear to me.

 

[Mike]

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.

Thanks for the input Jack. You’re right – Friday is not a good day to
tackle this. I think this is simply a buggy product I am dealing with.
But it is what it is and I need to deal with it.

You’re suggestion is pretty close to what I was trying to do
originally. My control includes this 3rd party control. My control is
dynamically added to and removed from other controls. In my Dispose, I
was calling my own clean up function but sometime after that I was
getting a null reference exception from within the 3rd party assembly.
I contacted the vendor and supplied a sample app. Their answer was to
remove the clean up call from my Dispose function and add it in the
code of my control’s user just before my control is removed. Sure
enough, if I do the clean up immediately before removal, all is well.
If I do the clean up immediately after the removal, the error arises.

 

[ozbear]

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.

<snip frustratration>

Mike, I feel your pain.
Sometimes we don't need a critique, all we need/want is a complete-
but-concise answer of "yes" or "no".

People that are unable to contain their unwanted dissections of
every nuance of a simple question make me tired.

Oz