ccarpenter18

Thanks Michael! (My delay in responding was due to trying to click the download in the email sent to me by Chief rather than inside the Chief Forum environment and getting an error). Your code is similar to something I had been playing with, except that I was going after the word "each" in the Price field rather than the hyphen in the Size field. Discovered that "each" is not really part of the variable and is added by Chief dynamically. Besides, I knew generally that using information from the same field you plan to modify is not likely to work. So that was a show-stopper for me. At any rate, I'll incorporate what you sent me and if I need further (paid) assistance I'll contact you. BTW, you are very kind to provide this code snippet! I wasn't expecting anyone to actually code anything on the spot. Was just asking around to see if someone else had run across the same problem and had already coded a solution. Thanks again, Chuck

No problem. I wasn't assuming you were offering macro services. Was just trying to get a sense of the rules of the road, at least as to what one could expect on these forums. Thanks.

Ridge_Runner, I'm not in the market to purchase a custom macro, if that is what you were suggesting. I had assumed these forums are exchanges of free ideas and code that have been developed within the Chief user community for love of the product and the subject. I understand we all have to make a living, so I'm not opposed to the concept of fee for service as a general proposition. It's just that I can't afford such an undertaking at this point.

I was a software developer for many years but am brand new to Ruby. Know just enough to be dangerous! Are there any docs that go rigorously into how to access all the Ruby contexts and NVPs available in Chief? The one chapter on Ruby in the Tech Doc doesn't say much on this.

I've used Chief since X6 but am new to these forums. Perhaps I selected the wrong one? My SSA support person recommended I ask around in the forums to see if anyone had worked on the general topic of using Ruby with material lists. I see Alaskan_Son inquired about this issue earlier so I suspect he will raise it elsewhere if he feels its important enough to pursue. Thanks.

I'm trying to avoid a lot of manual insertion in the material list each time I toggle the SMR List Type. Also, I regenerate the material list often. In theory, at least, a macro in the Components Price column of each member could be designed to use the Ruby context of the material list line. Once the member is used in a material list, it could use the material list context to sense the SMR List Type being used and whether the line represents a "per foot" or "per member" type of calculation to come up with the right pricing. Of course, the BEST way to lick this problem is to do a Chief redesign so that the components panel always assumes a price-per-length value AND the material list uses the price plus the member's length (when appropriate) to calculate a price-per-member. Short of that happening, I thought someone might have figured out a way to use Ruby to get around the problem.

Kbird1, I'm using just the default Structural Member Reporting list. I'm toggling the reporting method on the material list itself (button on the upper left) as I described above.

I've attached 3 photos of a material list. The framing members appearing here all have a price of $0.58 as recorded in the Price variable of each framing member's Component Panel. It is intended to be a "per foot" price. The first attached photo (linear.png) shows the material list. Note the "Linear Length" structural reporting method selection in the upper left. This method shows an accurate subtotal price ($349.57) for framing. Buy.png shows the same list with "Buy List" selected. Note that the subtotal is substantially smaller ($46.98). This is because Chief is still using the "per foot" price from each member rather than a "per member" price*, which is what it should be doing if the pricing is to be accurate for this type of reporting. Finally, Mixed.png shows the same framing for "Mixed Reporting". Half the list is "per foot" and the other half is "each" (ie "per member"). The subtotal price is $160.19, which is also inaccurate. Since all prices are coming from the Component Panels, I'm wondering if there is a Ruby script, or at least Ruby NVPs I can use to adjust the reported price in the panels depending on how the price data is being used in the material list. Hope this makes it a little clearer. I'm not sure I have a solution. For now I just ignore pricing in the material list for anything other than "linear". * or "per unit" price as I was using earlier -sorry if this caused any confusion

In X12 I've noticed that when using Structural Member Reporting in a material list, the price column in the list does not appear to be sensitive to whether a "per unit" or "per length" calculation is being performed by the material list. In both cases, the material list appears to use the same Price variable in the Component Panel of each object. Does anyone know of some Ruby scripting that could be used to correct this? Off hand, I'm thinking of a macro inserted into the Price variable on the Component Panel of each structural member that would use the Material List row context to report a price that depends on how the row wants to use the Price.