Sinks in Cabinets - access to data ?

[Joe_Carrick 2389]

When a Sink is added to a Cabinet, Chief just creates a 2D CAD Block.  I can select the cabinet, tab to the sink and open the dbx.  The sink can also be shown in a fixture schedule.

 

However, if I try to get the name/value pairs (attributes) for the Sink I only get the attributes of the CAD Block.  There doesn't appear to be any reference to the sink in the Cabinet attributes either - except for "has_appliance_or_sink" true/false.

 

Does anyone know how to get to the Sink's attributes?  I would like to include some of the Sink information in the Cabinet Schedule or in a "Note".

 

[Joe_Carrick 2389]

37 minutes ago, Dermot said:

Place the sink as a free standing fixture first and then just drag it over the cabinet.

OK, but that bypasses the automatic placement of the sink.  Shouldn't there be a better coordination of the data when sinks are placed in cabinets?  I guess I'll need to put in a feature request.

[Joe_Carrick 2389]

Thanks Dermot,

 

Since there usually are not that many sinks in a plan, I don't think there would be much "bloat".

[Autocad1234 2]

Probably no one will see this but, what?  Plan bloat? Try trimming some of your code.  This is not a viable solution but just another CA band-aid/work-around.

[GerryT 48]

On 3/11/2020 at 12:21 PM, Dermot said:

When you place the sink directly into the cabinet, we only store a minimal subset of the sink data.  For most people, this is the most efficient way of doing things and avoids extra plan bloat.  For an advanced user who is trying to get more control, placing the sink as a free standing sink will allow them to do the customization that they want.

 

I think Mr. Dermont's response is a little misleading. And, at the very least, I believe we can agree to disagree.

When a symbol is brought into a plan, only the GUID ( or some form of it) is stored in plan within the Ruby class within the Ruby namespace. The attributes are not stored in the Ruby Namespace but are just class function calls to the plan data. This keeps the data private and read only. Therefore, it does not matter whether the sink is in open plan or within a cabinet. The memory is the same. You can test this by setting the sink's owner to a global, than equating that to a custom attribute of the cabinet, which then gives you access to all of the sink's attributes in any cabinet schedule for that cabinet.

 

The problem is that if you then delete the sink before deleting all of the macro references, the program will throw a uncaught memory error and you will lose all your work. You are essentially trying to address deleted memory. Chief has been aware of this for years and has been very clear that they will never fix this problem for whatever reason?

 

My point is, i see no technical reason not to allow access to the child data of a parent ( they do this already with rooms) and I find Mr. Dermont's explanation to be a little insulting? But I do agree that Chief has the perfect right to structure its software as it sees fit.

[Joe_Carrick 2389]

On 3/11/2020 at 9:45 AM, Dermot said:

We don't just do it for sinks though.  We also do it for all of the appliances as well as the cabinet doors, drawers, panels, hardware, feet, pilasters, etc.

Dermot,

 

This is no longer true.  Cabinet Doors, Drawers, Panels, etc are now included in the cabinet attributes. 

 

Your argument about "Bloat" doesn't make sense.  You suggest that we could put the sinks, appliances, accessories, etc in as freestanding objects instead of inserting them.  If "Bloat" is really the issue then doing what you suggest would cause it.  IAE, the number of sinks in a plan is never as much as the number of windows & doors. 

 

BTW, The Fixture Schedule can pick up the data from these items so why can't they be included in the attributes of the cabinets.

[Dermot 628]

I apologize if any of the information I have provided was not helpful.