Dynamic properties in Properties Palette
James
Does anyone have a clue how to use the Dynamic Property Wizard in ObjectARX
2004/5? It seems you can only use it in an ARX project, not with a COM
wrapper in DBX, but even so I can't figure out how to connect things up. I
have been forced into implementing a COM wrapper in my ARX project, and
managed to get static properties working. I then added a DynamicEnumProperty
property class which builds, but the ARX fails to load. It always fails to
find any non-NULL entries in the property map. Does anyone know how this map
might be set up?
TIA
James Dellar
Cyrille Fauvel
In ARX 2004 there is a defect in the dyn prop manager class header. This is
fixed in the ARX 2005 SDK, and the file is compatible with 2004. Copy the
'dynpropmgr.h' from 2005 into the inc folder of your 2004 SDK, and that will
solve this defect.
Now Dynamic properties are only available in AutoCAD. This is why the
Wizards won't let you add a dynamic properties interface class into a .dbx
Object Enabler Application. Said that, make sure to load the .dbx
application first and then load the .arx. If you forgot to load the .DBX
application first and if Windows is not able to find your .dbx application
in its search path, the .arx application (which is a DLL) will not load into
memory.
Hope that helps,
cheers
cyrille
"James" <ja...@reel.co.uk> wrote in message news:405887c6_1@newsprd01...
James
OK, if I should only use the dynamic properties in AutoCAD, how do I go
about creating them for a DBX module that I have. Should I make a COM
wrapper for the module in the module itself (using the Wizard) and then
implement the dynamic properties in my ARX app, or implement the whole lot
in the ARX app, or even try to get the dynamic props working in DBX. The
White Paper entitled Dynamic Propeties, and the SimpleDynProps sample both
skirt the issue by starting off with everything in the ARX app. The other
COM samples only use static properties, of course.
I started off by separating my entities from my app by putting them into DBX
modules, but it now seeps that I have made things very hard for myself. Is
there a (relatively) simple way out?
TIA.
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:405b6c16$1_2@newsprd01...
Cyrille Fauvel
This is more a design issue rather than an implementation issue. Since the
time AutoCAD was objectified and ObjectDBX DLLs were made available, any
product built on top of the ObjectDBX SDK (ObjectDBX Host Application) can
read/write DWG files, and may load Object Enabler Application (.dbx) to work
with custom objects implemented in them.
If you write a custom object, Autodesk recommends to implement that custom
object into a .dbx application because then all host applications can work
with your real entity rather than working with a proxy object. This is
especially important for application trying to render a drawing for example.
In order to create such Object Enabler Application, you should make sure
that the .dbx is not dependant of AutoCAD in any way. If it is dependant of
AutoCAD then it won't load in any other host application and therefore it
isn't a .dbx but an ObjectARX application.
So you should always prefer to create custom object in an Object Enabler
Application (.dbx), but it is just a recommendation. If you really don't
like making your application modular, then you can choose implementing your
custom object in an .arx application (and then stucked to AutoCAD only). The
Wizards allows this, it just warn you will you try to create them in an .arx
application.
Now static properties are implemented into a COM interface for your custom
object. Again you have 2 options you can choose for your implementation. One
is to create this COM interface into the .dbx application directely. The 2nd
is to make it into a separate DLL (or an .ARX). If you choose the first
option, then your COM server and Object Enabler Application would be resume
into the same module, and the COM interface would be always available when
you .dbx module is loaded. If you choose the 2nd, then the COM server will
be dependant on your .dbx application, and will load into the host
application on request. Making your COM server non AutoCAD dependant would
let you load the COM server into any host application as well. So a 3D
Studio MAX script for example could automate your object via its COM
interface.
So the question is now what about dynamic properties? Dynamic properties are
dependant of AutoCAD. Therefore they have to be implemented in an ARX, and
can't go into a true .dbx. The Wizards won't let you do this to not break
your design. If you implement them in a .dbx, you aren't a true .dbx
anymore, you are a .arx. Options here are to create a second COM server for
just the Dynamic Properties. Or to move all the COM stuff into the same
module. It is really a design choice you have to make.
In any case, you will have at least 2 modules.
- a .dbx for the Object Enabler + COM static properties
- a .arx for commands to act on your custom object + COM static properties
Another option is to have 3 modules.
- a .dbx for the Object Enabler
- a .arx for commands to act on your custom object
- another .arx for COM static properties + COM static properties
Another one is to have all in 1 .arx
As you see, it is really a design choice for your application
implementation. My personal choice (and that's only my preferences) would
be:
- a .dbx for the Object Enabler + COM static properties
- a .arx for commands to act on your custom object + COM static properties
Finally, in your specific situation where you do not want to provide static
properties, I would stick to:
- a .dbx for the Object Enabler
- a .arx for commands to act on your custom object + COM static properties
then your .arx would be dependant of you .dbx application.
For sure you can do all in one .arx, that would be your choice and as long
you know what that means it is fine
Hope that helps,
cheers
cyrille
"James" <ja...@reel.co.uk> wrote in message news:405ef4d7_3@newsprd01...
James
Thank very much for a complete answer, and the reasons why things are as
they are. It was very helpful. Perhaps this information should go into the
developer guide or a white paper on ADN, or something? I saw that somebody
else in this group had trouble with the Dynamic Property wizard a while ago,
but there were no follow-up posts, so I am probably not alone with this
situation.
For your information, I have decided to go with .dbx and COM in one module
for static properties, and application with dynamic properties in the .arx
module.
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:405f5f72_2@newsprd01...
James
always get an exception in the AcRxDynPropManager because the first
_OPM_DYNPROP_ENTRY has that has *ppEntry != NULL (which is for my dynamic
property) has strCmd, strClass and pProp all set to NULL. This is called
from the application On_kInitAppMsg. If I continue, On_kInitAppMsg gets
called again, but this time it succeeds, and the dynamic property works in
default implementation. I have made sure that the macro
OPM_DYNPROP_OBJECT_ENTRY_AUTO is called and I have tried to ensure that the
dbx modules are loaded before the InitAppMsg is processed (see code below).
I have even tried applying my dynamic property to the asdkBolt class from
the palettes sample, with the same result. I am now using the ObjectARX 2005
libraries and include files, due to the fault noted in dynpropmgr.h of 2004.
This one is beginning to get on my nerves.
James Dellar.
class CMyApp : public AcRxArxApp {
public:
CMyApp () : AcRxArxApp () { }
virtual AcRx:::AppRetCode On_kInitAppMsg (void *pkt) {
bool bOk = acrxDynamicLinker->loadModule("MyDbx.dbx", true);
// bOk is true at this point
// Assertion on during line below
AcRx::AppRetCode = AcRxApp::On_kInitAppMsg (pkt) ;
CWnd* splashScreen = startSplashScreen();
// This was my original position for loading the dbx. The app failed every
// time because the module never god loaded
// bool bOk = acrxDynamicLinker->loadModule("MyDbx.dbx", true);
etc.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:405f5f72_2@newsprd01...
James
I was already using your updated dynpropmgr.h (the one from ObjectARX 2005)
with new macros in it, so it made no difference after a rebuild all.
I have been experimenting with very simple projects, and had success only
when the dynamic property works with AcDbLine or AcDbPolyline (ie standard
AutoCAD entities). I tried to use it with the asdkbolt class from the
palettes sample, the same failure. I also tried an AcDbEntity - derived
class in the ARX application, but still with the same result.
Please can you try using the wizards to produce the very simplest of dynamic
property applications that operates on the very simplest dbx module, just to
see if you can get it to work?
For the record, I am using a locked version of AutoCAD 2004 to test this.
Thanks for your help so far.
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:40607342_2@newsprd01...
> Hi James,
>
> Please use the attached file to build the application. Just put it in your
> ObjectARX inc folder and your application will run just fine. I thought I
> did send it already, but I seems I have forgotten.
>
> cheers
> cyrille
>
>
> "James" <ja...@reel.co.uk> wrote in message news:40604506_1@newsprd01...
James
As an experiment, I tried doing what the on-line help says, and used the
macro OMP_DYNPROP_OBJECT_ENTRY_AUTO twice with the same dynamic property,
but different AcDbEntity-derived classes. It would not compile due to
redefiition of the dynamic property class __pOpmObjMap_CDynProp. Surely
there is something wrong with this macro and/or the documentation?
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:40607342_2@newsprd01...
> Hi James,
>
> Please use the attached file to build the application. Just put it in your
> ObjectARX inc folder and your application will run just fine. I thought I
> did send it already, but I seems I have forgotten.
>
> cheers
> cyrille
>
>
> "James" <ja...@reel.co.uk> wrote in message news:40604506_1@newsprd01...
James
Thanks for the example. I think I am getting to the bottom of this now. I
remember that at first you said to load the dbx module first, then the arx,
and it should be OK. I misunderstood, and tried to use the
acrxDynamicLinker->loadModule() function to achieve this, but it seems it
does not. Your app behaves exactly as mine, ie Exception when you first try
to load it, works OK the second. Presumably there is something about the
loading of the DBX module that is different if loaded manually, instead of
by the dynamic linker. The result of the loadModule call always comes back
true though.
Any thoughts, or a better (programmatic) way to get the DBX loaded before
the dynPropManager does its stuff?
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:4061b82a_1@newsprd01...
> Hi James,
>
> Recently I have been involved in large application having even more
complex
> structure and all was working fine. The only problem I noticed was that I
> was getting 2 exceptions in the debugger when AutoCAD was exiting if the
> Property Palette Window was opened. But this is not due to the
application,
> but to a known defect in AutoCAD 2004.
>
> However, I rewrote a quick sample to demonstrate it. Load the DBX, then
load
> the ARX, and all should be fine.
>
> Cheers
> cyrille
>
>
>
> "James" <ja...@reel.co.uk> wrote in message news:40618611_3@newsprd01...
Cyrille Fauvel
Oh I see. It is a complete different issue. Here you are hitting the OS
search path issue for dependencies. When you load the ARX application (and
remember an ARX is a DLL). Windows will try to find and load all its
dependencies (in our case the DBX which is also a DLL). If the dependencies
are not into the OS search path, then Windows will refuse to load your DLL
Normally Windows starts searching in the current directory, then in the
application directory, then in System32, and finally looks into its search
path. Putting the DBX anywhere in these folders will make Windows to find
it, but you still need to ARX-load it and calling
acrxDynamicLinker->loadModule() is the way to go. And yes you need to
arx-load it before anything.
Autodesk recommends to put the DBX Object enablers into the 'Autodesk
Shared' folder
I.e.: c:\Program Files\Common Files\Autodesk Shared
so all applications can find them. This is true for the shipping release.
For development, I usually use an acad.rx file which loads that stuff for me
in the correct order.
cheers
cyrille
"James" <ja...@reel.co.uk> wrote in message news:4061c3c6_3@newsprd01...
James
Now we are talking on the same wavelength, I have fixed my acad.rx file to
load the dbx modules first, and voila!, it all works perfectly. Thank you
very much for your efforts with this.
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:4061cbad_2@newsprd01...
James
Thanks, that seems to work OK.
James Dellar.
"Cyrille Fauvel" <cyri...@free.fr> wrote in message
news:40630246_2@newsprd01...
> Hi Again,
>
> You you found here is a defect. I'll submit a defect report to get it
fixed
> asap.
> Use the attached file to fix the problem in the meantime. Code fix if for
> 2004 and 2005
>
> cheers
> cyrille
>
>
> "James" <ja...@reel.co.uk> wrote in message news:4061b0be_2@newsprd01...
> > Hi Cyrille,
> >
> > As an experiment, I tried doing what the on-line help says, and used the
> > macro OMP_DYNPROP_OBJECT_ENTRY_AUTO twice with the same dynamic
property,
> > but different AcDbEntity-derived classes. It would not compile due to
> > redefiition of the dynamic property class __pOpmObjMap_CDynProp. Surely
> > there is something wrong with this macro and/or the documentation?
> >
> > James Dellar.
< SNIP >
>
>
>