bigstick,

The technique that I've seen is to include all of your variations as subcomponents, and then use the "hidden" attribute to hide all but the one you want to show.

For example, if you have an attribute at the parent level called "panelType" that contains either a 1, 2, or 3, then your 3 subcomponents could have a formula to decide which is hidden.

Tile1:
hidden= parent!panelType<>1

Tile2:
hidden= parent!panelType<>2

Tile3:
hidden= parent!panelType<>3

At any given time, only one of the 3 tiles will be shown.

Hope I understood the question! Let us know if you have more.

Cheers,

@xrok1 said:

is it possible to have an alert popup with a link in it?

No, unfortunately.

@rickw said:

Using RD or RDoc style would be more consistent with the =begin/=end usage (rather than using it for block comments). Something like this?

Exactly. I didn't run this though RDoc to see the output, but my point is that RDoc is the closest thing to a docs standard that I'm aware of. Might as well build something that could be run through RDoc and give sensible output.

Now you should extend the template list and build a Ruby plugin wizard! (only half joking.)

Purely my bias, but I'd lean toward the RDoc comment style. Either way, this looks extremely helpful!

@thomthom said:

I'm thinking I just crawl my existing hash, all though it's nested. If it should turn out that it's too slow I build another un-nested hash for quick reference lookup.

That's what I do with DCs. Just build a hash of entities where the key is the id... then you get fast lookup later on, and you can use the valid? method to determine if something has been deleted since you added it to the hash. You can periodically clean it out to prevent it from growing too large.

I wish there were a generic way to grab things in Ruby, but I don't know of one.

Sounds like a very cool script, by the way!

Hey Matt!

Some strategies (highly dependent on the DC use, of course.)

1. Try to use textures instead of copied geometry where possible. (For things like tiled floors, this is a no brainer.) If you haven't seen an example of this, let me know and I could post something.

2. Try to minimize the number of formulas calculated within each child.

3. Skip auto-copying if appropriate. Create one configured DC, then use SU's regular copy mechanisms to generate the copies.

Cheers,

@thomthom said:

I made a property, Section length, which in the scene attached is 1200mm, but the DC Option displays it as 3048mm. (The whole model is in mm.)

Hey ThomThom,

The units assigned to your Section_Length attribute are "Text" with a value of "120". When you set the "Display in" units to mm (or, in your case, default it to the model units of mm), then we have to do a conversion from "text" to "mm". The conversion engine assumes that raw text strings that contain numbers are inches -- which is the weirdness that you're seeing.

The fix is easy. Go into your Attribute details and change the units from "Text" to "Cm". Then the conversion engine will understand what you mean better, and you should see what you want. (Note that when you change this unit, the engine will automatically do the conversion from text to cm... so you'll need to change the attribute value from 204.8cm back to 120cm.)

Let me know if you have more questions!

Cheers,

Hello trickout. Terribly sorry for the broken link. Please try again.

Cheers,

@jim said:

This is something I've been thinking about but haven't investigated - Can the DC Javascripy/Ruby library be used by user-created scripts? Are there possibly some JSON functions in there that we can use for passing strings between Ruby/Javascript?

Jim,

Yes. That's exactly what the Dynamic Components do. You can create a JSON string inside ruby, and then use WebDialog.execute_script to push that data up into javascript and do something with it.

In this thread we just posted an example script (ruby only, no web dialogs) that might be helpful.

Cheers,

Dik,

See attached for an example script for creating reports from Dynamic Component attributes. We tried to make it as instructive as possible, but please feel free to ask questions.

I'll ask Simone, who wrote the script, to jump on this thread to help.

Example script for reporting (CSV, HTML) on DC Attributes

Thanks, Todd! That'll do nicely.

Hey guys,

So I'm trying to override the UI::messagebox method so it doesn't bark at me while I'm running a bunch of unit tests. That bit was easy...

def UI;;messagebox(params)
  puts 'TEMPORARY OVERRIDE; UI;;messagebox > ' + params.to_s
end

So far so good. But once I'm done with my tests, I'd like to return control back to the default UI.messagebox. I tried various flavors of the alias and alias_method keywords, but those don't seem to work with modules. I'm certain there's a way to do it, but I thought I'd ask here before diving into my Ruby books. Hopefully it's a simple syntax hiccup.

Thanks in advance, oh Ruby masters,

Hey everyone,

The underlying DC engine can support other unit types, so we may support mms (or furlongs for that matter) down the road. We wanted to keep the DC user interface as simple as possible for V1, figuring we'd learn a lot and be able to make improvements down the road.

The reason we chose CMs as the "standard" metric unit is because it's closest to inches, so if one toggles back and forth between metric and english your formula-driven DCs don't go microscopic or ginormous at that moment. The formula LENX=100*2 is kinda close between inches and CMs...

So there was a reason. Hope that takes the sting out of having to shift your decimal points all the time. Vote for mm support duly noted. Thanks!

Cheers,

That's a tough one. We chatted about allowing local files to be opened, but there are all kinds of security concerns with that, so we dropped it from V1.

I've added a feature request to our list so we can revisit it for future versions.

In the short term, might a password-protected web repository be suitable? You could give a password out to all of your users that allows them to get at the PDFs. If you set up the login to be cookie-enabled, they would only have to log in once and then could get at all of your resources.

Feature request recorded. Thanks!

Also, there has been some discussion about adding a redraw option for Free users as well. Even if you're not authoring, there are times when redrawing is desirable. (Like, after you manually edit some geometry.)

Cheers,

Hey guys,

I've filed a bug. If any old-timers remember seeing this one from the years of yore, please let me know.

Thanks, Chris!

Cheers,

Hey Thomthom,

Is this happening for you in SU6 or 7 or both?

There were a whole class of what we called "iterator" bugs that we fixed in SU7. These had to do with looping across entities in models. This crash sounds like it's similar.

Cheers,

@danieldaniel73 said:

Hi BillW...
Have you found any solution on the parent!parent! issue?
I need to call a custom attribute from the toplevel component to apply on my sub-sub- component.

Hello Daniel,

Currently, you are only allowed to reference attributes in the parent or in children. If you need a custom attribute of a grandparent to drive a formula inside a grandchild, you have to do it with two formulas instead of one.

Inside the grandparent:
CustomWidth = 10

Inside the parent:
InheritedWidth = parent!CustomWidth

Inside the child:
MyWidth = parent!InheritedWidth

The idea is for each component to live in its own little world, and have the list of what's configurable be dependent on the parent it's inside of.

For example, if you were designing a set of cabinets, you may have a subcomp called "Drawer" that has 10 configurable options on it. But as soon as you nest that inside of a "Cabinet", you may choose to only create pulldowns for 3 of those (by wiring the drawer attributes to be driven by the cabinet's).

At least, that's the vision. There are certainly ways that we can think of to make all of this easier, so please keep the feedback coming!

@peweuk said:

It would also be a nice touch if it was possible to easily control the order of the input boxes in the 'Component Options' window.

I agree.

The only way to do it now is to name your custom attributes with intentionally alphabetical names. Hardly intuitive.

@unknownuser said:

It sucks when you have repeating SC's that are not next to eachother in the list.

I agree, and it's on the list. Thanks for the request.

I love it when people pile on to feature ideas that they agree with. Helps me prioritize stuff.