Jump to content

Judah Warshaw

Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited


22 Great

Personal Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Another option is the Custom Leaf setting. This way you do not have to model the entire door, including the jamb and any other options you would like. Just the leaf. And you may find one that is a good starter to work from:
  2. If you look at the remarks section for https://developer.vectorworks.net/index.php/VS:SetWSCellFormula you will see: If the 0 column is specified, a database row is created and the formula set as the database row criteria. Some examples would be: { creates a database sub-row for the record 'Part Info' } SetWSCellFormula(h,2,0,2,0,'=DATABASE(R IN [''PART INFO''])'); or dynCharArray := '=DATABASE(((R IN [''Window'']) & (''Window''.''OnSchedule''=TRUE)))'; SetWSCellFormulaN(tempHandle,4,0,4,0,dynCharArray); You would then have to add the formula for each column for the field you want: dynCharArray := '=(Window.IDLabel)'; SetWSCellFormulaN(tempHandle,4,2,4,2,dynCharArray);
  3. I'll try to clarify some of the calls, to the best of my abilities. I can't really comment on the naming, since that ship has sailed long ago. Keep in mind that many function calls are exposing inner functionality for public use, and the function and variable names will be created to reflect that. Lets examine ProgressDlgStart. This tells the dialog that how much of the work you want to be show. If for example you have ten steps that you are going to be doing and you want to update the meter text after each step, you would give the percentage as 10 for each step. Maybe you have three steps, but one of them reflects 50% of the work, one 30% and the final 20%. You would be calling ProgressDlgStart three times, each with a different percentage. Now each of these steps can be broken down into how many increments will be in the progress bar for that step. Let's take our example of 50, 30 and 20 as a division of labour, and you have 10 objects you will be working on during each of the operations. You would call ProgressDlgStart( 50, 10 ). You are saying "fill the progress bar until 50 percent of it is filled, and do it in 10 incremental parts." Each time the progress bar fills a little big, it will be 1/10th of 50% of the bar. That is you LoopCount. When is the progress bar incremented? When you call ProgressDlgYield. You are saying how many of the previously defined LoopCounts you want to increment the bar. It also gives you an opportunity to check if the cancel has button has been clicked. I know this may not be as clear as possible, but with a little playing around I think it would clarify itself. Does this help at all?
  4. Your errors are because of the scope of the declaration of the constant ToLW and the variable VToLW. They are declared within the function ChangeThickness and are therefore not visible in the main procedure of LWUpdate. Try the following which moves those outside the ChangeThickness function. ROCEDURE LWUpdate; CONST { substitute these with the required values } ToLW = 0.35; {mm} VAR VToLW:REAL; FUNCTION ChangeThickness(h :HANDLE) :BOOLEAN; VAR r, g, b :LONGINT; BEGIN GetFillBack(h,r,g,b); IF (r = 34952) & (g = 34952) & (b = 34952) THEN SETLW(h, VToLW); GetFillFore(h,r,g,b); IF (r = 34952) & (g = 34952) & (b = 34952) THEN SETLW(h, VToLW); END; BEGIN { Each object option here is set to affect all objects, on all layers, using a deep traversal} VToLW := ToLW / 25.4 * 1000; ForEachObjectInLayer(ChangeThickness,0,2,1); END; Run(LWUpdate);
  5. To try and make a long story short: door configurations were changed in how they were defined in VW 2021. When exporting back to 2020, the configs are set for their closest match (not everything is supported). If you take a native 2020 file, the doors have an internal version marked as being last set for 2020 and that triggers an update when opening in 2021. When exporting back to 2020, they are still marked as being from 2021. Therefore, when opening back in 2021, no update happens, leaving the new configuration in it's default state - Swing. That is why running Reset All Plug-ins helps, because the reset will cause they will be marked as being from 2020. I am working on an overall fix this, as it has come up more than once, but here is something a little better than "Reset All Plug-ins". Add and run the following script. This will set the version for all doors to 2020 without having to reset them all. Keep in mind that going from a new version to an old one and back again can sometimes give unpredictable results. PROCEDURE UpdateVersion; VAR crit : STRING; PROCEDURE UpdateDoorVersion( h : HANDLE ); BEGIN SetRField( h, 'Door', '__version', '2500' ); END; BEGIN crit := 'PON = DOOR'; ForEachObject( UpdateDoorVersion, crit); END; RUN(UpdateVersion);
  6. I would start with the following article on the Developer site: https://developer.vectorworks.net/index.php/VS:Progress_Dialog
  7. The main benefit of enabling "Run scripts in developer mode" is you can make changed to your script without having to relaunch Vectorworks. Once thing that may not be obvious - If you are handling the event kObjOnInitXProperties, you only get one shot at it. It will only execute once. If you have errors in your script and need to fix it, you will need to restart VW to have any properties set properly.
  8. The proper field for both Doors and Windows is NGA2. This is defined as an Area parameter and should you the value in the defined area unit for your document. Keep in mind that value calculated for Net Glazed Area is the area of the glass/glazing. This does not include the sash and jamb that surround the glass. If you have several panes of glass NGA2 accumulates all pieces of glass. The NGA (for door) and NetGlazedArea (for window) field are outdated. They were from before Area type parameters were available.
  9. Just to give you some background on this...when you convert the PIO to a symbol, you have one copy of the geometry that is duplicated through all instances of that symbol in the drawing. The symbols in the drawing, at that point, have no knowledge of any parameters that the underlying objects may have. In the Use Wall Depth situation, the Jamb Depth parameter gets adjusted whenever the door finds itself in a wall. When using a style, Use Wall Depth will always adjust the Jamb Depth when the door is in a different wall, or the wall's thickness changes. None of this can happen when using a symbol Think of it in terms of a container - when the door is in a symbol, the symbol definition is the container, not the wall. What is in the wall at this point - a symbol, not a door.
  10. The has always been my understanding of the hierarchy as well.. If it has changed it would be news to me. The door and window code make use of the services in VW to find the file. In this case only the first one found is used, as opposed to resources that might aggregate together. As a FYI: The source for this goes back many years to when the plug-in was converted from VectorScript to SDK. In the VS version, the user could edit the plug-in within the plug-in manager and change how it would appear in the UI. This is not possible with SDK plug-ins. That was always a per user only solution. There was no way to do this for a workgroup. When the change was made to SDK, a way to get user defined name was needed, and this was the best solution, at least at that time. It has the added benefit of being available for workgroup folders as well.
  11. Correct. Ultimately, these are a per user issue. But, as you ask, they can go in a workgroup folder. Either that or everyone needs a copy. It is only a visual change in the UI that is made. The field name in the record does not change. Yes they can. The changes can be places in a Workgroup or project folder. When VW launches, the first one found is the one that will be used. The file is found through that standard hierarchy that Vectorworks uses to find files. Again, you are correct. Since this is only a visual change in the UI and not the record itself, it is not portable.
  12. The door hardware definitions are found in the folder Libraries\Defaults\Door - Hardware in the file Door Hardware Library.txt If this file is set to read only then you will get the result you are seeing. Be sure the check the file in your user folder. This takes precedence over one in the application folder. Typically the files in the application folder are read only. You will have to check you file attributes to be sure.
  13. This is a little obscure, but it can be done with ease. Navigate to your Plug-Ins\Common\Data folder. You will find 2 files: DoorPreferences.xml and WindowPreferences.xml. In this file you can name each of the 10 user defined fields. Fill in the Key section, for example <Parameter> <Name>UserFld1</Name> <Key>MYFIELD1</Key> </Parameter> This will rename user field 1 to show as MYFIELD1. In the door settings dialog you will see: In the create report dialog: and in a worksheet:
  14. I'm sorry that I did not see this earlier but...there is a built in worksheet function for this: =PLUGINSTYLENAME You can find it in the Insert | Function menu item.
  15. You can also use the Edit Curtain Wall tool and choose edit panels from the toolbar. Then select a panel and use the context menu. There will be two options to insert a door or window directly into the selected panel. This will save the step of having to check the Curtain Wall object setting.
  • Create New...