MC++ property pointer to component

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

How does one specify in a component that a property is a pointer to another
component ? How is this different from a property that is actually an
embedded component ? Finally how is one notified in a component when another
component is destroyed ?

I have a managed component called P. Let us say that C is another managed
component. If on P I have:

__property C * get_CComp();
__property void set_CComp(C *);

Does this mean that my property is a pointer to CComp or does this mean that
my property is an actual CComp ? If the former, which seems like it should
be correct, how would I have a property which is an embedded CComp, since
CComp is a component which must be accessed through its pointer ? Or is is
that only __value classes can be embedded in a component and not another
__gc class ?

If CComp * is a pointer to a component, how I am notified if CComp is
destroyed, or is a moot point since as long as I hold a pointer to CComp it
is never destroyed by the GC ? If the latter is the case, I may still be
trying to use some functionality on CComp after it has been, let's say,
removed from a windows form. How does this effect my pointer, or does the
windows form container automatically set CComp back to 0 if that happens ?
 
Hi Edward,
How does one specify in a component that a property is a pointer to another
component ? How is this different from a property that is actually an
embedded component ?
Click to expand...

What do you understand by each of those sentences? Are you talking about
asociation versus composition? If so, why would both patterns be
distinguishable at the property level?
Finally how is one notified in a component when another
component is destroyed ?
Click to expand...

That depends on whether actual component containment (in the sense that the
..NET Framework Component model works) is actually taking place or not.
I have a managed component called P. Let us say that C is another managed
component. If on P I have:

__property C * get_CComp();
__property void set_CComp(C *);

Does this mean that my property is a pointer to CComp or does this mean that
my property is an actual CComp ?
Click to expand...

All it means is that it returns a reference to the actual object (let's
assume for now that we're only talking about reference types). No more, no
less.
If the former, which seems like it should
be correct, how would I have a property which is an embedded CComp, since
CComp is a component which must be accessed through its pointer ? Or is is
that only __value classes can be embedded in a component and not another
__gc class ?

If CComp * is a pointer to a component, how I am notified if CComp is
destroyed, or is a moot point since as long as I hold a pointer to CComp it
is never destroyed by the GC ?
Click to expand...

Yiou could hook them up through events, if you feel like it. However, let us
question another thing: What do you understand by "destroyed"? If you mean
just Garbage Collector, then the answer is: you don't know when it might be
collected. However, you are definitely assured that the CComp instance will
not be collected as long as your object is being referenced by a root
somewhere else.

I strongly suggest you look for the GC articles by Jeffrey Richter that
appeared a couple of years back in MSDN Magazine. Also, check out the use of
the IDisposable pattern/interface. And finally, make sure to clearly
separate the notion of referencing objects and containing components. Those
are two pretty different things, specially if you're talking .NET
 
Tomas said:
Hi Edward,


What do you understand by each of those sentences? Are you talking
about asociation versus composition? If so, why would both patterns be
distinguishable at the property level?
Click to expand...

I want to have a property which points to another component so that setting
the property in the Window Forms Designer means dropping the other component
on the form and then setting the property of my component to the instance of
the other component. My guess is that this means that my property is
OtherComponent * in MC++ which is equivalent to a reference in C#.

Now I want to have a property which is the other component itself, what I
call an embedded component if this is the correct term. Then when the user
goes to set my property, he is really setting the internal properties of the
embedded component However, components can only be created on the GC heap so
having a property of OtherComponent type appears impossible. I am guessing
that to have this sort of embedded component means that the type must really
be a value class and not a component, and in only this way am I able to
embed another class as a property.
That depends on whether actual component containment (in the sense
that the .NET Framework Component model works) is actually taking
place or not.


All it means is that it returns a reference to the actual object
(let's assume for now that we're only talking about reference types).
No more, no less.
Click to expand...

OK, understood. In the Windows Form Designer, therefore, the end-user could
only set the property to a separately instantiated object of CComp which has
been dropped on the form.
Yiou could hook them up through events, if you feel like it. However,
let us question another thing: What do you understand by "destroyed"?
If you mean just Garbage Collector, then the answer is: you don't
know when it might be collected. However, you are definitely assured
that the CComp instance will not be collected as long as your object
is being referenced by a root somewhere else.
Click to expand...

Here is the scenario. The user drops my component on a form. The user drops
another component on a form. the user sets my component pointer ( reference
in C# ) property to the other component. This sets my property's pointer to
the instance of the other component on the GC heap. Now the user removes the
other component from the form. What happens to my property ? Is my property
set function automatically called with a 0 pointer ?

Now the run-time scenario. The same as before but instead of removing the
other component from the form, the program calls delete on the other
component's instance. I know this means that the other component still
exists on the GC heap, but its destructor has been called effectively
rendering it "destroyed" for all practical purposes. What happens to my
component's property ? If it is not set back to 0, my component still thinks
that the other component is live and may attempt to call one of its methods
or access one of it properties.
I strongly suggest you look for the GC articles by Jeffrey Richter
that appeared a couple of years back in MSDN Magazine.
Click to expand...

Do you know what the year/month or for these. I can more easily find them
online if you do, else I will try to search under Richter's name if it is
possible. BTW Richter is the best writer on Microsoft technology ever IMHO.
Also, check
out the use of the IDisposable pattern/interface.
Click to expand...

I understandable IDisposable.
And finally, make
sure to clearly separate the notion of referencing objects and
containing components. Those are two pretty different things,
specially if you're talking .NET
Click to expand...

That is what I was trying to do with this question. I don't see how
components are contained, however, unless they are __value classes.
 
Back
Top