We are undergoing an improvement on how components are used and handled in the MultiSurf model. Here are some comments Reinhard Siegel offered upon seeing the development effort and he also adds valuable tips on how he manages components now. I have interspersed some tips of my own in his text.

> When I look through my library of components, there are hatches, doors,
windows, winches, blocks, fairleads, traveller, mast, boom, rigging wires,
stanchions, etc. Their common property is: an assembly of objects, that
depend on one single base point. Thus when loaded into a model, the only
parent for the component is a point entity (insertion point ip_xxx).
Dragging that ip moves all the entities that were in the component "xxx". To
access those entities conveniently I make entity lists:

> 1) an entity list "View_xxx", that holds the final, presentable objects to
show
2) an entity list "Edit_xxx" with "handles" or "grips", that allow
modification: winch meridian shape, stanchion height and diameter, hatch,
window, door dimensions etc.

RP - This entity list is a convenient way to form the content of a custom Real Values Dialog (RVD) for editing the component. The Entity List above should contain only Variables or Formulas so it will yield a RVD when the Entity List is selected.









> So by the "View_xxx" entity list the component can easily selected via the
Entity manager for hide, show or save actions (for example a Pov-Ray file).
Selecting the point "ip_xxx" and all its children is the road to remove the
entities created via component from the model.
>
> Of course, entity lists like "View_xxx" and "Edit_xxx" are not restricted to
objects created in a model via Component Load. I use them extensively to tie
a group of things together for fast selection - show, hide, save.

So far to my practice. And I must admit, it has been working fine for me.

Reinhard has seen the Development version and is commenting on same...
>
> And now there is a Component heading in the EM. Can it be an improvement?
Can it help to make the construction of a model easier to understand, easier
to edit? Similar to procedures and modules in a program code?




When experimenting with the component "entity" I thought: this smaller tree
of only the contributing entities is good - less objects, all in one part of
the tree, thus more clearness, easier to understand, easier to adopt to
specific requests.
>
> 
So I agree with your proposal to list component entities only under its
component heading. I much agree with your idea to indicate the parents of
the component (display in red). I strongly suggest to make them inactive,
that is, selectable, but not further expandable. So the user has a clear
indication of their function - the link between the group of entities and
the main model body.
>
> When talking to users about components, it soon comes to the question: can I
show/hide them with a click? They have in mind a subset of the entities in
the component, the presentable or final entities. They consider the
component merely as an assembly of finished surfaces, that needs to be shown
or hidden.

RP - Yes, this development build will be available for for inspection very soon.
>
> If we look at a component as a separate entity, could it have (beside its
other properties) the property "Visible Entities"?  Then Show/ Hide could
refer to this list.

 
> So far for now. I do hope, this lines are of help to you and the MultiSurf
development team. Much progress.

With kind regards,

Reinhard