getting 3dSolid Box properties using VBA...

Hello!

The problem is:

When i create a Box, then select it and click right mouse button and select properties menu, the window called Propertoes is displayed. This window have information about the box that is selected such as Length, heigh, width and so on...

So i need to write VB application where i can store this parameters. I need to do this only with Box objects that are free oriented in a ModelSpace.

Thank you for your advices!

Are you saying you need to store the information at time of the box’s creation?

If so then using BeginCommand and/or EndCommand event handler would probably be effective. The normal user interface for a solids creation could be replaced by a custom version that records the pertinent data.

-OR-

Are you trying to retrieve the dimensions of solids already in a drawing? If the solids are indeed simple boxes box then 3DSolid.PrincipalDirections can be used in conjunction with a .TransformedBy and a .GetBoundingBox to retrieve the box dimensions.

Thank you for reply!

I am trying to retrieve the dimensions of solids that are already in a drawing.

As i understood, your method is...

1. Get 3DSolid.PrincipalDirections to find the orientation of the box in a modelSpace

2. Then 3DSolid.TransformedBy ( and here should be PrincipalDirections that we have found in 1 step)

3. And finaly .GetBoundingBox.

That is the way of solving my problem, but i dont like it. I want to know if there is is a way to get properties of the box right from the properties window that you can view in attachment file.

I want to know if there is is a way to get properties of the box right from the properties window that you can view in attachment file.

It is certainly logical to think that possible but, oddly enough, it is not (at least not for solids with arbitrary orientations in space). Autodesk did not include a full compliment of properties or methods for the 3DSolid object.

In the case of dealing with regular box solids the process I described, though cumbersome, wouldn’t be too taxing for the coder during design, nor the machine at runtime. If the solid is not so regular, i.e., has undergone Boolean operations, the task becomes considerably more complex.

I’ve got a VBA sample if you’re interested.

It is certainly logical to think that possible but, oddly enough, it is not (at least not for solids with arbitrary orientations in space). Autodesk did not include a full compliment of properties or methods for the 3DSolid object.

 

In the case of dealing with regular box solids the process I described, though cumbersome, wouldn’t be too taxing for the coder during design, nor the machine at runtime. If the solid is not so regular, i.e., has undergone Boolean operations, the task becomes considerably more complex.

 

I’ve got a VBA sample if you’re interested.

Yes please poste the VBA sample here, or send me email:)

Autodesk did not include a full compliment of properties or methods for the 3DSolid object. ---------- This is very strange. Because methods and properties like:

MomentOfInertia

PrincipalMoments

ProductOfInertia

RadiiOfGyration

Volume

-- at least requires object length heigh and width for a BOX objects.

I am trying to say that length heigh and width properties are more important than those i have mentioned before.

The more cynical explanation would be that the 3DSolid portion of the API was purposely hamstrung to obstruct customization efforts competing directly with Autodesk Inventor.

Be that as it may, a lot of things are possible, just with a bit more effort from the coder. I’ll put together that sample and post it shortly.

Here is a sample.

BoxDimesions.txt

Hello SEANT,

thank you for your code, y use it, but there is a problem with boxes who have two same dimensions (example : Long 1000 ; larg 200 ; height 200).

In this example, the dimensions are calculate too long.

Have you a solution/correction for this little problem ?

Sorry for my bad english, y am french..

Patick.

Interesting. There is a discrepancy in how AutoCAD generates a solid’s Principal Directions. That discrepancy causes my routine to fail on a solid with matching dimensions unless the sides are aligned to X, Y, or Z.

Give me a bit of time and I’ll fix it.

Here is an updated version that should return the correct dimensions regardless of how length, width, and depth relate to each other.

BoxDimensionsV2.txt

OK, SEANT,

I have tested this version (v2) and it works fine.

Thank you very mutch.

Patrick

To bad they don't exposed more about 3DSolid's - one function that can be of great help is the OOB (Oriented Bounding Box).

It is on my todo list - some day.

To bad they don't exposed more about 3DSolid's - one function that can be of great help is the OOB (Oriented Bounding Box).

 

It is on my todo list - some day.

Is that anything like this?

http://www.cadtutor.net/forum/showpost.php?p=292804&postcount=3

Is that anything like this?

 

http://www.cadtutor.net/forum/showpost.php?p=292804&postcount=3

Nope...

Well unless that one works if the 3D solid it is rotated in a non-world or any other ucs, or if is not a box, etc etc...

The ExtrusionLength/OrientedBoundBox(OBB) is somewhat of a recurring theme, which has met with limited success . . . . though, I seem to recall, Luis, that you had a method demonstrating exceptional promise.

The general goal was to provide automated BOM generation for any linear stock (beams, pipes, extrusions, dimensioned lumber), at any arbitrary orientation, with any amount of end or midspan treatment,. The two general modes to accomplish this are:

Examine pertinent features/information of the solid to determine the original extrusion direction. If possible, calculate length directly or, if needed, temporarily reorient the solid to get useful Bounding Box information.

Imbue the extruded solid with orientation data at time of creation (set as xdata, group 1013). At time of BOM, use that data to temporarily reorient solid to get OBB.

Both modes have there strengths and weaknesses. I imagine any bulletproof routine employing the first mode will be ARX based.

The parameters of this thread's OP’s original query, strictly regular boxes, made the task reasonably easy from the VBA direction. The attached two files demonstrate a broadened scope VBA effort I had originally posted over at theSwamp.org.

http://www.theswamp.org/index.php?topic=21524.0

I doubt the routine will be bulletproof, I know it will not be very fast.

Additional links:

http://www.theswamp.org/index.php?topic=9775.0

http://www.theswamp.org/index.php?topic=24045.0

http://www.theswamp.org/index.php?topic=16754.0

SolidLengths.txt

SolidLengthProfile.dwg

Yes, I was very closed and as many of my personal projects sometimes I simple put it on the side (and don't recall that I made it as an open source on that place).

Once, I get a chance will try to finish it, but pay work first.

. . . . (and don't recall that I made it as an open source on that place).

. . . .

Perhaps, but I do remember seeing some highly modified extrusion which your code had correctly processed. With regard to open source . . . . we can only hope.

Perhaps, but I do remember seeing some highly modified extrusion which your code had correctly processed. With regard to open source . . . . we can only hope.

Hi Seant (is it your name or nickname?)

I will have a look, I did about 8 different algorithms.

How about the last lisp command posted by wizman, does not work for all the conditions or still is for boxed types?

Luis.-

Hi Seant (is it your name or nickname?)

My full name is Sean Tessier. I use the SEANT concatenation because it looks like it should be pronounced “Saint”. That should gain me instant credibility.

Just kidding.

. . . .

How about the last lisp command posted by wizman, does not work for all the conditions or still is for boxed types?

 

Luis.-

I think that routine will handle any type extrusion with the appropriate pick point. The algorithm will likely require some modification to handle higher quantity selection sets.

Given that AutoCAD programmers are typically the “Up for the Challenge” type of individual, these threads may have recruited a few more participants into this particular theme.

My full name is Sean Tessier. I use the SEANT concatenation because it looks like it should be pronounced “Saint”. That should gain me instant credibility.

 

Just kidding.

Funny, when I first read it, I thought it was someone who did one of these..