Author Topic: Deriving from AcDbPolyLine  (Read 6990 times)

0 Members and 1 Guest are viewing this topic.

pkohut

  • Guest
Re: Deriving from AcDbPolyLine
« Reply #15 on: March 25, 2009, 01:35:53 AM »
Good find Luis.  I couldn't put my finger on it yesterday when testing a custom DBX and
unloading it only to have the proxy graphics dialog pop up on the redraw.  I was trying
to think how AutoCAD could have caught that internally, but just couldn't come to
a good conclusion.  Since the sample Daniel provided is a part of an ARX app then
DLLIMPEXP = __declspec(dllimport).

Paul


After additional testing, it seems everything works just dandy as long as the Arx stays loaded in the session where the object is created.
Saving, Closing, etc. all work. As Paul said, itís probably something to do with the VTable.

There is a note every time you create a custom object added from the arxwizard.... for example:

Quote
#pragma once

#ifdef EZONEDBX_MODULE
#define DLLIMPEXP __declspec(dllexport)
#else
//----- Note: we don't use __declspec(dllimport) here, because of the
//----- "local vtable" problem with msvc. If you use __declspec(dllimport),
//----- then, when a client dll does a new on the class, the object's
//----- vtable pointer points to a vtable allocated in that client
//----- dll. If the client dll then passes the object to another dll,
//----- and the client dll is then unloaded, the vtable becomes invalid
//----- and any virtual calls on the object will access invalid memory.
//-----
//----- By not using __declspec(dllimport), we guarantee that the
//----- vtable is allocated in the server dll during the ctor and the
//----- client dll does not overwrite the vtable pointer after calling
//----- the ctor. And, since we expect the server dll to remain in
//----- memory indefinitely, there is no problem with vtables unexpectedly
//----- going away.
#define DLLIMPEXP
#endif



Thatís it, Thanks  Luis

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6934
  • AKA Daniel
Re: Deriving from AcDbPolyLine
« Reply #16 on: March 25, 2009, 01:38:35 AM »
I donít mind leaving my application loadedÖ in the end .. is this dangerous??  :laugh:

pkohut

  • Guest
Re: Deriving from AcDbPolyLine
« Reply #17 on: March 25, 2009, 01:56:42 AM »
I donít mind leaving my application loadedÖ in the end .. is this dangerous??  :laugh:

Nothing wrong with leaving it open and locked if that's what need to be done, but your
implementation has side effects. Your better to program the routine correctly.
#1 side effect is your object mutates on dwg filing from custom class to derived base class.
user would never know this is happening, but is this really a good thing?

Since you state you don't need a custom object but just wanted a special constructor, then
don't derived from AcDbEnity.  Make your own class that creates a new AcDbPolyilne
object and does any required work.  It's probably just as simple as what you've already
done and no side effects.

Paul

pkohut

  • Guest
Re: Deriving from AcDbPolyLine
« Reply #18 on: March 25, 2009, 02:23:44 AM »
I donít mind leaving my application loadedÖ in the end .. is this dangerous??  :laugh:

Let me add to that another way.  Scenario 1)  If the program went before a QA tester and
they filed a bug that said the application could not be unloaded you would then need to justify
the behavior or fix it.  In justifying the need to lock the application then the mutation side
effect is revealed.  QA tester would probably file a bug against that as well.

Scenario 2) Code is put up for code review with your peers and lead developer and they
were the ones to point out the mutation side effect and the application unload issue.
You would be asked to go back and fix it.  They might even be nice and give you a
quick lesson on design patterns and when to derive a new class on a base class, or just
create an instance of an object within a class and modify the objects properties.

Paul

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6934
  • AKA Daniel
Re: Deriving from AcDbPolyLine
« Reply #19 on: March 25, 2009, 03:30:29 AM »
Good points! Thanks Paul

Dan

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6934
  • AKA Daniel
Re: Deriving from AcDbPolyLine
« Reply #20 on: March 26, 2009, 09:04:25 PM »
FYI, you can declare the subclass with __declspec(novtable) and the ARX will unload properly, it seems to work very well.
However the use of this __declspec may cause problems if one needs to derive from the class again.
I decided just to make a wrapper with a conversion operator and see how that works.

Thatís one cool things about .NET, is that you can subclass any of the entity classes and in the end it still uses the underlying wrapper.

Chuck Gabriel

  • Guest
Re: Deriving from AcDbPolyLine
« Reply #21 on: March 27, 2009, 06:49:37 AM »
Isn't what you are doing the type of thing that protocol extensions are for?

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6934
  • AKA Daniel
Re: Deriving from AcDbPolyLine
« Reply #22 on: March 27, 2009, 09:38:15 AM »
Isn't what you are doing the type of thing that protocol extensions are for?

Thanks for the tip Chuck!

Iíve never heard about this before, Iíll need to study the docs on this.