Author Topic: "Entity" and "Object"  (Read 13417 times)

0 Members and 1 Guest are viewing this topic.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
"Entity" and "Object"
« on: November 04, 2006, 07:16:46 PM »
.....................
On a related note, what's the difference between an "Entity" and an "Object"?   ^-^

Interesting related note !
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

Chuck Gabriel

  • Guest
Re: "Entity" and "Object"
« Reply #1 on: November 04, 2006, 07:45:27 PM »
An object is a database-resident chunk of data.  An entity is an object that has a graphical representation.

JohnK

  • Administrator
  • Seagull
  • Posts: 10572
Re: "Entity" and "Object"
« Reply #2 on: November 04, 2006, 08:45:16 PM »
^^ couldnt have put it better
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #3 on: November 04, 2006, 09:40:55 PM »
Hmm . . . Civil 3D . . . There are no entities at all, only "Civil 3D objects" that are expressed on screen by whatever style is assigned to it.  It can be copied and assigned a different style making the copy look completely different yet it is still the same "object" - change the data for the object and both copies are affected by the change instantly.  No part of the "object" can be selected individually except in some circumstances when the style of a component or its label can be changed.  The styles assigned to the group and all of its components control their visibility, layer and all other properties that can normally be assigned via the layer dialog within normal AutoCAD.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: "Entity" and "Object"
« Reply #4 on: November 04, 2006, 10:00:11 PM »
Must admit, I've always used the names interchangably ...

According to the docs, internally AutoCAD refers to objects as entities  ... a statement I have never really understood  :oops:


kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: "Entity" and "Object"
« Reply #5 on: November 05, 2006, 12:37:13 AM »
To summarize the already brief blurb int the dxf reference, objects are units of data that have no graphical representation; entities are merely graphical objects ... and given the respective lists of properties and methods for both --

AcadObject
===== Properties =====
Application
Database
Document
Handle
HasExtensionDictionary
ObjectID
ObjectName
OwnerID
===== Methods =====
Delete
Erase
GetExtensionDictionary
GetXData
SetXData

AcadEntity
===== Properties =====
Application
Color
Database
Document
EntityName
EntityType
Handle
HasExtensionDictionary
Hyperlinks
Layer
Linetype
LinetypeScale
Lineweight
ObjectID
ObjectName
OwnerID
PlotStyleName
TrueColor
Visible
===== Methods ======
ArrayPolar
ArrayRectangular
Copy
Delete
Erase
GetBoundingBox
GetExtensionDictionary
GetXData
Highlight
IntersectWith
Mirror
Mirror3D
Move
Rotate
Rotate3D
ScaleEntity
SetXData
TransformBy
Update


-- noting that entities sport all the methods and properties of objects but not the other way round I'll suggest that AcadEntity is likely derived from AcadObject.

:)
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #6 on: November 05, 2006, 12:45:58 AM »
An object is a database-resident chunk of data.  An entity is an object that has a graphical representation.

By that definition, toolbar and menu items would be entities, because they have a graphical representation, right?

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #7 on: November 05, 2006, 12:50:25 AM »
To summarize the already brief blurb int the dxf reference, objects are units of data that have no graphical representation; entities are merely graphical objects ... and given the respective lists of properties and methods for both --

So what would you say something like a PVI in a FGProfile is?

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: "Entity" and "Object"
« Reply #8 on: November 05, 2006, 01:24:26 AM »
So what would you say something like a PVI in a FGProfile is?

I've no clue since I've never worked with Land Desktop (had to do a google search to find a reference to it). I'd hazard a guess that it's probably not much more than a simple structure or collection class that need not inherit the AcadObject properties / methods (doesn't exhibit the "is a" AcadObject trait) but as noted, I've never played with LDD so I'll stop my speculation there.

:)

Edit: Tried to fix the grammar but I think it's worse now. Obviously time for bed; night all.
« Last Edit: November 05, 2006, 01:33:16 AM by MP »
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

MickD

  • King Gator
  • Posts: 3603
  • (x-in)->[process]->(y-out) ... simples!
Re: "Entity" and "Object"
« Reply #9 on: November 05, 2006, 01:36:59 AM »
An object is a database-resident chunk of data.  An entity is an object that has a graphical representation.

What Chuck said above with a slight difference, as AcDbEntity derives from AcDbObject ('the' base database class from memory), entities too reside in the dwg database and you must override the filer in/out as well as the world/viewportDraw() methods of AcDbEntity when you derive from it. The only difference is an 'entity' in this sense has a graphical representation whereas an 'object' does not.
A 'custom object' is a bit of a misguiding name for what most expect it to be, while you can create a custom 'object' most uses for them are graphical by nature but this is not always the case, you can create classes that simply store data say, you would derive these from AcDbObject instead of AcDbEntity.

edit - Sorry Chuck, after reading your sentence a few more times you did say the same thing, I just elaborated a bit more perhaps :)
« Last Edit: November 05, 2006, 01:38:28 AM by MickD »
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Crank

  • Water Moccasin
  • Posts: 1503
Re: "Entity" and "Object"
« Reply #10 on: November 05, 2006, 08:55:45 AM »
From Autodesk's DXF-references:
Quote
Object and Entity Codes
In the DXF™ format, the definition of objects differs from entities: objects
have no graphical representation and entities do. For example, dictionaries
are objects, and not entities. Entities are also referred to as graphical objects
while objects are referred to as nongraphical objects.
Entities appear in both the BLOCK and ENTITIES sections of the DXF file. The
use of group codes in the two sections is identical.
Some group codes that define an entity always appear; others are optional
and appear only if their values differ from the defaults.
Do not write programs that rely on the order given here. The end of an entity
is indicated by the next 0 group, which begins the next entity or indicates the
end of the section.
Vault Professional 2023     +     AEC Collection

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #11 on: November 05, 2006, 11:37:59 AM »
An object is a database-resident chunk of data.  An entity is an object that has a graphical representation.
From Autodesk's DXF-references:
Quote
Object and Entity Codes
In the DXF™ format, the definition of objects differs from entities: objects
have no graphical representation and entities do.

OK, sounds like everyone agrees that all Entities are Objects, but not all Objects are Entities.  Again, what about toolbars, which have a graphic representation, but are considered Objects and not Entities (according to Autodesk's documentation)?  And what about something like a COGO Point, which is considered an Entity (also according to Autodesk's documentation), but is stored in a separate database, and therefore has no DXF representation?

In standard usage in computer programming, an Entity Object is an object that incorporates "business logic", or logic specific to the particular application.  Entity Objects would typically not be reused in writing another application, because they are very specific to the task at hand.  This is in contrast to generic Objects, such as UI elements, data structures, etc.

Entities in Autocad are similar.  From what I gather, it seems that Autodesk considers an Entity to be an Object that can have a graphical representation IN A DRAWING.  That does not mean that the object has to exist in a DWG file - in other words, an Entity might not have a DXF representation.  But it would still be an Entity.  On the other hand, a Toolbar Item would be an Object, but not an Entity, because it does not have a graphical representation IN THE DRAWING.

A Block seems to be considered an Object because it has no direct representation in the drawing.  However, a Block is a collection of Entities, and the Entities have a representation in the drawing.  Similarly, a Linetype defines display properties for Entities, but has no direct representation in the drawing, so it is an Object.  Layers, Materials, PlotConfigurations, TextStyles, UCSs, all of these are Objects.

As an interesting quirk, this also means a Paperspace Viewport is an Entity, while a View is an Object.

In Vanilla Autocad, there are actually no Entities that are not stored in the DWG file.  That is not true in Land Desktop, however, where items like COGO Points and Finish Grade Profiles are stored in the Project, but still considered to be Entities.

But the answer is not at all clear-cut.  It is interesting to note the differences between Land Desktop and Civil-3D.  In Land Desktop, an Alignment is an Object, composed of a collection of Entities like AlignTangent, AlignCurve, AlignSpiral, EGProfile, and FGProfile.  In Civil-3D, however, the Alignment is now an Entity, and its horizontal layout is considered a property of the Alignment.  Profiles are still Entities in their own right, but the EGProfile and FGProfile Entities have been combined into a single Profile Entity.  PVIs used to be Entities in Land Desktop; in Civil-3D, they are considered Properties of Profiles Enitites.

Similarly, a Surface is an Object in Land Desktop that contains a collection of Entities like Breaklines and Boundaries.  In Civil-3D, a Surface is considered to be an Entity in its own right.

So, it seems that what constitutes an Entity depends in large part in how you look at it...   :wink:

Crank

  • Water Moccasin
  • Posts: 1503
Re: "Entity" and "Object"
« Reply #12 on: November 05, 2006, 12:51:11 PM »
The question is: Does it matter if you considere an entity as an object?
In Alisp (when you can use the entitylist), I consider the item as an entity, but in Vlisp it's an object to me.
Vault Professional 2023     +     AEC Collection

Serge J. Gianolla

  • Guest
Re: "Entity" and "Object"
« Reply #13 on: November 05, 2006, 03:17:36 PM »
No, no, no!
Objects used to be called entities in past before the catholic church had a go at Autodesk! LOL



Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #14 on: November 05, 2006, 10:37:04 PM »
Sinc, I am still not convinced that Civil 3D objects such as profiles or surfaces are actually entities.  We are EXTREMELY limited with the types of manipulation that can be performed on them.  You can not even copy a profile although they can be created multiple times and they can not be moved at all within their profile view.  You can forget the other modify commands except explode which has its own peculiarity.  They can be modified with grips, but this is actually a method of inputting new data from which it is created as all copies of this profile react immediately to the new data.  There are native AutoCAD primitives within it but to get to them, the profile must be exploded into a block and the resulting block must then be exploded into lines and arcs.  Also of note, if there is only one copy of this profile or surface and it is exploded, the definition is gone and short of a successfull run of white knuckle "undo"s, they have to be recreated from scratch or restored from a backup.  I do not know what the dxf from one of these looks like, but I know that unless they are exploded down to primitives they come back as either proxy objects or zombie entities when the dxf is imported by an earlier AutoCAD version.
How can they be an entity if they can not be manipulated by most regular methods?  What about things like point groups or profile views?

MickD

  • King Gator
  • Posts: 3603
  • (x-in)->[process]->(y-out) ... simples!
Re: "Entity" and "Object"
« Reply #15 on: November 05, 2006, 10:54:18 PM »
Quote
How can they be an entity if they can not be manipulated by most regular methods?  What about things like point groups or profile views?

The only reason I can see you can't interact with these entities is they have no UI written for them, this may have been on purpose for what ever reasons.

All verticals that have custom objects are responsible for there ui and appearance, this means you must override/write for everything that you want available in the editor such as glyphs and snaps, if you don't write code for it you won't get it!

Just to put a line in the sand with what sinc was talking about with objects such as toolbars, yes they are objects in an OO programming sense but in not in a drawing database sense. No wonder people are confused with all the similar terminology flying about :)

Just to add to the confusion, you can draw visible entities that are not db resident such as a custom ucs indicator, are these entities or objects? :D

"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #16 on: November 05, 2006, 11:49:58 PM »
The only reason I can see you can't interact with these entities is they have no UI written for them, this may have been on purpose for what ever reasons.

All verticals that have custom objects are responsible for there ui and appearance, this means you must override/write for everything that you want available in the editor such as glyphs and snaps, if you don't write code for it you won't get it!

Just to put a line in the sand with what sinc was talking about with objects such as toolbars, yes they are objects in an OO programming sense but in not in a drawing database sense. No wonder people are confused with all the similar terminology flying about :)

Just to add to the confusion, you can draw visible entities that are not db resident such as a custom ucs indicator, are these entities or objects? :D


Part of the problem is that there is just not one thing you can select and manipulate with these things.  A click on any part of a profile or one of its associated labels activates the entire profile for modification.  A click on a label will yield additional methods for manipulating the labels themselves.  they can not be trimmed from, extended to, mirrored,or arrayed.  The only exception I can think of at the moment is that an alignment can be offset.  Even simple osnaps work very sporadically.  Most won't work at all but endpoint will work at least in some circumstances.  One of my labels styles includes 2 different lines of text, a line and a block made up of two circles at one end of the line. Absolutely none of the osnaps work with this label even though there are intersections, endpoints, midpoints, centers and insert points visible on screen.  The only grip available for use is at the anchor point defined in the label style.
The only effective means of manipulation seems to be the moving of data points by grips which as I stated seems to be more an alternate method of data entry than anything else.  If I use this method to change a profile, the surface that was used to create that profile is immediately rebuilt and a flag is set for any other structure or object tied to the surface calling for an update.
This is why I am thinking these things are not entities.  It is more like looking at the raw data being expressed on screen in a chosen style filtering out all but what is needed.  You can not grab a contour on screen - you select the entire surface and you can make it display any density of contours, slopes. flow arrows, colors by a chosen elevation range, TIN lines, any combination or all of these or even NOTHING.  The data is still there and the crosshairs can constantly show the elevations of each surface in the drawing at any point for which there is data available even when there is no visible evidence of the surface in the drawing.

Glenn R

  • Guest
Re: "Entity" and "Object"
« Reply #17 on: November 06, 2006, 12:58:54 AM »
If it's graphical, part of the drawing database and filed in and out on saves, then it's an AcDbEntity.
If it's non-graphical, part of the drawing database and filed in and out on saves, then it's an AcDbObject.

A toolbar, for example is neither - it's a programming object sure, but has nothing to do with the dwg dbase itself.
Dictionaries = non-graphical but in dwg dbase = AcDbObject for example.

The case with your Profile, I suspect, is that it is a "custom entity" defined by Autodesk to extend autocad for the civil market.
When defining a custom object in ARX, you as the programmer get to decide the "grip points" amongst other things.

Now if you generate a standard profile, it uses all it's internal code to generate and display it and allow interaction with it.
Now, if you go and add a custom block as a label I think you said, then that is not a part of the code/object defintion per se - it's an add-on.

Therefore, there was no defintion in the code to allow for creating "grip points" at the appropriate places for the objects that make up your block - hence the flakey behaviour in the OSNAPs on the profile - there should be, but there's not.

Hope this ramble makes some sense.

Cheers,
Glenn.

Glenn R

  • Guest
Re: "Entity" and "Object"
« Reply #18 on: November 06, 2006, 01:04:03 AM »
At the end of the day, I would be VERY surprised if profiles and what not in Civil3d are not implemented as anonymous blocks.
For example, a standard AutoCAD table, behind the scenes, is really an anonymous block of the form "*T123" where the 123 is an auto incremented value.

If you post up a dwg with JUST a small surface or profile, I should be able to look at it with vanilla autocad thru object enablers - then I could tell you if my assumption above is correct.

Cheers,
Glenn.

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #19 on: November 06, 2006, 07:11:35 AM »
Sinc, I am still not convinced that Civil 3D objects such as profiles or surfaces are actually entities.
...
How can they be an entity if they can not be manipulated by most regular methods?  What about things like point groups or profile views?

Check the Civil-3D Help (civilauto-reference.chm in the Civil-3D install/Help directory).  It does not seem to be complete, and a lot of it is broken (thanks, Autodesk), but enough of it works that you can get the general picture.

You will see that Civil Entities derive from the IAeccEntity class.  Various other things derive from various other classes that derive from IAecObject.  For example, Styles derive from IAecObject (through a couple of other classes).

Surfaces has a "point collection" in the Surface entity.  But there is also an "AeccPointGroup" entity.

Note that you must Export Civil-3D drawings to other formats to open them in Vanilla or LDD; I'm guessing that in the Export, Civil-3D converts the C3D Entities to Autocad primitives.
« Last Edit: November 06, 2006, 07:15:43 AM by sinc »

Glenn R

  • Guest
Re: "Entity" and "Object"
« Reply #20 on: November 06, 2006, 07:19:25 AM »
The 'I' in IAeccEntity, is typical programming nomenclature to represent an Interface to an object, not the actual object itself per se.
Any number of different programming objects can support an Interface, but be totally different beasts under the covers.

Cheers,
Glenn.

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #21 on: November 06, 2006, 07:26:58 AM »

Part of the problem is that there is just not one thing you can select and manipulate with these things.  A click on any part of a profile or one of its associated labels activates the entire profile for modification.  A click on a label will yield additional methods for manipulating the labels themselves.  they can not be trimmed from, extended to, mirrored,or arrayed.  The only exception I can think of at the moment is that an alignment can be offset.  Even simple osnaps work very sporadically.  Most won't work at all but endpoint will work at least in some circumstances.  One of my labels styles includes 2 different lines of text, a line and a block made up of two circles at one end of the line. Absolutely none of the osnaps work with this label even though there are intersections, endpoints, midpoints, centers and insert points visible on screen.  The only grip available for use is at the anchor point defined in the label style.
The only effective means of manipulation seems to be the moving of data points by grips which as I stated seems to be more an alternate method of data entry than anything else.  If I use this method to change a profile, the surface that was used to create that profile is immediately rebuilt and a flag is set for any other structure or object tied to the surface calling for an update.
This is why I am thinking these things are not entities.  It is more like looking at the raw data being expressed on screen in a chosen style filtering out all but what is needed.  You can not grab a contour on screen - you select the entire surface and you can make it display any density of contours, slopes. flow arrows, colors by a chosen elevation range, TIN lines, any combination or all of these or even NOTHING.  The data is still there and the crosshairs can constantly show the elevations of each surface in the drawing at any point for which there is data available even when there is no visible evidence of the surface in the drawing.

That makes complete sense.  Any entity has special grips that allows you to manipulate it, and you can only manipulate it through the grips (or programatically, of course).  A Line Entity may have two grips, one on each end.  A Surface Entity may have more esoteric grips.  A Line Entity will get one set of options when you right click.  A Surface Entity will get a different set of options when you right-click.

Nothing says that an Entity must be selectable, or that an Entity must be a primitive structure (e.g., a LWPolyline is an Entity, so is a 3DMesh).

And I think you see why I tried to differenticate between something that CAN be seen graphically in the drawing (i.e., has the capability of being seen in the drawing, assuming the user performs some specific set of actions), and something that actually IS seen graphically in the drawing right now.  Entities may be invisible in the drawing, or partially-visible, or not even in the drawing (as with Cogo Points).

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #22 on: November 06, 2006, 07:27:43 AM »
The 'I' in IAeccEntity, is typical programming nomenclature to represent an Interface to an object, not the actual object itself per se.
Any number of different programming objects can support an Interface, but be totally different beasts under the covers.

Cheers,
Glenn.

Sure, but from it's name, you can see that it's the interface to an Entity...

Dnereb

  • Guest
Re: "Entity" and "Object"
« Reply #23 on: November 06, 2006, 08:52:10 AM »
An object is defined in the VBA library and can hold every non non native data type (integers long etc..)

An Entity is part of the Autocad Object model en is restricts it's contents to Objects having a graphical representation in a acad drawing.

Notes:
Entity's in other object models do not have anything to do with autocad.Entity's

If a manual refers to "All Objects be considered entity's"
they forgot a bit to make reading easier for nitwits it should be:
"All Graphical objects within a autocad drawing, that is  those in model and paperspace"
but I assume writing that restriction every time would seriously make the text unreadable.

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #24 on: November 06, 2006, 02:00:38 PM »
At the end of the day, I would be VERY surprised if profiles and what not in Civil3d are not implemented as anonymous blocks.
For example, a standard AutoCAD table, behind the scenes, is really an anonymous block of the form "*T123" where the 123 is an auto incremented value.

If you post up a dwg with JUST a small surface or profile, I should be able to look at it with vanilla autocad thru object enablers - then I could tell you if my assumption above is correct.

Cheers,
Glenn.
You may very well be correct about the anonymous blocks.  This drawing is about as simple as I can get to you that is not exploded down.  It includes a simple alignment, a small surface and existing and proposed profiles over the surface along the alignment.

Glenn R

  • Guest
Re: "Entity" and "Object"
« Reply #25 on: November 06, 2006, 05:35:37 PM »
Nothing is leaping out at me in that dwg, however, all your 'special' objects are showing as Proxy's/Zombie's. I may need a full version of Civ3d to be able to really pull it apart, which I don't have.

For the most part, with the information I can see, they are full fledged/ridgy didge custom objects...impressive from a programming point of view.

Cheers,
Glenn.

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #26 on: November 06, 2006, 05:41:37 PM »
Nothing is leaping out at me in that dwg, however, all your 'special' objects are showing as Proxy's/Zombie's. I may need a full version of Civ3d to be able to really pull it apart, which I don't have.

For the most part, with the information I can see, they are full fledged/ridgy didge custom objects...impressive from a programming point of view.

Cheers,
Glenn.
That is about what I expected you to get from it.  Even with object enablers, if I sent that file to a non-Civil 3D shop to be worked with, I would not likely be able to even open it again with Civil 3D if one of those objects was modified and the drawing saved in anything other than Civil 3D and would most likely have to do an audit if it was just opened and saved.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: "Entity" and "Object"
« Reply #27 on: November 06, 2006, 05:57:48 PM »
translation :
ridgy didge
'real', 'unadulterated', 'all right', 'genuine', 'fair dinkum', 'good', 'good as gold'

:-)
« Last Edit: November 06, 2006, 05:59:26 PM by Kerry Brown »
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

sinc

  • Guest
Re: "Entity" and "Object"
« Reply #28 on: November 06, 2006, 06:06:52 PM »
Nothing is leaping out at me in that dwg, however, all your 'special' objects are showing as Proxy's/Zombie's. I may need a full version of Civ3d to be able to really pull it apart, which I don't have.

For the most part, with the information I can see, they are full fledged/ridgy didge custom objects...impressive from a programming point of view.


Yes indeed.  That's what I've been saying - they REALLY ARE entities.  Civil-3D is not Softdesk...   :-D

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #29 on: November 06, 2006, 06:30:24 PM »
. . . Yes indeed.  That's what I've been saying - they REALLY ARE entities.  Civil-3D is not Softdesk...   :-D
One thing I would never said was that Civil 3D was Softdesk - or even kind of like it.  The program is already too good for that comparison.
Whatever these objects are that it creates though, what is needed to manipulate them?  Without the full program, it is difficult to even explain what it provides for us to work with much less a customization project and how it would be used.  One thing lacking is the ability to select an object or label of a desired style and assign that style to a like object or label.  Such a customization would save considerable time.  Currently to change the appearance of the object, either the style must be modified which changes all objects with that style, or a new one is selected or created if none yet exist that are suitable.

MickD

  • King Gator
  • Posts: 3603
  • (x-in)->[process]->(y-out) ... simples!
Re: "Entity" and "Object"
« Reply #30 on: November 06, 2006, 07:59:41 PM »
Dino', it sounds like they have created another symbol table/dictionary similar to layers and dim styles. IOW you must give it a style as you would a layer only it sounds like your styles are much more involved and therefore harder to set up on the fly.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #31 on: November 06, 2006, 08:47:23 PM »
Dino', it sounds like they have created another symbol table/dictionary similar to layers and dim styles. IOW you must give it a style as you would a layer only it sounds like your styles are much more involved and therefore harder to set up on the fly.
I am not even sure if it is possible to do.  The labels I put on those curves in the sample drawing are only displaying a fraction of the data available to compose a label.  I just counted 38 different bits of data that could be displayed with that curve label.  If that was still insufficient, I can add any text wanted to the style and place it wherever I wished; if I decided to go rogue, the entire label could be composed of nothing but text I compose or import from a file.  The lines, blocks and arrows can also be added, moved or deleted as desired and any of the conventional properties of these items can be specified at this point to override the default values defined in the drawing.  It is again more like a database query being displayed on a form that looks like a drawing than a real drawing.

Dinosaur

  • Guest
Re: "Entity" and "Object"
« Reply #32 on: November 09, 2006, 01:13:36 PM »
I used THIS little tool from ronjonp on one of the profiles in my sample drawing that yielded the following output.  I am much more adept at code thievery than interpretation and don't know much about what it has reported.  Does something like this have promise for any customizations?  Incidentally, I purposely picked one of the labels to get this report but my best guess is that this report is for the entire profile.


Code: [Select]
VLAXPROP
Select Entity to Display it's Data: ; IAeccProfile: IAeccAlignEntity Interface
; Property values:
;   Alignment (RO) = #<VLA-OBJECT IAeccAlignment 128899e0>
;   Application (RO) = #<VLA-OBJECT IAeccApplication 128cbc80>
;   Description = ""
;   DisplayName (RO) = "Layout (1)"
;   Document (RO) = #<VLA-OBJECT IAeccDocument 128cac60>
;   Dynamic = 0
;   ElevationMax (RO) = 1022.5
;   ElevationMin (RO) = 973.486
;   EndingStation (RO) = 1867.5
;   Handle (RO) = "613F"
;   HasExtensionDictionary (RO) = 0
;   Hyperlinks (RO) = #<VLA-OBJECT IAcadHyperlinks 128cfd04>
;   IsReverseStationing (RO) = 0
;   Layer = "profile"
;   Length (RO) = 1867.5
;   Linetype = "ByLayer"
;   LinetypeScale = 1.0
;   Lineweight = -1
;   Name = "Layout (1)"
;   ObjectID (RO) = 2124674360
;   ObjectName (RO) = "AeccDbVAlignment"
;   Offset = 0.0
;   OwnerID (RO) = 2125425912
;   Plinegen = -1
;   PlotStyleName = "ByLayer"
;   PVIs (RO) = #<VLA-OBJECT IAeccProfilePVIs 128c8db0>
;   SampledEndingStation (RO) = 0.0
;   SampledStartingStation (RO) = 0.0
;   ShowLabels = -1
;   ShowToolTip = -1
;   StartingStation (RO) = 0.0
;   Style = #<VLA-OBJECT IAeccProfileStyle 128d2b70>
;   StyleName (RO) = "Finished Ground"
;   Surface (RO) = nil
;   TrueColor = #<VLA-OBJECT IAcadAcCmColor 128d3fd0>
;   Type = 2
;   Visible = -1
;   WeedGradeFactor (RO) = 30.0
; Methods supported:
;   ArrayPolar (3)
;   ArrayRectangular (6)
;   Copy ()
;   Delete ()
;   ElevationAt (1)
;   GetBoundingBox (2)
;   GetExtensionDictionary ()
;   GetXData (3)
;   Highlight (1)
;   InstantGrade (2)
;   IntersectWith (2)
;   Mirror (2)
;   Mirror3D (3)
;   Move (2)
;   Rotate (2)
;   Rotate3D (3)
;   ScaleEntity (2)
;   SetXData (2)
;   TransformBy (1)
;   Update ()
nil