Topic: Getting proxy entity’s information

[Kurtz David]

Hello,
I'm trying the write an AutoCAD App (Using Visual Basic .NET) that will drive attributes from proxy objects.
I have found the linked article in C# that does it but I can NOT translate it.
Any help on the issue or with the translation (\conversion) will be appreciated.

Thanks in advance,
David.

Link:
http://adndevblog.typepad.com/autocad/2012/08/getting-proxy-entitys-information.html

[Jeff H]

The code in link is C++ so probably why you are having problems

For converting C# to VB you can always use reflector, ILSpy or
http://www.developerfusion.com/tools/convert/csharp-to-vb/
http://converter.telerik.com/

If you need ProxyObjects information look at giles code here and convert it VB and modify as needed.
 
 

I do not have anything to test it on but just for ProxyEntities  and not does not look for ProxyObjects where you need to search the entire database.

Code - Visual Basic: [Select]

1.         <CommandMethod("PrintProxyInfo")> _
2.         Public Sub PrintProxyInfo()
3.             Dim doc As Document = Application.DocumentManager.MdiActiveDocument
4.             Dim db As Database = doc.Database
5.             Dim ed As Editor = doc.Editor
6.  
7.             Dim proxyClass As RXClass = RXClass.GetClass(GetType(ProxyEntity))
8.  
9.             Using trx As Transaction = db.TransactionManager.StartTransaction
10.                 Dim bt As BlockTable = trx.GetObject(db.BlockTableId, OpenMode.ForRead)
11.  
12.                 For Each blockId As ObjectId In bt
13.                     Dim block As BlockTableRecord = trx.GetObject(blockId, OpenMode.ForRead)
14.  
15.                     For Each entId As ObjectId In block
16.  
17.                         If entId.ObjectClass.IsDerivedFrom(proxyClass) Then
18.                             Dim proxy As ProxyEntity = trx.GetObject(entId, OpenMode.ForRead)
19.                             ed.WriteMessage("{0}{1}{0}-{2}{0}-{3}{0}-{4} References",
20.                                             Environment.NewLine,
21.                                             proxy.OriginalClassName,
22.                                             proxy.OriginalDxfName,
23.                                             proxy.ApplicationDescription,
24.                                             proxy.GetReferences.Count)
25.                         End If
26.  
27.                     Next
28.                 Next
29.                 trx.Commit()
30.             End Using
31.         End Sub
32.  

[Kurtz David]

Hello,
Thanks for your answer.
I could NOT understand how can I retrieve the attributes (not the className but the internal attributes) from the proxy entity.
(I have read the links you forward me to)
Attached a proxy entity as an example.

[Kurtz David]

Attached a PrintScreen of the Proxy Entity and the Properties i'm trying to get ....

[dgorsman]

Ahhh, ProSteel - my old frenemy.  Have a look around, there should be a document for accessing the properties via COM, its pretty old (around v16 or so) but should still be applicable.  You can also try poking Bentley support for assistance - I beleive there is a dedicated .NET API for newer releases.

[Jeff H]

Attached a PrintScreen of the Proxy Entity and the Properties i'm trying to get ....

I know nothing of ProSteel but if the object enablers are loaded then they are not treated as proxy entities, and dealing with a ProxyEntity your only going to get ProxyEntity properties.

[CADDOG]

...dealing with a ProxyEntity your only going to get ProxyEntity properties.

Weeellll.  Sorta.  The information is there regardless.  In any of the situations, API - no API, Enabler - no Enabler, will only change how you go about getting the info.  Its (data) is going to be in either a dictionary/extension dictionary/xrecord/xdata/or the unamed properties of the classid.
If API - will change everything, and as such you can use their object classes to get at the info by object properties/methods.
If no API - you must reverse engineer how the data was stored.  Difficult, doable, but probably not worth it.  Not knowing the method they store, they could be using a UID on the object/group/block/proxy with a dict in the namedobjectdict as a database.

Prosteel, close sister to AutoPlant (I think) - they can either be database linked or the file can have all the data, or you can use as hybrid with both data in file and db.  The db is more than one table with relationships, so it could be assumed that the data, if stored in the file, will be just as complex (aka difficult).  If full db mode, then no info will be found on the object itself, as that is being stored only in the drawing session.

I would check the xdata on the proxyentities to see if there's evidence of those 'attributes' (really should be called properties).  Pause the code at the ed.writemessage and hover the proxy var to explore xdata and extension dictionary or classid->non-public memebers.  It may have releative information you are looking for.

Post a file with a piece of steel in it.  It may wind up being pretty straight forward.


EDIT:
Saw this, but haven't been approved for membership yet to see what's being done in lisp.

[MP]

Prosteel, close sister to AutoPlant (I think)...

Sisters solely by adoption, and by a parent that is dysfunctional. Their data embedding schemes are unfortunately very different. Succinctly, AutoPLANT embeds most of the data in xdata, no object enabler required, whereas Prosteel's data is fully encapsulated within custom objects, so if you don't have the appropriate object enabler loaded too bad, so sad, no interface for you. Gong.

[CADDOG]

Still would love to see a file from OP (curiosity sake).
It's the teenage difiant mind that I've yet to shed in my adulthood.   

[dgorsman]

Prosteel, close sister to AutoPlant (I think)...

Sisters solely by adoption, and by a parent that is dysfunctional. Their data embedding schemes are unfortunately very different. Succinctly, AutoPLANT embeds most of the data in xdata, no object enabler required, whereas Prosteel's data is fully encapsulated within custom objects, so if you don't have the appropriate object enabler loaded too bad, so sad, no interface for you. Gong.

AutoPLANT requres an object enabler, otherwise all the pipes look square.  Even better, when the object enabler loads it populate *all* open drawings with basic AutoPLANT data (after all, you only run that one program in AutoCAD, right??) at which point they are considered AutoPLANT drawings.  Open those up, or XREF, or insert, and the object enabler will do the same thing with all open drawings.  "Just delete it", I here somebody say?  Without the object enabler loaded, trying to delete the AutoPLANT drawing extension dictionaries results in an error.  Doing it *with* the OE loaded... results in them being added back in!  As a result I've banned the use of the AutoPLANT OE in our office with the exception of the sole project in use by client mandate.

Now back to your regularly scheduled ProSteel data [wr/m]angling.   :pissed:

[Jeff H]

...dealing with a ProxyEntity your only going to get ProxyEntity properties.

Weeellll.  Sorta.  The information is there regardless. 

Not inside a ProxyEntity.

[dgorsman]

...dealing with a ProxyEntity your only going to get ProxyEntity properties.

Weeellll.  Sorta.  The information is there regardless. 

Not inside a ProxyEntity.

Like he said - kindasorta.  ProSteel doesn't use an external database/data file, everything is in the drawing file and it can be looked up.  But the object enabler automates the process of finding that data as well as displaying the graphics correctly.

[Jeff H]

...dealing with a ProxyEntity your only going to get ProxyEntity properties.

Weeellll.  Sorta.  The information is there regardless. 

Not inside a ProxyEntity.

Like he said - kindasorta.  ProSteel doesn't use an external database/data file, everything is in the drawing file and it can be looked up.  But the object enabler automates the process of finding that data as well as displaying the graphics correctly.

I guess I do not understand and do not see how it matters where the data is stored.
It is a Proxy object and has no idea how to load the data into it.
 
How would you go about using a ProxyObject to get the information?
A ProxyObject derives from a DBObject so can you just use a DBObject to get the information?
Every custom object provides some initial data which the proxyObject gives access to, but other than that how is a ProxyObject helpful in obtaining that data?
 
We might not be on the same page, but the point I was trying to make to OP was using a ProxyObject does not give access to the custom objects data.
 

[CADDOG]

I stand corrected.  If designed correctly, then the xdata or extdict is only retrievable by the proxyobject definition's methods - and would not normally (irresponsibly) be defined with public properties, rather non-public properties.

But, I went back and reread everything to make sure this topic wasn't derailed.  From all indications, the OP has the application, and therefore could evaluate the object - call the required object's methods to retrieve the data.   The only thing that indicates he doesn't (ignoring the screen shot), is the fact that the user said proxy, whereas a proxy is only a proxy if object enabler or the actual application is not loaded.

Although this post, without additional OP input should probably pause, I will test later if the extdict and xdata can be exposed if using the proxy.HandOverTo(newobjid, true, true).

Edit:  Tested on AutoCAD PID proxy line "SLINE", and HandOverTo threw an exception.  In lieu of nothing else to test and not having ProSteel, I'm dropping out.  Jeff, thanks for not getting frustrated  :kewl:

Still have a hunch the user would like to get access to the ProSteel properties and has the program, so another direction may still be viable.