Problem with simple Dynamic Component

I think I must be being stupid today but perhaps some kind soul can help!

I am trying to create a simple DC to represent an internal door in plan. I have two issues I cannot seem to resolve:

  1. The idea is that you can use handles to scale the DC to fit an opening of any width. But if you do that, the size of the swing and door does not do what I would expect. There must be something wrong with my formulae but I cannot spot it.

  2. I made the door frame a component within the DC so that both instances would always be the same. But if you change its thickness, say, it behaves like a Group with one changing but not the other. Perhaps you cannot use Components within DCs in the normal way?

Here is the file:

2d door.skp (211.6 KB)

Try this:
2d door_b.skp (212.5 KB)
Somehow, your RF lost its size constraints. I deleted it, ctrl-dragged the LF over to replace it again, renamed it RF and constrained its X-position within the parent.

The right frame (RF) had no size constraints because it was a component. It was a copy of LF and only named differently to identify it within the DC. As a further development, I wanted users to be able to specify the wall thickness, which would affect the depth of LF and so, because it is a component, the depth of RF too. In your version, both LF and RF are Groups so each would need size constraints (not a problem in such a simple drawing but might be if there were many repeats).

Your version works just as I expected, so thanks for providing it. Having just re-opened my version to check the differences, I see that it no longer has any dynamic functionality, despite the constraints still being there. I am beginning to wonder if the file is corrupted in some strange way. Maybe that is why it was not behaving as expected yesterday.

I just changed the Frame Depth of your model to be user definable. Again, something weird is happening. If I set it at 100mm (as originally drawn), it gets reduced as if there is an unseen multiplier/divider at work.

Here is a screen shot:

Any idea what is going on?

the unseen factor is 2.54, the conversion factor for changes from inch to cm. It is a known bug which you need to be aware of whilst using metric units. Check the preferred units in the right l> dialog of the value. Same with options dialog. Moreover re-entering the values can correct or force a recalculation,

if you post your edited DC, it would be easier to pin point the issue

Latter you will find that some functions like current and facearea return the value in inches and you need to multiply the result by 2.54 or its square

I will post both the original file that no longer seems to know it is dynamic and the one that I referred to last (B).

I think the units were correctly selected. However, I forced the depth dimension to 10cm (which is where it started) and that seemed to resolve the issue. Looks like it is now working as hoped with user input for wall thickness (= frame depth) and the ability to scale to any given opening width.

2d door.skp (212.0 KB)
2d door_b.skp (212.1 KB)

Whoops, I spoke too soon! If you look in the Component Options, you will see that the depth is reported as 254mm not 100mm as it should be. Sounds like that is the bug you refer to. Maybe there is nothing to be done about that until the problem has been ironed out?

you will note that there are no units after the values for DoorLength, DoorWidth …in 2D internal door. they have defaulted to text. click the inside each value box and then click the right icon => to get the info dialog and change the default from text to centimeters

don’t forget to apply

BTW, both RF and LF are still components in my version. I just deleted your RF and as you said, made a new copy of LF and renamed it. Only diff is that I added the X constraint within the parent, which made it behave better when scaling.

Looks like LF was a group that you subsequently made a component.

OK, but isn’t the whole point of making something a Component that when you edit it, all instances get edited at the same time? That wouldn’t happen in this case, would it? In which case, it would behave just like a Group, surely?

And yes, it was a Group that I turned into a Component. Does that make a difference?

When you turn a Group into a Component, only that one copy of the Group is taken to be an instance of the new Component. All others are still Groups and remain independent of the Component.

Yes indeed, but what I did was this:

  1. I started with a Group and then copy-moved it to create the second instance;
  2. I then realised that I would have to put in size parameters for each instance;
  3. I deleted the second instance, turned the first into a Component, and then copy-moved that.

I then only expected to have to put in size parameters for one instance, just as you would outside a DC. But when I resized the DC, the second instance did not change size like the first. @fljdave solved my problem by putting size data back into the second instance, treating it just as if it had been a Group.

None of this matters in this case where there were only two instances. But suppose I had railings and dozens of instances. It would then matter a lot!

No, as i said above, I deleted RF, copy-dragged LF over and only added the X position parametric, which maintained its component relationship with the original. Basically the same process you just described. Not sure how your original RF lost its parametric constraints…

I definitely find DC’s to be glitchy. I often have things just not work until I delete and redraw the same thing over, Real PITA sometimes!

Ok, just did a little experiment:

  1. drew a rectangle
  2. made it a group
  3. gave it size constraints
  4. converted it to a component
  5. copy-dragged the component
    Result: The copy looks like the same component in Outliner, but in reality changing one does not affect the other. (Probably what happened to simoncbevans.)

Experiment 2:

  1. converted group to component first
  2. then gave size constraints
    Result: Component copies behave as expected

Experiment 3:

  1. used the misbehaving component from first experiment
  2. redefined the constraints
    Result: Copies now behave properly

Conclusion: Converting groups to components is similar to creating “raw” components in that constraints need to be defined after component creation. I would consider this a bug in the “Make Component” tool functionality.

Is it that when you copy a Component within a DC, it automatically creates a unique copy?

When you say in Experiment 2 that you converted a group to a component first, do you mean created a Component from a number of entities or that you created it from a Group outside the DC (or neither)?

I have to say that I am not convinced that DCs have quite lived up to their promise. A lot of people seem to fid it easier to create something from scratch or simply edit something that exists. The concept was sound enough but without further evolution and improvement, I fear it may be a cul-de-sac. Could be my incompetence talking, of course…