Topic: "Entity" and "Object"

[MickD]

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?

[Dinosaur]

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?

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]

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]

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]

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.

[Glenn R]

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]

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]

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]

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]

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]

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]

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]

translation :
ridgy didge
'real', 'unadulterated', 'all right', 'genuine', 'fair dinkum', 'good', 'good as gold'

[sinc]

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...   

[Dinosaur]

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

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.