Inserting a field (blockplaceholder) within a dimension object

[maverick.b.jeske]

Hi, 

From within the block editor I have created a dimension, (for the purpose of explanation, lets say a linear dimension along a line). Now when I edit the text via "ed" and selecting the DIM. I can then go about adding a field. All well and good.

Now going to: 

Field category: Objects; Field Names: Blockplaceholder.

it states "only accessible in the block editor" Thus I can't reference any of my parameters. 

However I can access them via the attribute editor (then insert field). (note I can't access it via a normal Mtext within the block editor too)

Is the attribute editor the only way to access the "Blockplaceholder" items?

Is there a way I can create a so called custom field that works the same as the "Blockplaceholder" to work around this?

I'd just like to continue using the dimension object as it places the text in the middle of the line. I know I can use the stretch command with a 0.5 multiplier, however, there is problems when certain parameter change my object however they don't affect the text. (such I have another line that is parallel to the dim line. If I change the angle of the 2nd line the other line changes angle but the text is not affected at all. and as such that the text doesn't keep aligned, but with an associated DIM it works easily. 

or would it be easier to set an attribute to be centred?

If no solution, I'll keep plugging away at the geometric parameters and maybe I'm just missing one.

[Libbya]

Post the block.

AFAIK blockplaceholder fields are only accessible within attributes.  

Attribute position is easier to control then dim text which leads me back to... post the block.  Maybe even add a description within the block that shows the desired behavior and how that differs from the current behavior.  

[maverick.b.jeske]

This is pretty much a snip from it. And all that is really needed. Right now, the horizontal appears to work fine, however the vertical text isn't.

The goal is to get both text on the triangle to be centred.

The test is to change the angle of the single line and because of that change the angle of the trianlge. I'd like the trianlge to be scalable, while the text not.

In my original file, my trianlge is 3 lines with geometic cocindent connecting end points (could that also be a problem instead of using a polyline)

I've added the strech command to the attributed text, which works so long as the angle of the single line doesn't change.

Hopefully this is clear enough.

Thanks in advanced.

P.S This is what I initally wanted to get working, however the DIM seemed like an easier solution, however since it can't refer to blockplaceholder, I've replaced it back with an attribute.

[Libbya]

Why are you using constraints?  Why do you have the setup with the parallel lines and the dimensional constraints that change the angle?  The mix of constraints and dynamic parameters/actions is problematic and I don't know enough about what exactly you are trying to accomplish to recommend what direction to go with this.

In other words, showing a small portion of the block you are trying to build doesn't really serve here.  Odds are good that the entire block could be made without any constraints and doing so would be easier and more effective than trying to build it with the parallel constraint driving the triangle shape.  

[Libbya · Accepted solution]

For example, this shows how to do all of the described actions without any constraints (preferable).  

[maverick.b.jeske]

Bascially the driving force as to why the triangle changes is because the angled line in the block changes via a dimensional constraint. Best way to describe the trianlge is just like a magnifed version of the angled line. however for clarity I want to show the dimensions along the side of the major block where there isn't much stuff. that's why the entire trianlge is moveable, basically to be able to put it in empty space. so that you can tell the slope of the angle (hence the dimensions).

Basically the Length and Height lines (These are just construction lines) are there to show the ratio of H:L of the sloped line (and the triangle). However the sloped line is tiny and wont have those nice round numbers. Thus I refer to those for the triangle and not just straight from the sloped line.

To get the angle of the triangle I decided to refer straight to the sloped line as all it would take is just one geometic constraint (Parrelel).  As for "AngleL" that should of had a handle on the other side of the line and "AngleH" was purely there just for testing the angle of the trianlge.

Sorry for the confusion with the dimensional constraints (Looking at it again today I see I didn't create it correctly. Then again that's why I'm asking for help)

As for all my geometic constraints, I've put them in purely to avoid what happens at 6:00 where the whole triangle deforms from a rightanlge triangle, becuase of a strech action.

Seems like you have got the solution to what I'm after in the screencast (I much appreciate you providing that) Just seems like a whole lot more parameters then what I thought i'd would need. just for a copied angle with a could dimensions.

[maverick.b.jeske · Accepted solution]

Is the attribute editor Object the only way to access the "Blockplaceholder" items?

Yes. Attribute editor object is pretty much just an Mtext and if needed to be placed in DIM object I think a point parameter and move action would do just the trick.

Can I create a so called custom field that works the same as the "Blockplaceholder" to work around this?

No solution provided as of yet. This seems to be beyond scope as the attribute editor object works anyways.

Solution to my block, in short:

Basically just use, point parameter and set the "Chain actions" property to Yes. have a move action linked to the text via the point. and the overall scale action have the points and the shape(triangle) in the selection set.

[maverick.b.jeske]

Is there a reason as to why "no constraints" is preferable?

I would of thought having geometric constraints to keep a shape of a object be better then fiddling around with scale and strech selection, to make sure you have the right objects selected.

The only isue was with the parrelel constaint as they are really two seperate objects, so I can see why that can cause problems (it does cause problems).

[Libbya]

There are several reasons why having no constraints is better.  The main reason is because constraints do not behave consistently, especially when combined with dynamic parameters/actions.  In contrast, dynamic parameters/actions behave very consistently.  Constraints also use more computing power and cause larger blocks.  If a block is drawn accurately and dynamic parameters are used sensibly, then it will not warp out of shape and so, no constraints are necessary.  If it is warping out of shape without constraints, then constraints are merely a bad band-aid for a poorly constructed block.  On this forum, one of the most common causes of issues is the unnecessary use of constraints and for 98% of dynamic blocks, no constraints are necessary.  It takes a bit of learning to understand how the dynamic parameters/actions work and interact, but after an initial small amount of learning they are far less 'fiddly' than constraints.  All of that said, there are a few conditions where the use of constraints can accomplish something that cannot be accomplished otherwise.  For those situations, they are quite useful and valuable.