Stair railing resizes incorrectly

Hey All,

I am having trouble with this stair railing(currently just the bottom rail). For some reason it jumps when resized. I have all the child components reading from the parent only but its still takes a few tries to get it to the correct size. I am wondering if the order of actions when SKP redraws a component is part of this puzzle? Or is it something else in the way I have set it up?

STAIR RAIL jerky.skp (185.4 KB)

By jump, do you mean that it rescales in the blue direction? If so, isn’t that what you would want it to do?

Hey simoncbevans,

Not the z stretch, that is how it is intended. I am referring to how it won’t snap to the surface or corner in the x direction. If you scale it way back and forward again it recalculates the size as being longer or shorter than the intended target…

I had the same problem with a regular rail i built. Cleaning up the child component references fixed that one, but i just can’t seem to get this one smooth on rescale.

I must be missing something, sorry…

There is a problem if you try doing this and select the corner instead of the surface, but it seems to work even then if you hold the shift key down.

No, hold on, you’re right. There is a small gap even when you snap to surface. Hmmm…

YEP, That’s the thorn in my side. :wink:

I wonder if I’ve got a looped reference somewhere… or if there is a better way to determine and/or pass the size & position info to the children…?

Yes, you have a circular reference. If you scale in the x direction with the scale buttons, you are then calculating the length of the rail, which then alters the overall size of the whole component which the rail is calculated from and so on round in circles. It is not just that you have to resize it twice, it iterates on and on, getting closer to a size (not necessarily the right size). If you turn up the precision of the units and look at the calculated sizes, you’ll see them changing every time you try and scale it to snap to your box at the right. It takes about six times scaling it to get it to converge to 6 decimal places.

I don’t have time to solve this right now (not even sure how without spending lots of time on it). One way might be to remove all the scale buttons and have have a textfield for the horizontal size. I haven’t checked all your maths for the end brackets so there could be an error in there or with the positioning of the start and end of the rail.

This doesn’t change the size, just makes it a bit simpler:

BTM_HINGE_BASE_END, Position.X could be simplified from

1 Like

Thanks for the response,

Hmmmm, I removed the formula for BTM_RAIL LenX, but the positions of the brackets are also determined by trig functions based on the parentLenX, and thusly it is still circular. So I guess the question is how do you set up something like this to scale accurately? With minimal user input… The LenX of the rail, and X and Z positions of the brackets need to come from trig functions of the intended stretch length, rise and run. So how to accomplish that without pulling out the measuring tape and manually entering the LenX? Perhaps I am asking too much of DCs? Why can’t they just magically do what I want. LOL

Yep. Looking at that right now. Less math=better.

Your formula for the rail length is missing an allowance for the distance from the walls to the pivot point of the bracket, so it would be something like this;

Then you’d have to subtract something for the distance from the pivot point to the start of the rail, at both ends.

Once you get your maths right, it shouldn’t be circular anymore. No matter how many times you scale it, it would calculate the same numbers every time and wouldn’t change the lenx of the whole Dynamic Component.

1 Like

Thanks McGordon, great help. I’ll keep grinding away.

Here is what one of the original designers of the DC has to say about it:

Here’s the idea. Before something is a DC, it’s reported width is equal to what is on screen. However, at the moment a positioning formula is added to one of its parts, its reported width can get out of sync with what is one screen. Consider this series of steps:

  1. I draw a 4-piece frame that is 100cm wide
  2. I look at it inside the Component Attributes window and its LENX is 100cm. So far so good.
  3. I add a formula to the right piece where its X=parent!lenx. This moves the piece “outside” the size of the parent, to the far right of the parent component.
  4. The LENX of the entire frame is STILL reported as 100cm, even though on screen it is wider (100cm plus the width of my piece.)

This may seem weird at first, but consider what would happen if the reported width were always updated to the onscreen width. My frame was 100cm wide, so the right piece moves to 100 cm, so the frame becomes 110 cm wide, so the right piece moves to 110cm, so the frame is 120 cm wide, etc. etc. etc. Every time you redrew your DC, the frames would grow. It’s a kind of geometric circular reference.

So the software’s behavior is as described above: at the moment you add a formula to a DC, its on screen width gets stored inside the DC, and formulas are driven off of that. If you scale a DC, the internal width is updated and the formulas are fired again.

see this thread on sketchUcation

in addition, you better use a custom attribute in stead of the LenY of the component itself

1 Like

OK, so it sizes as desired now, however the parent lenZ does not update on resize? so I can’t use it to position the btm_hinge_base_end component… So close…STAIR RAIL.skp (277.7 KB)

Part of the fix was burying the end brackets inside the rail piece and restricting their size. Removed a bunch of math.

Hey Mike Wayzovski,

Do you mean add an attribute that mirrors the LenX (scale direction) value of the parent? I am missing what you are suggesting. Great article clears things up a bit for me.



The BTM_RAIL is the wrong length though…


THANKYOU! Here is a working version of the component if anyone is curious. STAIR RAIL.skp (280.1 KB)

Also still curious as to why the LenZ dosn’t update?