Jump to content

VectorGeek

Member
  • Posts

    224
  • Joined

  • Last visited

Everything posted by VectorGeek

  1. Does this do anything that the Eyedropper Tool doesn't? V-G
  2. Great ideas - thanks Julian and Pat for the value input. V-G "All we are is dust in the bin"
  3. Is there a way to get the orientation (AKA flippification) of a symbol in a wall, and change it using VS? Asking for a friend. V-G "Vectorscripting since 1865"
  4. I have a path PIO that I use for measuring specific areas and would like to modify it so as to have a second, controllable path inside the first. The inside shape may take on a different path than the outside one (see example herein), but could start by default with a fixed offset. Ideally, when using the reshape tool, handles for both the inside and outside handles would appear allowing me to edit either. This is slightly different from a donut object (as one would create by using Clip Surface), because I need to track the areas of both the inside and outside shapes, as well as turn on/off the lines that define the two shapes and control their respective graphics. Not sure if this is possible as the basic function (GetCustomObjectPath) seems to only be able to create a single path. Any creative ideas and input would be welcomed!! V-G.
  5. Yup that's it. Creating a second external reference would make those layers have an NNA#2_ prefix. A third references's layers would be NNA#3_ etc.etc. Confirmed by test file. So that explains why you saw NNA#7_ and I saw NNA#1_. VG
  6. Hi michaelk: I am running Vectorworks 2019 SP 5.3, Mac OS X Mojave. I duplicated the DLVP several times and ran the command - still coming up as NNA#1_. I'll try creating a new DLVP with different layers, and from a different referenced file. Perhaps the number increments in that case. Will report back. VG.
  7. michaelk (and Pat!): This is MASSIVE, and solves my issue as posted (and reposted) over the past years: The "hidden prefix" means that I can control the layer visibility within DLVPs with VectorScript, and that will save us considerable bloat in our files (ask me and I can explain). One interesting note is that when I run Pat's script, I get a response that DLVP layers have prefix of NNA#1_ (not NNA#7_)...wondering if that was a typo or if there is some more mystery here...?? Thanks for this. I have been struggling for some time to get this working!! V-Geeque #gowisconsin
  8. Kevin (or anyone else): Were you ever able to find out if it's possible to access layers within a reference DLVP? I have tried a lot of prefixes with NNA_, but nothing has worked yet. V-G.
  9. Many many thanks Nicolas and Josh. The assigning of the global variable "h" to a new variable works perfectly! V-G.
  10. Thanks Nicolas - I'm still confused however. If I declare h:HANDLE in the main procedure, isn't it available throughout the entire script? How would you recommend that I setup the handles in the sub-procedures then? V-G
  11. Hey y'all: We have a custom Path PIO that we use to track various areas (unit overall, storage, balcony) for apartment units. So that I can create a database worksheet that summarizes all the areas, unit by unit, I am working on a command that posts the areas from two small path polys to a larger path poly. The user would run this command before recalculating the database worksheet. I'm using a few ForEachObject() procedures (one in the main procedure, and two in a subroutine) to cycle through the objects, looking for a match by "unit number". Here is the code: Procedure bindareas; VAR h : HANDLE; hProcessStorage, hProcessBalcony : HANDLE; TheUnitNumber, StorageArea, BalconyArea : STRING; Procedure process_storage (hProcessStorage : HANDLE); BEGIN IF GetRField(hProcessStorage,'VG-Area Poly','unitnumber') = TheUnitNumber THEN BEGIN {get the storage area and post it to the source object} StorageArea := GetRField(hProcessStorage,'VG-Area Poly','calculatedarea'); SetRField(h,'VG-Area Poly','boundstorage', StorageArea); END; END; Procedure process_balcony (hProcessBalcony : HANDLE); BEGIN IF GetRField(hProcessBalcony,'VG-Area Poly','unitnumber') = TheUnitNumber THEN BEGIN {get the balcony area and post it to the source object} BalconyArea := GetRField(hProcessBalcony,'VG-Area Poly','calculatedarea'); SetRField(h,'VG-Area Poly','boundbalcony', BalconyArea); END; END; Procedure do_me (h : HANDLE); BEGIN TheUnitNumber := GetRField(h,'VG-Area Poly','unitnumber'); ForEachObject(process_storage,((NOTINDLVP & NOTINREFDLVP & (R IN ['VG-Area Poly']) & ('VG-Area Poly'.'polyclass'='Area-Storage')))); ForEachObject(process_balcony,((NOTINDLVP & NOTINREFDLVP & (R IN ['VG-Area Poly']) & ('VG-Area Poly'.'polyclass'='Area-Balcony Open')))); END; BEGIN {main} ForEachObject(do_me,((NOTINDLVP & NOTINREFDLVP & (R IN ['VG-Area Poly']) & ('VG-Area Poly'.'polyclass'='Area-Strata')))); ResetObject(h); END; Run(bindareas); When I run it, it works, except for the posting of values to the main Path PIOs (the SetRField() procedures). In the subroutines “process_storage” and “process_balcony”, I am getting an error in the debugger that the handle called “h” is NIL so it doesn't execute the SetRField() routine. I don’t really understand passing handles to subroutines very well so I think it’s probably something simple. Any help would be greatly appreciated. All the best, V-G
  12. Thanks Josh and Pete for confirming that I am not losing my mind. Jonathan, as I said, this is happening without a mode bar change (U key or otherwise). What's weird is I can't pin down exactly when and where it happens, therefore I have also not filed a bug report. Pete - your description is EXACTLY the same behaviour I am seeing - randomly changing modes after clicking on an object to put down the attributes. Wondering if Jim can lend any insight... V-G.
  13. Is it just me, or does the Eyedropper Tool have a mind of its own? I regularly see it change modes demo pickup to put down, WITHOUT having pressed mode bar key or the option key (which should temporarily toggle to the alternate of the current setting). Signed, V-G.
  14. Thanks Andy and Josh. Got it working with the __NNA_DO_NOT_CHANGE trick. V-G
  15. Thanks Andrew: I believe this does the same as SetParameterVisibility() which shows/hides parameters on the OIP. What I am looking for is a way to hide the parameters in the Properties dialog that appears when an object is first placed. Will test though to see if it does indeed do this. V-G.
  16. Is there any way to suppress the "Properties" dialog box when a plug-in object is first inserted in a file? V-G.
  17. Looks like this is not possible with Control Points as the parameter name is not editable... Any tricks? V-G.
  18. Brilliant! Many thanks Josh. V-G.
  19. So, SetParameterVisibility() works great, however the first time an object is placed, when the "Object Properties" opens, all of the hidden parameters are visible. Not a deal-breaker, but I'd prefer they were hidden always. Is there a way to do this? Thanks! V-G.
  20. Ray, Miguel, Kevin: Thanks for the feedback. I think Kevin has it - it's related to Developer Mode. Of course that's how we do all our testing, but the users never turn it on. That's why I was seeing inconsistent results! Cheers. V-G.
  21. Thanks Hippo. So "IsNewCustomObject" is really useless then, because the second time, the object isn't new? V-G.
  22. Hi friends: I just realized while debugging a script that this procedure generates both a message and an alert dialog. In other words, IsNewCustomObject is not working because the code appears to execute twice during object placement. So the first time, IsNewCustomObject is TRUE, then it's FALSE, all during a single placement of a PIO. I recall Miguel posting something about this, but I'm at a loss to understand is this is truly what is happening. If this is true (running code twice), is the IsNewCustomObject procedure of any use? Thanks!!! V_G. IF IsNewCustomObject(myName) = true THEN BEGIN iullength := pullength; iulthick := pulthick; cp01X := itotalrun + iullength; cp01Y := itotalrise - iulthick; SetRField(myHand,myName,'CONTROLPOINT01X',Num2StrF(cp01X)); SetRField(myHand,myName,'CONTROLPOINT01Y',Num2StrF(cp01Y)); Message('I'm New'); END ELSE BEGIN cp01X := itotalrun + iullength; cp01Y := itotalrise - iulthick; SetRField(myHand,myName,'CONTROLPOINT01X',Num2StrF(cp01X)); SetRField(myHand,myName,'CONTROLPOINT01Y',Num2StrF(cp01Y)); alrtdialog('1234'); END;
  23. IMO, there is a high level problem with the GSG and that is, quite simply, it's not teaching or training, it's "follow the bouncing ball". In other words - you need to add context. "How to do it" is not nearly as important as "Why am I doing it?". Think of the best teacher you ever had - I would contend that he/she made the information you were expected to learn pertinent, and that they gave relevant, contextual background. That's how one learns. For example: You can make a video and have the viewer add some classes, however if they don't understand classes conceptually, they are just repeating steps. By simply explaining (in short form) how VectorWorks uses classes (and how that might compare with other software paradigms), the viewer gains insight rather that just learning how to do something, but not know why they are doing it. If the context is discipline-specific, even better. Not an easy task, but there are many training options for other software that succeed in this sense. Namasté, V-G.
  24. Dexie: There is a way, but it requires an extra cell. Assuming you have the value 2.29803 (or any value between 0-10) Create a cell with the formula: =ROUND(D8*100)/100 That will round the value to two decimal places Now base your calculations on the value in this new cell. Math is fun, english is funner! V-G.
×
×
  • Create New...