>> So it was correct to initialize members in the "attach"
>> method and null them in the "detach" method?
Well, it's not incorrect. The Attach() and Detach() virtuals
are just formal means of getting notified when the instance
is associated with a document, and before it becomes disassociated. The constructor is usually the
place where you do initialization, and you can do that
in this case too as long as it isn't dependent on the
document. Read the comments.
There's really no etched-in-stone rules for using a class
like that. I wrote it because I needed a simple, reusable
solution for what the counterpart ArxWizard-generated
code does in C++.
So rather than taking it literally, consider it as merely
one example of how you might go about rolling your
own solution.
>> Do not the majority of .net programmers have to deal
>> with this issue?
Yea, but if they can't implement their own solution
for something as simple as this, they're going be
hitting lots of walls. The ObjectARX wizard was not
intended to be a crutch that compensates for a lack
of general programming skills or API knowlege.
There's nothing mystical about the class I pointed
you to, it's just a home-grown solution to a more
common problem.
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com
"perry"
wrote in message news:5140799@discussion.autodesk.com...
Tony Tanzillo wrote:
> Right - You add non-static members to your derived
> class, and by doing so you have different copies of
> them for each document.
>
> The DocData() members are just analogs to the ARX
> counterpart (AcApDataManager), and the one that
> takes no arguments is another way of referencing the
> ActiveDocData property.
>
> One caveat about this class that I didn't mention,
> is that because it uses static members to manage
> the per-document instances, you can't derive and
> use more than one class from it.
>
> To do that, you would need to make it more like
> the ARX counterpart (or use generics in .NET 2.0).
>