Locked items moving - but differently

I’ve just spent several hours registering a complex set of off-axis walls. I did them in three sets of walls, each one parent component.

Inside each set, as I worked up, I locked each wall after positioning it very carefully, and editing other components to match them. I locked each of those as I went.

I get to the top, and find when I look again at the bottom, that lower walls have moved, sometimes by inches, both off register at the origin where I had placed them, and off angle even when correctly registered.

There’s an earlier reported bug at

but this isn’t the same - I was moving and rotating (by very small rotations of less than 1/1000 of a radian, or .057 degrees, in some cases), and not typing in distances, but moving and rotating with the mouse. I got exact inferences, and locked each floor’s components.

It seems that if a parent component is unlocked (which it has to be to edit any subcomponents) the parent and all its locked subcomponents can still be moved, taking the locked items with it.

I’m going to have to do the whole 45-storey set of walls again, even if only to check which ones HAVE moved, and reposition them.

This seems like a bug to me. Here’s my bugged wall:
Arch 23 mostly straight columns and floor outlines.skp.zip (2.6 MB)

Here’s a correctly registered wall component at floor 12:

Note the clean corner where the pinkish/purple guide meets the white outer wall end, and the inner main wall with windows in it, and the triangular infill piece.

And here are the next two floors up, off by about 3/8", which were just as well registered before being locked.

It looks as if I shall have to explode this section of walls and lock them individually in the context of the overall model.

Will that stop them moving?

I’m not exactly following what you are saying.
Locked groups and components are locked only to the axes of the context they are in.
Being in a context one (or more) level(s) up does not prevent moving the content that contains a locked nested group or component. Is that what you are questioning?

Yes. In retrospect, perhaps it is logical, but I had expected a locked component inside an unlocked component to stay fixed in World axes location.

So, perhaps, by design?

It still seems somewhat counterintuitive for a locked component to be able to move, and has certainly caught me unawares, and badly bitten as a result.

I think I previously made a feature request for something between Locked, and Unlocked - like ‘Frozen (immoveable), but copyable’.

Maybe two levels of locking? Relative (to parent component), and Absolute (relative to World axes?

I’m not sure what issues / unexpected behavior locking nested components to the worlds axes would cause. To me the way it is now seems “natural”. I need to re-think about the other option though.

This will be my third or fourth attempt to draw these walls accurately. Every previous time, I wasn’t bothering to lock anything, and found that almost every wall I had previously worked on had moved or rotated, so nothing fit at the end, even though every level had at the time I drew or edited it.

I probably should have thought more carefully about how locking works. I’ve never previously worked on such a big and complex model (with Scott Baker, @NewThinking2) so the issue hasn’t previously arisen for me. This is just a small submodel of the whole, which has tens of thousands of component definitions, tens of millions of edges, and a file size approaching 300MB.

Many nesting levels of components, and (as you see in these walls) complex geometry.

So a steep learning curve for both me and Scott - for whom this is his very first Sketchup model.

Talk about jumping in at the deep end!

Anyway, thanks for the clarification that this is designed behaviour.

I’ll mark your post as the solution - it explains what’s happening, and why. Thank you.

Seems reasonable in retrospect, just not what I expected.

Another weirdness.

I have the section of walls from 23-32 in one component, with individual walls locked but not the parent.

When I open one wall component for editing (because I think its contents are slightly off-axis) and I want to change the component origin) but do nothing else than OPEN it, all the other walls in that component jump their position visibly by over 2" on the world red axis.

They stay moved when I close the component without making any changes. And now they don’t align in rotation with the other ends, even when I move them back to their correct positions.


Looks to me as if I need to explode the walls so each individual one is in the main model context, then re-combine them into a parent component. The way I’m doing it now leads to madness.

Compare SketchUp’s behavior with you being on a bus, sitting somewhere, seat belts fastened. You have a watch on your wrist.
You and the watch can be (and will be) moved in the worlds axes system when the bus starts moving.
But you can’t move in the bus.
With no seat belt fastened you can walk up and down the aisle, not fixed to the bus’s axes. Your watch is still on (/“locked” to) your wrist.
As I said, it seems completely natural to me.
Your second option, locking nested entities to the world axes, puzzles me.

It may not be a good idea, and could have unexpected consequences, so perhaps I won’t pursue it.

But if several ARE locked relative to the parent component’s axes, why would they all move when ONE like component is opened for editing, and stay moved? But the opened one DIDN’T move.

Agreed, to open one for editing, you have to unlock all. But why do they move their own origins in both world and parent axes when unlocked, when as far as I know the parent hasn’t moved, and their own contents haven’t been moved relative to their own origin in the component?

The component I opened for editing, then closed without changing anything, did NOT move.

That I just DON’T get.

This is something else and yes, this might be a bug that has been brought up (again) a few days ago.
Someone had a large model in size and space with many seats in a theater. Some seats jumped (rotated) when opening one for editing. Even without making any changes to the seat component.
I’ll see if I can find it (a few days ago).

I remember reading that.

It might indeed be another manifestation of the same or similar bug - related to move rather than rotation.

PS. Minor correction I should have made to what you last quoted:

I want to change not the component ORIGIN (my mistake) but the orientation of the red and green axes, which were slightly off the line of the long edges - the bounding box was visibly not on the component long edges.

Found it:

Thanks - that’s the one I looked at too when it was first posted.

But my components aren’t far from the origin (well, less than a thousand feet, which is nothing for SU).

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.