Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by JoelS

  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.
  16. I am having trouble sending an Applescript to VW2011 (SP2) under MacOS X 10.6 With VW2009 on the same machine, I use this Applescript to send the contents of my editor?s front window to Vectorworks: -- getplaintext subroutine called from within the Tell using 'of me' on getplaintext(fromUnicodeString) set styledText to fromUnicodeString as string set styledRecord to styledText as record return ?class ktxt? of styledRecord -- Ensure Western (Mac OS Roman) encoding end getplaintext tell application "SubEthaEdit" activate -- Get the script text out of SEE as a string. set theScript to the plain text of document 1 as string -- Convert from Unicode set theScript to getplaintext(theScript) of me tell application "Vectorworks 2009" activate -- Execute the script in VW ignoring application responses DoScript theScript end ignoring end tell end tell This does not function with VW2011 as the AS compiler returns ?Expected end of line but found identifier.? Changing the line to DoScript(theScript) gives a clean compilation but it does not work with VW2011 (other than bringing VW to the front) and no errors are reported that I can find. I see elsewhere that using a file reference in a script has been used but I cannot make this work with VW2011 either: set theFileReference to "My HD:Users:Me:Desktop:VScript.txt" as alias tell application "Vectorworks 2011" activate -- Execute the script in VW DoScript(theFileReference) end tell An error is returned by the system: ?error "Vectorworks 2011 got an error: Can?t continue DoScript." number -1708? This error is not an Applescript or OS error code that I can find so was probably returned from Vectorworks but I cannot find any trace of this error code in the documentation I have searched. I have tried different file encodings for the script file without success. If I open the same file with the Run VectorScript command, it executes as expected. So what is the official way to address DoScript in VW2011 under MacOS X 10.6? I can find no trace of any recent documentation on the subject. Using a file reference would be by far my least favourite option as it means creating an intermediate file on each occasion to a fixed location as text first, so the old way would be much easier if it is still possible. Many thanks, Joel.
  17. Thanks Ray, that's a good tip. Joel.
  18. A screenshot wont really help. On the Mac at least, in any scrollable list, single-clicking in the scroll bar above or below the thumb should scroll a 'page' or the height of the visible part of the list, but the list in the search criteria only scrolls by a line, something I don't think I have seen before. Joel.
  19. There is a problem with the search function of the board. Attempting to search all forums for the strings "pdf" or "Acrobat" in the subject and body returns no results for a 6 year scope, even though these terms are common and one of the posts that includes these terms is mine. Search is working for other terms but now there is no way know if the search has failed because there are no hits or because the search function is defective. Other search issues: 1/. The blue link for advanced search tips is barely visible against the grey background. 2/. The forum list scroll thumb does not operate correctly. If clicked above or below the thumb the forum list scrolls by a line and not a page. If dragged it operates correctly. The scroll arrows also operate correctly. This behaviour is consistent between my various Mac browsers. Joel.
  20. Thanks Paul, Well, I satisfy two criteria :-) Despite the detail in these recommendations and the context in which they are framed, it still would have been difficult to judge if VW2009 would have worked acceptably on my system without actually trying it. Had it not been satisfactory I would now be hunting for new hardware on eBay. Obviously NNA want users to have the best 2D/3D experience but depending on your specific needs, other options may be just as good. It will be interesting to see if VW2010 makes significantly heavier demands on the hardware but the biggest performance improvements usually come from the code and not the chips. Joel.
  21. I am happy to report that VW09 installs and runs very well on my PowerBook G4 17" (1.67GHz, 2GB RAM, Mac OSX 10.4.11) for the 2D work that I do - I can't tell any difference between it and VW08 for my files. The interface is responsive to the new features, so it looks good. This defers the purchase of a new machine for a while longer, something I very much appreciate as spending money on computers looks to be an increasingly futile exercise. Joel.
  22. The minimum system requirements are given as PPC G5 running 10.4.11 - does this mean that it will not install or run on PPC G4 or that it is not recommended for use on this CPU? My use is exclusively 2D drafting. Thanks, Joel.
  23. Miguel, Thanks for that tip, I'll bear it mind for my PIOs. Joel.
  24. Here are some findings that might be of interest. (All measurements are averages of multiple loops through the same objects) (Compiler mode ON, Stop on VS Warnings ON, OIP displayed) (PowerBook G4 1.67GHz, VW2008 SP3) Of the scripts I have profiled that select and deselect objects, all are around 10 ticks _faster_ overall with the OIP displayed than with it closed. My OIP never flickers during script execution or shows any activity until the script terminates. (I don't think it ever has done). Selection and deselection, even of thousands of objects, has been very fast for me with the OIP displayed or not. Mostly I see 2-3 ticks to select, process and deselect around 10 objects within a loop which is doing a fair amount of work - plenty fast enough. The single biggest problem by far is the use of ForEachObject and the LOC criterion. It costs 46-50 ticks (0.8 secs) just to make the call even when the callback is empty, and therefore using it to save the handles of the objects meeting those criteria is not recommended either. In comparison, Count or SelectObj with the same criteria are < 1 tick and using both and performing the same callback operations in a WHILE loop for the selected objects is 4-5 ticks. The entire script loop of 400 lines of code now reduces to 8 ticks (0.13sec)! Where ForEachObject is not used with LOC, there is no significant performance hit in taking the handle array route then calling the subroutine within a FOR loop. A benefit of this is that Message() will reliably update during script execution which is certainly not always the case when it is in the callback of ForEachObject. I'll keep collating the measurements I make to see if there are other bottlenecks that can be avoided. Joel.
  25. Charles, Thank you for these very useful pointers, I'll revisit my code and see if I can make improvements on this basis. I was wondering if GetTickCount would work and I'll see how I can best use it. Interestingly, I have always found file I/O operations to be blisteringly fast. Saving the data from 3.5k objects takes about 3 seconds on my PPC G4 PowerBook! I use ForEachObject a great deal because many of my scripts depend on the LOC criterion and I suspect this is costing me. I'll try to minimise my usage but I don't think there will be a lot I can do. Using selections is often the only way to prepare objects for processing amongst numerous others - if the OIP is closed, does it still have the same effect? I would say script performance is generally pretty good, it's just when having to process very large documents, every second saved is a bonus. Thanks again, Joel.
  • Create New...