Forum Replies Created
-
Posts
-
That’s why, I think. The underlying Surface could be changed, and without running each parameter script again, the values in the objects would no longer be correct.
I have two notes: 1. It would be good for this to be up to the individual / BIM manager to manage – not to have this functionality shut out unilaterally. 2. Does the parameter script run when producing schedules? I don’t know.
Let’s take the specific example of the door schedule:
– we schedule the leaf finish, and frame finish in the schedule
– this finish needs to be a code, e.g. TM-104
– this needs to be read directly from the relevant parameters in the doors to ensure integrity of information: in this case “gs_leaf_mat”, and “gs_frame_mat”
– the Surface name in the project attributes is actually “TM-104: Timber oak dark stained”, therefore I need to SPLIT the Surface name so only “TM-104” will show in the schedule
– I cannot use a Property, as Properties cannot read object parameters
– I cannot use a SPLIT command, as I cannot REQUEST the Surface command in the Parameter script
– I cannot cheat by narrowing the column, as different codes have different widths
– I cannot change the Surface names to just be the codes, as there are exceptions to this that require the description
– I may be able to set up an IFC field that will SPLIT the Surface name, but so far I haven’t been able to get this to work – and there could be performance issues associated with this.I understand the reason GS gives for not being able to REQUEST the Surface name in the parameter script, but surely there’s a better way?
So I’ve experimented with the Master_GDL, and I don’t think it will do what I need.
On a project, the material codes are selected by the designer. There can be >100 selections, each with their own code (see example in my second to last post). The materials are NOT object specific: the same material can be used on doors (leaf, frame, glass), walls, objects etc. Therefore, we need to list the code when we schedule out our elements. I cannot figure out a way to do this in schedules inside Archicad. I suppose I could export the schedule to Excel, and run a formula in there – but it would be very handy to be able to extract this somehow inside Archicad.
Maybe the addition of an ID and Description field within the surface itself – similar to building materials?
I’m kind of stuck.
I don’t think I quite follow.
The same door library part may have different surfaces for separately placed instances. Our surfaces are named such (code + description) so they are a little more informative to the user; and there may be multiple entries of the same code, but with a different vectorial fill (e.g. timber grain direction), which requires a different descriptor. However, in the schedule, just the code is required.
I don’t think I can hard code the surface into the part.
I’m not familiar with master_gdl, as every practice I’ve worked for has prohibited their use. However, I might dig into it further.
I’m now running into the same problem with trying to intelligently produce door schedules with leaf & frame finish fields. I want the schedule to read the finish surface of the leaf or frame, and run a SPLIT or STRSTR command to extract the finish code from the description.
The problems I’m encountering:
1. I can’t run a REQUEST (“Name_of_material”,…) command from the parameter script – for the above mentioned reasons I’m presuming.
2. I can’t run a SPLIT command in the properties, as I can’t reach object parameters from properties
3. I can’t shorten the schedule column to obscure the description of the surface, as it adds a ‘…’ to indicate there is more information.This is resulting in three separate entries for the same data – not a good practice: 1. User selects the right surface inside the object. 2. User selects the finish code from a properties-specific options list for the leaf. 3. User selects the finish code from a different (but containing multiple duplicate values) properties-specific options list for the frame.
This is bad!
An example of a surface name would be “TM-104: Timber veneer” – and I just want the “TM-104” part.
Ideas?
Found it.
I needed to create a boolean parameter called “ac_bDisableLabelFrameDisplay” and turn it on. Problem solved.
Attachments:
reqNote = "Your Text Here" DEFINE STYLE 'txtStyle' LABEL_FONT_NAME, LABEL_TEXT_SIZE, 5, 0 STYLE 'txtStyle' ! Get the Height and Width of the displayed Text, convert it to model size r = request("Height_of_style", "txtStyle", _heightOfText_mm) _height = _heightOfText_mm * GLOB_SCALE / 1000 _width = STW(reqNote) / 1000 * GLOB_SCALE
