Puzzling position of axes when inserting a component

tim

As part of my ComponentScenes plugin I've been trying to change the code to insert the component into its special view centred nicely; in the hope that Layout will behave a bit more pleasantly when zooming/scaling (but that's another story).
I've successfully got things so that the component is indeed centred correctly on the global axes; at least, I think so. If one turns on the layer for the single component it appears in the place I expect however on the page added to display the component the axes are not in the same place. This is very vexing. So far as I can tell the 'false' axes are actually the axes of the component to which the singled out component used to belong, which makes no good sense to me at all. After all, I'm inserting the singled out component directly into the top level of the model, not back into its original 'owner'. At least, I hope this code does that -

		newItem = entitiesList.add_instance(thisItem.definition, transf)

A top-level component that is chosen will appear correctly centred, presumably since it is considered to belong to the same owner as before.
Example:

a set of closet doors consists of two copies of the same component with one a mirror of the other.
each door consists of a pair of stiles, two mid-rails a top rail and a bottom rail.
select a door and use 'component scenes' and a new page is created that displays the new layer that a new copy of the chosen door is placed upon. The centring is correct both in the original overall view and the new component view.
select a door, open it for edit and select one of the rails to use with 'component scenes'. The new page shows the component not centred on the axes. BUT go back to the overall view, select the relevant new layer to be displayed and the component pops up centred exactly as I expected.
Err, WTF? Where are the 'phantom' axes coming from? In particular, why would said axes appear to be based on the axes of the owner-component that the component used to but no longer belongs to?

Dan Rathbun

Axes are one of the properties, that can be saved (and I think are, by default,) in a ScenePage.

This means that custom manual user set Axes (via the AxisTool,) can be set and saved in a Scene.
Or the WorldAxes (aka GlobalAxes,) if they are the axes that are currently set for the page, when it is updated (ie, all it's properties are saved.)

When a new scenepage is created, a COPY of the current page is used to create the new page. So whatever Axes are set for the current page, will be dup'd into the new page.

So.. sounds to me like you may be inside a group or component editing context (and so that parent's axes is current,) when you create the component-copy-scenepage.

If that's the case.. just get a ref to the nested component... then back out of the editing context(s) model.close() until the context is at the model context ?? model.active_entities==model.entities
before you create the "part" scenepage.

Other than that.. there's no way with only one line of code, that we can tell what is going wrong. (You have references in the statement, but we have no way of knowing if you assigned those references correctly.)

tim

@dan rathbun said:

When a new scenepage is created, a COPY of the current page is used to create the new page. So whatever Axes are set for the current page, will be dup'd into the new page.

So.. sounds to me like you may be inside a group or component editing context (and so that parent's axes is current,) when you create the component-copy-scenepage.

Ah; right, that's the crucial bit of info I was lacking. Yes, the annoyance occurs when we have a component with sub-components, are editing the outer component, and thus have the outer component's axes on display. I hadn't ever really noticed the jumping around of axes before...

@dan rathbun said:

If that's the case.. just get a ref to the nested component... then back out of the editing context(s) model.close() until the context is at the model context ??

I could do that I guess but it seems like it would be a pretty annoying thing to have messed up the user's edit situation, especially if it had involved descending a dozen levels into a complex model. Hmm, I suppose it must be possible to record the chosen components that are 'open' on the way up and then do the component scene creation, then re-walk the list to get back to where the user had been.

Ta.

Dan Rathbun

@tim said:

Hmm, I suppose it must be possible to record the chosen components that are 'open' on the way up ...

No.. you grab them as an array from the bottom, using: model.active_path()

@tim said:

... and then do the component scene creation, then re-walk the list to get back to where the user had been.

Unfortunately.. the API does not have an "edit_open" method. (Which is weird because it does have a "close edit" method.)

A workaround might be, to have a "master" scenepage that you use as the "template" for these piece-part scenepages.
Switch to the template page, before adding the new page. (You may need to use a UI timer block, or a Pages FrameChangeObserver, to be sure the transition to the template is complete, before creating the new page.)

When done,... switch back to the "Edit" page.

Or.. you might try cycling the "axes" attribute of the new page:
page.use_axes=false
page.update()
page.use_axes=true
page.update()
See if that resets the page to "World" axes ?

Note: I've noticed quirky behaviour with the update() method. Sometimes I have to use: Sketchup.send_action("pageUpdate:")
Also.. currently this will rebuild ALL scene thumbnails whether you want this, or not; and can take some time. (We've asked that it be fixed to honor the thumbnail settings.)

Dan Rathbun

@dan rathbun said:

Or.. you might try cycling the "axes" attribute of the new page:
page.use_axes=false
page.update()
page.use_axes=true
page.update()
See if that resets the page to "World" axes ?

Ok it works with: Sketchup.send_action("pageUpdate:")

But in a quirky way.
It requires that you have a page with World Axes saved, to switch to (because using view.invalidate, view.refresh or UI.refresh_inspectors, does not update the axes display.)

So assume you have a page named ' WorldAxes', and the current page pgs.selected_page is a "part" page with the wrong axes saved.

To reset it to World Axes:
` pgs = Sketchup.active_model.pages
cp = pgs.selected_page
cp.use_axes= false
Sketchup.send_action("pageUpdate:")

may need a delay here

pgs.selected_page= pgs['WorldAxes']
pgs.selected_page= cp

may need a delay here

cp.use_axes= true
Sketchup.send_action("pageUpdate:")`

Dan Rathbun

This pattern, from the start, may work even better:

Again, there is a page named " WorldAxes":
` pgs = Sketchup.active_model.pages
cp = pgs.selected_page # (the current editing page)
np = pgs.add(newpagename,119) # 127-8

the new page is now the selected page

pgs.selected_page= pgs['WorldAxes']
pgs.selected_page= np

may need a delay here

np.use_axes= true
Sketchup.send_action("pageUpdate:")`

Dan Rathbun

AND.. lastly.. I am seeing an issue with the Axes display, and I cannot find any method that cause the Axes display to be refreshed.

I tried toggling them via model.rendering_options['DisplaySketchAxes'] but no joy.

SO... you'll need to save (or update the edit page,) with the current editing context axes, so that when you return to that page, the axes are in the orientation of the edit context.

` mdl = Sketchup.active_model
st = mdl.options['PageOptions']['ShowTransition']
mdl.options['PageOptions']['ShowTransition']= false
pgs = mdl.pages
cp = pgs.selected_page # (the current editing page)
Sketchup.send_action("pageUpdate:")

np = pgs.add(newpagename,119) # 127-8

the new page is now the selected page

pgs.selected_page= pgs['WorldAxes']
pgs.selected_page= np

np.use_axes= true
Sketchup.send_action("pageUpdate:")

pgs.selected_page= cp
mdl.options['PageOptions']['ShowTransition']= st`

I think you will need to track when edit contexts change, and implement a Sketchup::ModelObserver subclass. See:
ModelObserver#onActivePathChanged

In the callback, if the selected page is the "edit" page, call Sketchup.send_action("pageUpdate:") so the current edit axes is saved.

You realize all this is just to workaround a bug ?? sheesh

tim

Wow, thanks much for all that explanation and work Dan; it's amazing how much hassle can be caused by a simple seeming issue. At least this is merely a minor irritation rather than a life threatening disaster!

I get the impression from reading a lot of postings in this forum that SU needs a great deal more of the api exposed so that, for this case as an example, one could actually create a blank page and set it up as needed rather than having a rather cockeyed 'new' message that actually creates, does setup that isn't wanted and then leaves one to work out how much to undo… right now it isn't 'new' but 'copy'.

I guess my first port of call is thoroughly to test out the interaction of LO with what I have working in the plugin, since that was what triggered my attempts.

Dan Rathbun

@tim said:

..., for this case as an example, one could actually create a blank page and set it up as needed rather than having a rather cockeyed 'new' message that actually creates, does setup that isn't wanted and then leaves one to work out how much to undo… right now it isn't 'new' but 'copy'.

Well we are supposed to be able to do this with the flags argument in the add() method. see page.update() for an explanation of the flags.

What it is missing, is a camera argument. It assumes you wish to copy the current view.camera
So you have to modify the new page's view / camera after it is created. (It gets set to the current selected page, whether you want this or not.)