Malcolm,

Would you be able to share a minimal script + swf that demonstrates the problem? Then I could load it on my various test setups and see if there's a pattern.

Super-hacky workaround idea: one might be able to set up an onKeyPress event listener at the HTML level, and then pass the captured enter key to flash via javascript. (What I don't remember is if the window even receives key presses when focus is on the Flash movie...)

Cheers,

@thomthom said:

hmm... what about custom attributes? In case the DC you replace with isn't identical?

What I do currently is:

1. Make a list of all custom attributes in the old component
2. Delete the old component
3. Insert the new component in its place
4. Make a list of all custom attributes in the new component
5. For any custom attributes with the same name in both components, overwrite the new values with the old. (So if there was something called "WoodFinish" on both, I assume that you want to preserve the old WoodFinish selection on the newly inserted comp.)
6. Fire a redraw of the new DC, so it makes itself pretty.

So I only copy over shared custom attributes.

@thomthom said:

Is the "Swap Component" readable or scrambled? (if I dig into the DC source code)

Scrambled. Plus, it's written in the context of being inside the DynamicComponents object, so I'd have to refactor slightly to make it work as standalone code. Happy to do it, but it might take me a few days to fit it in.

Cheers,

@thomthom said:

I'm wondering, if the components are DC, will they scale properly if I copy the original transformation to the DC replacing the old component?

Well, not really. When you scale a DC with parts that position themselves, the parent component's transformation doesn't actually change... it's the parts whose transformation changes.

For example, if you make a window 2x wide, what really happens is that the window itself is set back to 1x wide, and then the subparts are transformed inside the definition.

So probably the approach you'll want to take is to apply all of the attributes (like LENX, etc) that are on the old instance to the new. There is a right click > Dynamic Components > Swap Component item in SU Pro that does just that, but only one component at a time. Let me know if you'd like some sample code to work from.

Cheers,

@thomthom said:

Also: is there a way to work out if two components derives from the same DC? I'd quite like to incorporate into my Selection Toys plugins a method that allows you to select all components of the same family type.

There is an attribute dictionary called "dynamic_attributes" that contains all of the DC attributes. You'll find it attached to each DC definition.

Inside there you'll find an attribute called _name and a timestamp that is updated each time a DC is altered via the Component Attributes window. These should be sufficient to determine if things are related (though it could also lead to confusion if you happened to base one family off of another... so it might not be what you're looking for.) If you want something more explicit, you might want to just create a DC attribute called "Family" that is your key for doing the work.

Sounds like a fantastic script idea. Let me know if I can help. PM me if you need any offline advice.

Cheers,

There was a lot of debate about this before launch. We wanted DCs to follow the rules of SketchUp as much as possible. So the question became: "If I have 3 DCs in a model, and I scale one of them, should all of them update? Or should only the one I scaled?"

I think you can imagine what the arguments on both sides were. In the end, we thought it would be more frustrating to have every instance in the model update instead of just the one you scaled.

We've talked about adding some kind of toggle that would allow you to choose which behavior you prefer. Any thoughts on that? Do you guys think we did it backwards? I'd love to hear your ideas.

Cheers,

We already have pushed some small updates since the initial release, and we're planning another in the next few days. So please post any typos or suggestions. Thank you, everyone!

We also created a new homepage for the Google Developer's Group, which includes a link back here to Sketchucation:

http://groups.google.com/group/google-sketchup-developers

Cheers,

Bugs noted. Thanks, guys!

We fixed some WebDialog mac bugs with 7.0, but there's obviously still work to be done.

Cheers,

I'll be there. I went last year and it was incredibly fun. I'm not sure who else on the team will be going or what exactly we'll be presenting. But there are lots of fun and exciting things going on with Google APIs, and IO is a fun way to learn more.

We don't know exactly what will be presented yet. We'll have a booth and there are always parties and stuff where you can hang out and network.

-Scott

Mocathe,

This problem is somehow familiar to me. It's been a while since I did serious flash work in webdialogs, but I do recall having a problem like this. But what I can't remember is what I did to fix it.

A few questions that'll help me help:

1. Are you on a Mac or PC? If on a PC, what version of IE do you have installed?

2. If you bring up a basic HTML form, does the enter key work? Or is it only flash text entry?

3. Do you see the same problem regardless of what tool you have selected in SU?

Cheers,

A bunch of fixes got pushed on Friday. Thanks again to folks who found typos, both from this thread and from the wiki documentation. Keep 'em coming!

I'm on vacation for the next week, so don't think I'm ignoring anyone if I don't reply for a few days. Thanks, guys!

@avariant said:

I'm pretty certain the material observer is completely wrong. The base class defines all but two methods incorrectly, and doesn't appear to use them all that correctly either.

Attached script demonstrates using the MaterialsObserver as documented. The base class may not have all of the methods correctly implemented, but SketchUp will call them.

As the docs say, the onMaterialRemoveAll does not fire in a particularly useful way.

Let me know if you find anything else! Thanks!

materialsObserverTest.rb

@chris fullmer said:

But is the SU Ruby code documented in a similar way to rDoc or something? Is it set up so that you guys can change the documentation, then run some rDoc like command on it and it automatically updates the website?

Yes.

We now generate the docs directly from source code comments, using something like rdoc. So we make a change to the source. It gets code reviewed and checked in. Then we push a button and it all goes onto the new site.

So... there are likely some "autogeneration" bugs that we will all discover over the coming weeks. Not to mention plain old human error. Which, by the way, is why the get_glued_instances method isn't up there. Remus is right, that was added with M1 and I am a bonehead. Fix coming!

Thx,

@chris fullmer said:

Jim just pointed out this method and I noticed its missing:

Face.get_glued_instances

Hey Chris (or Jim),

I don't think that's a standard method... (am I wrong?) I went to go add it to the docs, but I can't find it. Maybe it's part of some script out there?

Let me know,

Hello everyone,

Yes, we just launched some new docs for the Ruby API on the code site. These are the most accurate and up to date documentation we have ever had, and we hope that they are useful. (That being said, there is obviously still room for improvement.)

Your help in finding typos/missing details are very welcome! What isn't evident just from glancing at the site is that we have a new process internally for maintaining and updating the docs that will help us be more responsive to changes from here on out. (ThomThom, I've already pulled in your questions/corrections and will be pushing them out soon.)

By the way, HUGE thanks must be given to the people who worked on the wiki-enabled docs over the last couple of years. We integrated those community changes, and I'm currently doing a review to make sure that any changes from the last couple months are reflected in the new docs. Thank you! (The wiki docs are still up for now, and I will continue to monitor them for fixes.)

http://code.google.com/apis/sketchup/

Keep the corrections coming!

Hey Thom,

The weights don't strictly have to be between 0 and 1 or add up to 1, but that's generally what you want. What's happening is each vector's length is being multiplied by its weight, and then they are combined.

Here are some examples:

# This yields Vector3d(0.5, 0.5, 0)
Geom;;Vector3d.linear_combination 0.5, [1,0,0], 0.5, [0,1,0]

# This yields Vector3d(1, 1, 0)
Geom;;Vector3d.linear_combination 1.0, [1,0,0], 1.0, [0,1,0]

# This yields Vector3d(2, 1, 0)
Geom;;Vector3d.linear_combination 2.0, [1,0,0], 1.0, [0,1,0]

# This yields Vector3d(2, 1, 0)
Geom;;Vector3d.linear_combination 1.0, [2,0,0], 1.0, [0,1,0]

Best way to get your head around it is to type some variations into the console. (That's what I did. Let me know if you see any weirdness and I could peek at the source code to be sure. )

Cheers,

The attached SKP demonstrates. I tried to keep all of the driving formulas at the top level and as simple as possible.

Cheers,

BifoldCabinet.skp

The Generate Report functionality always reports in inches. This was something we consciously decided to ease programmatic processing of those reports. If you write a program to read the CSV, you know what you're getting and can convert to whatever units you like.

If you are a Ruby API programmer (or wanted to hire one to help you), you could easily write your own reporting tool inside SU that generates whatever units you like. In this post you can download example Ruby code for generating custom DC reports:

http://www.sketchucation.com/forums/scf/viewtopic.php?f=15&t=15244&p=124401#p124392

Cheers,

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:

1. I draw a 4-piece frame that is 100cm wide
2. I look at it inside the Component Attributes window and its LENX is 100cm. So far so good.
3. 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.
4. 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

@august said:

YouTube says: "We're sorry, this video is no longer available."

Any alternate sources?

Hey August,

I've sent a query to the code site folks asking what happened to the video.

Thanks!

We summarized the new SU7 features in a blog post:

What's New in SketchUp 7

Posted by Scott Lininger, SketchUp Team SketchUp 7 contains several improvements to the Ruby API. Here's a quick tour of the best changes. I...

(sketchupapi.blogspot.com)

I can't give an exact date for the detailed documentation. We're working on it.

Thanks,