Problem with Dynamic components ??
-
Yep Chris, that is exactly what I did
I should have said that I saved it as a component really, sorry about that.
It was a handy misunderstanding, though, as the fact that it worked fine just by being wrapped up shows how useful "parent!" is in attribute references; if I had used "frame!" instead then it would not have worked unless you called the wrapper "frame" as well.
-
Oh james using the old parent! trick! That is indeed interesting to see that in action. And whats more, it would have created dynamically the X,Y,Z attributes in the parent, since they would not have been there. So that cool!
Chris
-
Thanks guys.
Your input has given me a better understanding now.
I'll have a go at making the components I need and see how I get on. -
I think I am getting the hang of this, but in the meantime I have another related (sort of) question which I posted here
Any thoughts would be appreciated.
-
Hi,
I am just looking at DC and working through some examples.
I have looked at the Frame-fixed.skp file in this thread and have the following observation and questions.If I measure the top of the frame it measures 59.1cm.
Then if I make this a component and view the Len X in the attributes box it reads 63.1cm. The top rail also jumps up out of the frame.I am coming accross this in my initial attempts at making DC and it is putting me off.
Can anyone please explain to to correct this and what I am doing wrong.
Many thanks,
Bruce
-
What I'm seeing is that the top bar is floating, an dyou want it to be fit nicely down inside the 2 sides. right?
The answer is that you have the top's Z set to parent!LenZ - 4 . But it doesn't rely on the paren'ts height at all. It depends on the height of the side frame. So Top's "Z" function should read:
Side!LenZ - 4
That will then position is at the top of the side frame, and down 4 inches. In fact, I think all of your "parent!" values should be replaced with pointing to something else. Because the length and height of the parent component will change each time you change your model. Say you add a new beam over the top of everything? Now your parent component has grown super tall and you don't everything to be based on that. I think you should set the one side component to x =0, y =0 and z=0. Then relate everything back to the side component, since it will then always draw itself to the 0,0,0 of the parent component.
Does that solve it?
Chris
-
@chris fullmer said:
What I'm seeing is that the top bar is floating, an dyou want it to be fit nicely down inside the 2 sides. right?
The answer is that you have the top's Z set to parent!LenZ - 4 . But it doesn't rely on the paren'ts height at all. It depends on the height of the side frame. So Top's "Z" function should read:
Side!LenZ - 4
That will then position is at the top of the side frame, and down 4 inches. In fact, I think all of your "parent!" values should be replaced with pointing to something else. Because the length and height of the parent component will change each time you change your model. Say you add a new beam over the top of everything? Now your parent component has grown super tall and you don't everything to be based on that. I think you should set the one side component to x =0, y =0 and z=0. Then relate everything back to the side component, since it will then always draw itself to the 0,0,0 of the parent component.
Does that solve it?
Chris
Thank you Chris,
I now understand why the top rail jumps out of line, and this now make sense.
I can not get may head around the dimensions that are displayed as LenX as being 59.059cm when the dimension is actual 63.1cm. So therefore LenX is actually not the overall dimension but the overall dimension - the side LenX of 4cm, is that correct?
So every component inside a DC has its own reference point that must be strictly adhered too ! is that correct?
I will try and experiment a little further if I get time today.
Many thanks,
Bruce
-
OK, I have tried this again and I am still seeing this anomaly.
The Len X is ok but the LenY is incorrect I can not see how the attributes box for LenY is being calculated. What am I not understanding here.
The LenY reads 126.322 ????
Any help is much appreciated.
Many thanks,
Bruce
-
I have to admit, I'm seeing it too and I can't figure out why. I'll try to see if I can duplicate it when I get a chance,
Chris
-
Just for clarity the Google Team report as follows.
*Thank you for your note. We're aware of this problem, and our engineers
are currently investigating. We hope to have this resolved in an upcoming
release of SketchUp. We appreciate your patience, and thanks for taking
the time to write.Regards,
The Google Team* -
Hey guys, I can explain. This is one of those problems that is halfway between a bug and "working as designed." Ideas for how to make it better are more than welcome!
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:
- I draw a 4-piece frame that is 100cm wide
- I look at it inside the Component Attributes window and its LENX is 100cm. So far so good.
- 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.
- 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.
In the case of this particular frame example, the answer to getting the onscreen and reported widths to line up is to constrain the X and LENX of all of your subparts to be relative to the parent!LENX in such a way that the formulas place all of the parts perfectly inside the reported width.
Does that make sense? I'd be happy to post another example...
Cheers
-
Thanks Scott,
I think I am getting to understand this a little more.
Please see attached, it seems to work as expected
Many thanks,
Bruce
Advertisement