Jump to content


  • Posts

  • Joined

  • Last visited


0 Neutral

Personal Information

  • Occupation
  • Location

Recent Profile Visitors

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

  1. We encountered another problem when trying to roll out our scripts in that .vss includes were causing scripts not to function at all, i.e. when chosen from the menu, nothing happens, no errors, nothing. It was historically useful to have some includes not compiled into the solution to handle users with different versions of VW but instead of trying to debug yet another issue we made the decision to make these .px and updated all the scripts to reference these files. This allows them all to work on our client sites. Testing is complex because the environments are. For licensing reasons, scripts are document specific and sites have different configurations, so recreating those environments exactly is not so easy. Our client base is fantastic so we can test on their installations to guarantee good results. In all, the changes since VW2015 have caused a lot of disruption and we have come to the end of the road with this approach. We have already been working on alternative ways to deliver the same or better functionality in our solutions without using Vectorworks and these are well advanced. Thanks all for your contributions.
  2. I think I have found it. When all the script and include files were updated for VW2019 (280) one include remained as a .vss because it alone was previously in a different location and had to be moved due to the changes wrought in VW2017/18. Of course, this file is referenced in virtually every script, which why they all had a problem. A quick edit and recompile/encrypt show it to still function when includes are removed in VW2019, which is promising. Moving that same plug-in to VW2018 is also working. We have to test on a client installation next week and see of that one script remains functional but it looks like having to edit and re-encrypt the whole suite… I'll do some more tests and report back in a few days. We never saw any errors of course except at run time. I have not seen any issues here with the change from HFS+ to APFS. All our path names are clean.
  3. Not possible, we are Mac only for 34 years, 19 with MiniCAD/Vectorworks.
  4. Nicolas, Thanks for the link. We are not using the SDK, hence no plug-in. We are encrypting on an individual script basis and anyway this does not explain the behaviour of VW2019 in relation to the includes. I will do some more experiments with earlier versions of Vectorworks to see if anything emerges and report back.
  5. Hi JBenghiat, Mainly was using 2015 with some 2017/18. All the necessary changes were made: All files UTF8, deprecated functions handled, all scripts compile and run normally unencrypted, no errors or warnings, so all paths OK. After encryption, everything still works perfectly but the includes have still to be present. Hi Nicolas, The BatchEncryption Plugin definitely not present in any of my Vectorworks user or application folders going back to 2012. Not part of the standard install? Is it documented somewhere? Thanks both.
  6. I am having a problem with encrypting our plug-ins under VW2019 which did not occur with previous releases, in that the encrypted plug-in still looks for the include as if it were a .vss and not a .px, as all of ours are. Thus we cannot ship any of our plug-ins. I have looked at the encrypted plug-ins with BBEdit and they are clearly encrypted but not large enough to have incorporated the include data. What may have changed in the encryption process or is this a bug with 19? macOS 10.14.6 (Mojave) Vectorworks 2019 SP4 TIA Joel.
  7. Turned out to be a stupid thing. One common include was a Mac alias instead of the original file and so the file was effectively missing but VW was trying to use the contents as an include anyway. All working now, thanks. Joel.
  8. Hi Raymond, All the include files have those blank lines and they are the same files that compile on the Mac side. Will check out CONST declarations specifically. I'll do some more digging. Thanks, Joel.
  9. I have been developing a script on the Mac in VW2012 and wanted to test it on the PC side, so I installed a copy of VW2012 on Boot Camp with Win7, copied across the various resources and I see this error: Line #1: book | { Error: Expected = } | { Error: Expected BEGIN } | { Error: Expected a RUN statement at the end of the scirpt } Seconds to Compile: 0.00 Previously in VW2011 any script I brought across to the PC worked the same in both environments but here there is a difference. There is no "book" on line one of the script and it shows no compilation errors on the Mac side, so what is the compiler trying to get across? Thanks, Joel.
  10. DWorks, Thanks, I'll have a look at that and see how I can make use of it. Joel.
  11. Josh, Ah well, it was a nice idea. There is a suggestion in the remarks for GetPluginInfo that getting the rec definition (type 47) from the PIO by using GetObject(PIOName) might return the object with the values I was looking for but that is also blank, as per your explanation. Normally I use the PIORecHandle (type 48) returned by GetPluginInfo to save the parameter data with SetRField(). I have such a system for some default values but I didn't want divergence between the default values assigned in every PIE def and those in my file, which also loses the flexibility of per-document settings, for which I have yet another scheme. No matter, I'll concoct something to store these values somewhere. Many thanks for your help. Joel.
  12. Josh, Thanks for that, but I'm hoping to have access to default value rather than change it and have the script read the default instead of the current value. You gave me the idea of trying: GetRField(PIORecHandle, PIORecName, PIOFieldName); instead of pFieldName but it returns nothing even though there is a default string in the parameter def. There have to be two values stored for each field, the default and the current. How to get access to the former? Joel.
  13. Is there a way to force the reading of the default parameter value instead of the value previously saved? Programmatically reverting to the default value would be useful if an error is detected that makes the value that would have been saved to the parameter invalid. It seems that once a menu command has run for the first time after parameter creation and the default value read, changing the default value subsequently in the VS PIE has no effect, even if the parameter value is never saved in the script. TIA Joel.
  14. I work and develop VectorScript on the Mac but I need to just test on Windows 7. Could I run VW2011 on one of the net-tops like the Acer Veriton and its Atom CPU? Performance is not important and I will not be drawing or using most of the functions in Vectorworks, just running scripts. The machine will not be running anything else other than VW. I had thought of perhaps running one of the virtualisation apps for the Mac but I would like to have an environment as close to that of my users as possible and leave the Mac alone. I am not familiar with the Windows landscape at the moment, so all comments are welcome. Thanks, Joel.
  15. Joshua, Well done, it works! Hopefully we'll know when it changes again as a result of your submission. How did you discover this solution? Thanks, Joel.
  • Create New...