Sam Jones

Use the UID of the Lighting Device instance which is in the "Name" parameter at the bottom of the OIP. Doing a GetObject() on that string value will give you a handle to that particular Lighting Device, and then use SetRField() using that handle. You only need to SetRField() for the parameters you want to change. All the rest will remain unchanged. HTH.

In my experience, there is no limit for the number of objects the ForEachObject() procedure can handle. SetRField isn't particularly slow, but VS is interpreted, and you are making 30 assignments of string variables for each of 300 objects. I have 2 recommendations. One, go get coffee and/or do the dishes. Or two, try and get your data into .XML files. Data input with XML files is lightning fast. They load really fast, and they assign really fast. However the speed problem is killing you, there shouldn't be a limit on the number of Lighting Devices.

I'm no help here, and have run into this problem several times. In some commands, I have even thrown up an alert telling the user to nudge the object up and down to cause the OIP refresh. It would be fantastic if someone can tell us how to guarantee the refresh of the OIP when Redraw, RedrawAll, ResetObject, HMove don't do the job.

Not really a whole lot of work when compared to manually typing in the color; in that, once the symbol is made, you don't have to type in those values. If things change, you can still change the record field values and use data vis. If you use a set of different kinds of truss often, you will save time by making symbols without giving up the ability to change the field values and use data vis. I'm not going to touch the problem of swapping out different truss lengths. There are simple scenarios and Andy mentioned, but there are a lot of scenarios that require very convoluted programming logic to pull off.

For sure, but this command has a lot of room in it, and I am curious if the big shows can quantify this. It would be great if one of the 3000 unit (in Lighting Devices), can tell me how many pieces of truss they used. Also, limiting the command to dealing with objects with the "Truss Record", may not provide a reliable number to use in the "ALLOCATE" command. However, I am running some test testing the Count() command using the criteria "Count(INOBJECT & (R IN ['Truss Record'])). I might be able to use this with some padding. Still, what is a large truss rental order?

What is the largest number of individual pieces truss including corner blocks have people dealt with in one drawing? Think bid list or shop order. I'm trying to size an array for a command, and I would like to not have to make it a dynamic array.

Are there any corner blocks for 12" JThomas truss or Tomcat truss in any of the VW libraries?

There seem to be 2 issues. Collecting piece data and collecting weight data. Let's talk about collecting piece data in this response. In order to collect the pieces that make up a Hanging Position (HP), a data tag would need to enter the Path Profile (PP) of the HP. That profile can be constructed differently depending on what is selected when the HP is created. I'm not going to consider HPs created from straight truss for now, though piece information is in the PP created from straight truss. In the 4 HPs below each one has been created a different way. Truss tags on the ends of the truss were created by a vectorscript in AutoPlot Tools which knows how to enter the PP of the HP. It also knows the difference in how to handle symbols from how to handle "Truss" objects. It also knows how to enter groups. I am not that facile with Data Tags, but I don't think they can have the necessary programming power to do the above. If I'm wrong, great, and I will need to find out somewhere how to program Data Tags; though, I think it will always be easier for me to script what I need. All of that being said, it would seem that you need a command that would look at the selected truss and create the report you are showing. I think such a report would be found useful by many users, and I don't see it in the Spotlight report menu. I will consider making such a command. The biggest problem is that the format would probably be hard coded and would not be specifiable by the user; however it could then be exported to Excel. It would always be a one way report that collects information. Truss sticks could not be reconfigured from the worksheet. There are similar issues with weight, but they are not exactly the same. I'm not sure when I'll get to that discussion. Feel free to message or email me if you wish to discuss this further. Sam Samuel L. Jones Developer of AutoPlotVW, AutoPlotTools for SpotLight, and Chain Hoist Tools sjones@autoplotvw.com (310) 993-4172(cell)

What would your truss inventory report look like? As for the total load, would that include all the selected objects that might be on the truss? or just the Lighting Devices and other objects with known records?

Depends on what you mean by "excessively slow". I have removed, separated out, some WS creation because it slowed things down too much. Unfortunately, the need for the WS creation remained, and was put in a separate command. (When I could). The speed problem came about when I was creating long list of havested information with concatenated data. After several tests isolating the data collection, data concatenation, and writing the cells, writing the cells was the main drag on time. Still it was the fastest way I had of making the lists I needed. One could always try typing the data into a list of any kind by hand, to make one put up with a slow script.

Unfortunately, it doesn't. Sometimes, with some commands, it does. Using the NIL handle returns bad handle error. I know how to do this. I do it often. I have gotten into the habit of making the subroutines to do all this when I create the SetupDialogC case statement of any dialog that might want set and retrieve defaults. I am somewhat unreasonably gunshy on piling on the XML file that holds these settings. Thanks Kevin and Josh in confirming what I suspected. As an aside, Kevin, are the bad handle errors ignorable?

I suspected this. I've been punting to Set/GetSavedSetting() and Rpstr commands, but I had a little time and wanted to nail down the status of using command parameters. Thx

I want to get a handle to the command that is running within the command's code, so that I can store date in the parameters of the command with GetRField(commandHandle, commandName, parmeterName); SetRField(commandHandle, commandName, parmeterName, newValue); I am trying to get the handle with these lines in the commands code: PIORecName := 'AP Make Jumper Cable Chain'; PIORecHdl := GetObject(PIORecName); PIORecHdl always returns NIL. Why is this happening, and what method should I use to get the handle of the currently running command? TIA, Sam PIORecName is the name of the running command

Josh may be of more help here, but be sure in addition to ResetObject(LDHandle) after setting the parameter value in each Lighting Device, you run RedrawAll at the end of your script. You should be able to get away with running Redraw, but I have had inconsistent success with Redraw recognizing or finding changed Lighting Devices.

If you are into a Braceworks workflow, and having Braceworks calculate loads I will leave you to it. I don't use Braceworks; however, many of us want to get as much of the load information as possible just to keep us in the ball park. The screen shot below shows a worksheet of all the selected devices below it. Depending on the hanging position, to report the weights can be problematic unless everything has, or is, a Braceworks load. The AutoPlot command ("Collect & Total Weight") used to generate the worksheet below queries the weight fields of the selected objects and lets you substitute your own weights if you desire. Hanging positions of truss can be made up of 5 different kinds of VW constructions. 1. Truss created with the Straight Truss tool 2. Truss created with VW truss symbols 3. Truss created by grouping VW truss symbols 4. Truss created using VW Truss PIO objects 5. Truss created by grouping VW Truss PIO objects How weight is collected from each of these is different. It became a little simpler in 2022, but not much, and I didn't even include circular truss. The command goes into a deep dive as to where to collect weight values in each case. Then we have Hoists. Legacy Hoists and the current VW version of hoists report weight differently, and of course you will want to decide whether or not you want to include chain weight, which you almost always will want to do. The two versions of Hoist report chain weight differently. Then we have the Video Screen object and the Blended screen object, and they report weight differently. With the Video screen object you need to be given the choice of whether to use the screen weight or the projector weight. Also, you should note that Lighting Devices do not report the weight of the accessories in the "Weight" field. They do report the combined weight in a "Total Weight" field that is greyed out in the load information section. You do not have access to that field in a worksheet, but it is possible to query the weight accessories in vectorscript which is what the command that makes the worksheet does. This allows you to enter weights as needed, since the vast majority of accessory symbols have "0" in their weight field. If you care, there is more to collecting weight than just adding the hoist weight to the the hanging position total. What is your workflow and how do you use weight? AutoPlot "Truss Tags" will also try to decipher weight information, but that is another discussion.

So. ...You're saying the work around is still needed, but not much longer. While it is needed, how will it work if I want to anchor a template holder at the nose of the light but inside the symbol graphic and I want to anchor iris at the gate that is not at the insertion point. I'm assuming 2 loci won't work, because the tool won't know which locus to use for which accessory. This all being the case, I assume the workaround won't work for more than 1 errant accessory. Right? If wrong, how would that work?

Can you tell us how this would work with more than one accessory attaching to a single light? Color scroller, Top Hat, and Iris?

AutoPlot Tools for Spotlight, www.autoplotvw.com, has such a command. There is a fully functional 2 month trial period, which should give you time to do the export. Let me know if you have questions or need help finding the command you need.

You can use the old hoists. They're called "Legacy Hoist" and you have to add them to your workspace with the workspace manager under the "Tools" tab. Unfortunately, you will need to replace the ones you have already drawn with the legacy hoists

Doh !!

I'm sure there is an obvious answer, but I can't think of it. Why would you want to do this?

The find and modify functionality seems to exist, but I find it very difficult to use, and I have not find a way to select with it unless I want to modify. I'm willing to admit that I am very set in my ways, and maybe a little dull, but I can't figure out how to do any useful work with accessories and the Spotlight Find and Modify... functionality. But then, I don't have to; I made my own. BTW, I heartily recommend the Savvy Select Similar Instrument tool.

I don't think you can select by accessory type in 2021. Maybe Kevin Linzey or Jesse Cogdell can enlighten us. You can do it with AutoPlot Tools for Spotlight. It has a 2 month fully functional trial, so if you can get your task done in 2 months it's a free solution. Let me know if you want to Zoom and I'll demo it.

Damn! I've been wanting to know about this for 20 years.

Pat points out the problem. How would VW know which number from the Excel sheet goes to which Truss object or Hanging Position? If you make a database worksheet of the objects typing in the numbers should go pretty fast, but you have a similer problem. How do you know which number goes with which row?