Prev: cannot send email
Next: Using SOAP Request in Application VB Express
From: Mike on 22 Jan 2010 15:45
On Jan 22, 3:17 pm, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> Mike wrote:
> > 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

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?
From: Peter Duniho on 22 Jan 2010 16:00
Mike wrote:
> 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
From: Mike on 22 Jan 2010 16:41
On Jan 22, 4:00 pm, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> Mike wrote:
> > 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

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.
From: Captain Jack on 22 Jan 2010 16:52
"Mike" <MLM450(a)hotmail.com> wrote in message
news:8a794be6-ebbe-495e-9315-986589b48897(a)m25g2000yqc.googlegroups.com...
>
> Any time the control is added to or removed from a control/form.

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 going to
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.

--
Jack


From: Mike on 22 Jan 2010 17:13
On Jan 22, 4:52 pm, "Captain Jack" <CaptainJack1...(a)comcast.net>
wrote:
> "Mike" <MLM...(a)hotmail.com> wrote in message
>
> news:8a794be6-ebbe-495e-9315-986589b48897(a)m25g2000yqc.googlegroups.com...
>
>
>
> > Any time the control is added to or removed from a control/form.
>
> 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 going to
> 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.
>
> --
> Jack

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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: cannot send email
Next: Using SOAP Request in Application VB Express