Weird behaviour from View.zoom & zoom_extents -

If one has the component edit>hide rest of model turned on then using either zoom or zoom_extents does nothing like the doc claims it should - the resultant view has the nominated entity as a tiny dot in the far distance. If however one has hide rest of model off then both routines do what seems sensible - the component is nicely sized in the view.

That seems like maybe it's a bug. I didn't see much discussion of similar issues beyond a 2007 message relating to nested components causing problems. Has anyone else noticed this? Devised a work around?

Version 0.2 updated to-

• wrap the routine in start/commit_operation. This noticeably speeds up dealing with many components. It should also make 'undo' work better but Pages do not get removed by undo so something ain't raht.
• zoom to the extent of each component when creating the page for it
  See first post for download.

That's the usage I put in - with the second parameter 'true'. It does indeed speed up making many scenes, quite noticeably.

I haven't fully characterised how many scenes need to be undone to cause a crash (EDIT - I said originally 'kill' and I realised you might be thinking 'slow down horribly' rather than crash, burn, quit rudely etc) but since 'a few' works OK (except for the damned pages staying in place instead of going away) and 'a few dozen' crashes, I guess it's somewhere in the middle.

Pirun - lovely, stylish, clear drawings. Nice. I've made plenty of good, solid, descriptive drawings but - like Sonder - you've made something positively artistic as well.

I'm going to toot my own horn a little here because I've just released a plugin intended to help with getting things set up to make doing the LO pages for components easier. See http://forums.sketchucation.com/viewtopic.php?f=323&t=45790

My first version of an attempt at solving this is http://forums.sketchucation.com/viewtopic.php?f=323&t=45790

I've been trying to make nice with the undo system (firstly by wrapping a start/commit around the code) and I notice that when attempting to 'undo' after running my ComponentScenes plugin the pages created are not removed. (I further notice that manually created pages appear to not go away with manual undo.) The created layers and copied components all disappear politely. 'Undo' on a model where a large number of components were processed tends to kill SU completely, which is unfriendly.

I see the ModelObserver operation methods listed but can't work out how to make use of them from the doc found so far and in fact ThomThom's list of observer issues suggests maybe it wouldn't even work properly. Has anyone found a good explanation of how I might improve my undo/redo?

@dan rathbun said:

But there are only two methods that begin with " close..." in the

Yeah but you know what it's like - you are searching for something for which you have no idea of the name, try all sorts of combinations - exit, stop, abandon, cancel, whatever - and when you give up and ask for help it's always the most embarrassingly obvious choice that you never even considered. This is why getting forgetful in older age is so infuriating.
"Um, strawberry-ish. Red thing. Flower?"
"Rose?"
"Yes - spectacles! Thank you!"

Thanks; that's even pretty damn obvious once you know it. Good point about multiple levels of open as well; hadn't considered that.
Maybe it would be best to leave things as they are...

I am unable to find the api to close a component that is open for editing; I've searched for terms that seem plausible like 'close_edit' and exit and clear and selection and so on and on. A list of methods is all very useful when you have a decent idea of what your target might be called but not so much fun otherwise. Simply searching the forums dumped so much on me that I almost fell asleep reading through it. I was anticipating something along the lines of "Sketchup.close_open_edit()'.

My ComponentScenes plugin can be used when a component is opened up and sub-components are selected. At the end of the function I'd like to close the edit because it seems confusing to have the edit context make the 'new' components created non-visible (depending upon the users settings for 'view>component edit' of course). One might argue that users should be aware of their own setup but I think it worth trying to be helpful. If it turns out to actually be helpful, of course.

Here's an example skp file and layout file to show what it does.
Pine bed example SU file
Pine bed LO file

The skp started as a single page with the bed model. I d-clicked on the bed component to open it and selected-all. The plugin created the slat, side, headboard, footboard and mid rail pages. Since the headboard and footboard are composed of further components I also opened them and repeated the process, creating a sizeable list of other pages with each individual component on its own page.

The model was sent to Layout and just as an example I created a detail page for the post from the headboard. Since the post exists on its own scene I could have a total of five views on the page, one each of the left/right/front/back view and an iso view for context. Without any other components in the SU scene there is no clutter to worry about in Layout.

Here's a first attempt at a plugin to build a set of pages that show one component each, ready for Layout to embed and dimension etc.

Usage
Select one or more components - even inside another component - and from the plugin menu 'Build Component Scenes'. You should see a number of pages appear, each named after the components chosen, Each page will have one component visible on a layer named after the component. When you open the model in Layout you will now have a nice convenient way to do individual component drawings.

I've tried to make this idempotent - if you repeat the command you should get the same results each time with no interference between the sets of pages. Pages seem to be happy to share names whereas Layers seem to prefer unique names and there shouldn't be any clashes.

The current To-Do list is

Make this an extension later http://sketchupapi.blogspot.ca/2011/07/turn-your-plugin-into-extension.html
Package as an RBZ file http://sketchupapi.blogspot.ca/2011/12/rbzs-in-sketchup-8m2-distribute-your.html
Do not make scenes for duplicate components

• (how to decide this? scaling, shearing and flipping in the component transform can make two apparently equivalent components NOT duplicates).
  Make undo/redo friendly.
• first pass at this is to wrap the main routine in start/commit_ operation

but it doesn't remove created pages and

SU crashes completely if it tries to undo a lot of component pages

Find a way to close any open component edits after making the component pages so that the components don't appear to be missing; you could argue that the user should understand but never underestimate the confusion of users. On hold for now because it would surely annoy users to lose an edit deep inside a complex model

Updates for v0.3

• attempt workaround for active_view.zoom failing to actually zoom to the chosen component

Updates for v0.2

• Wrapped routine in start/commit_operation, which speeds up dealing with many components.
• Zoom to extent of component when making the page.
  Download ComponentScenes
  version 0.3

Doc and code drifting is quite possibly one of the biggest issues affecting code maintainability. I've never quite got over the idiocy of a few people I've worked with that really took to heart the attitude of "documents and comments? Why do you think it's called 'code'?" Certainly when I was managing a team I didn't let anyone get away with that - at least where I could detect it…
An old colleague came up with a pithy way to describe what ought to happen - "don't document the code, code the document!"

I didn't know that there is a separation between Page and View; now I do, so thanks for that. The specific problem I had with my code was that with no named page in a fresh drawing simply adding a page, hiding everything, adding my new layer, adding the copy of the selected component and updating the page left an apparently mangled drawing because there was still only one page visible and it no longer had the main model visible. I can see that going down well with anyone trying out a new plugin! As a workaround I've made it add a default new page before adding my 'real' new page so that at least there is no nasty surprise.

Couldn't find any prior references to this matter -
Pages.add has two issues that I consider bugs.
a) when you add a page it returns nil, according to the official API doc pages. This would be a really daft thing to do but actually the code appears to do the right thing and returns the created page. So far as I can tell from testing, anyway. The API doc needs correcting.
b) If you add a page to a document that has only there default first page (i.e. no set scene name) then you do not end up with two pages as one might expect. No, a single page - the one you added - is your lot. It seems that the default state for a new document is that sketchup.active_model.pages is empty. That isn't very logical to my way of thinking. At the very least a mention of that in the doc relating to Pages might be nice. I discovered this when my plugin code 'added' a page, set everything to hidden and inserted a new component. I was left with a model that only had my new page with the component visible. Workaround would seem to be adding a new page with some default name if the pages count is 0 before doing whatever else one was about to do.

Seriously? Those are real tables and chairs made directly from SU output? Very cool!

Damn. Thought I'd spotted a nice simple solution - ComponentInstance.equals? - which claims to compare the geometry. Sadly, that comparison seems not to care about flipping nor scaling. Poo.

@dan rathbun said:

See this topic:
The Transformation Matrix

I'd spotted that particular one and to my amazement found that I even remembered most of the matrix stuff mentioned. After a quarter century that is a surprise!

@dan rathbun said:

otherwise do a forum search on keywords liking "scaling" "transformation" (or both) etc.
(This is one of the most discussed topics around here, it seems.)

Also if you have the DynamicComponents extension loaded, it adds some scaling methods to Group and ComponentInstance.
Undocumented Geom::Transformation methods?

Hadn't seen that topic though; that's interesting but a bit worrying. If it is only added by an extension, I imagine I'd have to check that it exists and is active on the target system.

Still searching around for a way to actually derive from a transform whether the component is flipped or scaled… this is fun, For a certain odd definition of the word 'fun'.

Dan, I don't think I made it clear what I need to find out - or possibly I don't understand what SU is doing underneath.

It's not that I need to find out if two references to components are to the actual same component, but that I need to weed out instances of the same component definition. The complication so far as I can discern is that two components where the definition is the same can have transformations that flip them (like pairs of table legs where each is a mirror of the other) or scale them. They may be the 'same component' so far as SUs need for storage is concerned but not from the point of view of wanting to build a list of components needing a parts drawing in my LO doc. Scaled items need separate drawings for the different dimensions, for example.

To use the table legs example again, there will likely be one definition that is used four times with two of them flipped. There might be a single screw definition used a couple of dozen times, with some scaled to play the part of 1" #8's and some scaled to be 2" #10s and a few ¾" #6's.

@paul russam said:

I HATE SKETCHUP ON THE MAC

What problems do you have to make you so annoyed with it? Since I use SU on an iMac I'd be interested to know what you think I'm suffering from...

@fuzzion said:

Most software is designed around Windows. You can boot windows on a Mac, so the issue is preference and cost.

Well, yes and no. You'd be amazed how much software is written by people that know how to do a good job on both. And, for a $50 or so purchase of Parallels or VMWare you can run Windows (and linuxes, whatever) at the same time as OS X. It's not at all difficult to run TurboCAD under Windows at the same time as SU under OS X and gimp under Ubuntu. For work I've occasionally had three or four versions of Windows running at the same time to compare some app's behaviour. Mostly it reminds me why I dislike OS X less than I dislike Windows but that's neither here nor there right now.

I'd like to be able to detect when two components (don't care at all about groups or 'lesser' entities, though I doubt it makes much difference) are duplicates.

The obvious trivial test is to compare the component.definition.name but this takes no account of any axis flipping or scaling that has been applied. I'm not sure if there are any other attributes that should be considered yet. I suppose in some sense the applied materials might be important?

It's well over a quarter of a century since I last played with 4x4 geometric transforms (I wrote a really trivial solid modeller for a NatSemi 32000 based system I designed and built myself for a masters degree) and I'd rather not have to attempt to dig out that portion of my memory again; it's probably backed up on mouldy paper tape somewhere. I've been able to find some transform related extensions that TIG wrote up several years ago but I'm wondering if anyone has added code that could quickly compare two transforms and establish if they have nothing more than translation and rotation differences? I have a feeling that there might just be some neat trick to it. Like maybe applying the inverse of one transform to the other, cross-producting with the dot-product of jam and bread, adding the number we first thought of and then holding your finger in the wind to see if bananas are flying.