Jump to content


Vectorworks, Inc Employee
  • Content Count

  • Joined

  • Last visited

Community Reputation

63 Excellent


About Vlado

  • Rank

Personal Information

  • Location
    Maryland, USA

Recent Profile Visitors

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

  1. Hi @P Retondo This is a known issue, and there are wishes to update this tool. We have it high on our lists to update and improve the workflows with. Regards, Vlado
  2. If it works in general but not for a specific database, maybe there is a specific things about the SQL language of that database, like comma or quotations. We have a configuration file that can set these things up, as from Vectorworks perspective they are all the same, we just sent requests. What's the database you are using? I've managed to this during my tests with another DB. I am using VW 2020 SP2.2R1 in german. It looks you've found a place where the buttons should have been disabled but they are not. Symbols are not accounted for when exchanging data. Which one would you recommend? It's either say, all these use the same API.
  3. Hi @Bogdan Ciocan How do you do this? You surely have objects in the drawing for this? The fundamental concept is that you connect a database to your VWX drawing. Then you define the format to be connected to a table, and establish which format field connects to which database table column. Note, there is no data flow at this point, only connections that tells it how the data will flow, and where the data will be stored in both places: <vectorworks' format field> to/from <db table column> Now, when you have a record of this format, which is the actual instance of a record, and can only be attached on objects in the drawing, then you have data, which is stored in a row of the data connected to this format. fields, i.e. db table columns, define how the data from that row will be exchanged with the record. So, now, if you edit a symbol definition, having nothing selected means that you are editing the defaults values that will be attached when this symbol is placed in the drawing. Noice that the 'Object Database Connection' is disabled in the context of symbol edit. Now, if you insert this symbol into the drawing, the record is attached to that symbol, and you can use the Data pane button, or menu Tools -> Database -> Object Connection to associate a row of the db table to this record. Note you can do that on a single selection or multiple selection in Vectorworks. The single selection will be like either add or select a row to provide the data for this symbol instance, where multiple will give you a chance to add or find rows depending on cirterias. As far as I understand, you are trying to build up a library with prebuild values from symbol defintions connected directly to db. This can be possible with scripting (either python, vectorscript or marionette). But there is one main question: if you add multiple instances of this symbol definition, you'll have repeating data...essentially the key will be duplicated, so several objects will contribute to a single row in the db table. Maybe your data works that way?
  4. Hi @Bogdan Ciocan, Well, technically, the symbol definitions are pre-set graphics that are ready to be placed in the drawing. They do not store any information, well they hold default values, but not countable information. Then they cannot be connected to the DB as it holds actual data. So, maybe your question is how to connect the default values of the symbol data to a database? But that would be strange as when you insert the symbol in the drawing, you can have several copies of the same data. Is that required? What is the workflow you want to implement? At the moment, a DB table for vectorworks is a Format and Record at the same time. Format represents the table and it's columns (the definition), and a record is a single row. This way, when you have several records of a format, you are dealing with several rows of that table. Following my thought from above, if you have a record attached in the drawing, you can associate it to a single row from it's DB table. So, if you symbol instance has a record attached to it, you can associate it with a DB table row and get/put the data there. This works via the 'key' columns (one or several) identified when connecting to the database. They are used in the 'WHERE' of the SQL to identify a single row. this is the so-called primary-key and secondary-key of a table, and unique so they can identify a row uniquely. This means that your format needs to connect to these columns, so when you connect a record, it has a place to store the 'keys' to uniquely identify that particular row in the DB table always. Yes, selecting multiple objects and trying to connect them with the menu command, will allow you to use logic to associate the multiple objects to multiple rows in the DB table using pre-existing values in the keys. You can also use the Data Manager to exchange data between records and parametric objects. Regards, Vlado
  5. @David Bengali > clarify further on the process and its relationship to .pyc files, and how to ensure that the source code truly cannot be accessed in some way. The python would compile the .py files into .pyc files before execution. This is part of python and always happens, it always executes the pyc files, and it has some smarts to not compile if the py didn't change. The pyc files are binary files that are byte-code of the python code. I guess you can read more about them in the python documentation. As far as I know, it can be uncompiled but it doesn't restore variable names, comments, etc. The process of encrypting a python plugin in Vectorworks consist of bundling all .pyc files into the vsm, vso, or vst files. It essentially, copies the binary files as is, one after the other in the vso, vsm, and vst file. This adds a little protection too as it's becomes one big binary now. Even though, if you really wanted, and analysed the bytes, you can figure it out. let me know if you have more questions. Regards, Vlado
  6. Well, the equivalent of the console command 'python' is a Vectorworks document script. You can execute pip-like stuff that way. Also, note that python is very flexible in the sense of libraries. Perhaps you can try moving only the necessary stuff into the users folder: <user name>/Plugins By default vectorworks will add that location to the search path of the python engine. So if you can isolate necessary needed pieces, you can provide them there. This is, of course, if there is no conflict with the exiting packages in the app bundle. I'll make it a point to update for the next release.
  7. Hi @relume and @JBenghiat did you manage to get it to work? First note that Vectorworks embeds the python engine, which means that Vectorworks is the python. So, if you just update your local python you are not really affecting vectorworks at all. So as Josh suggested, you can download the 3.5.2 on the side and manually copy it over into the Vectorworks bundle. However, there might be problems with this. There are two sides of python: first it's the engine itself, it is linked, embedded into Vectorworks, and there is no way to change it unless we rebuild Vectorworks on our end. The second part is the python built-in libraries. This is what you would be updating if you just copy them into the Vectorworks bundle. I guess it would work as long as python engine supports the new bundle directly. Of course you can try, just test it out carefully as not to have strange effects on other python based features. Regards, Vlado
  8. @orso b. schmid i'm sorry, i've missed all these posts and the reference to me. I'm sorry to hear that vectorlab is down. It is absolutely possible to merge any information you have from vectorlab into the developer.vectorworks.net wiki. Also, i can give rights to anyone who is willing to support it. Page edit requires logged in user, page creation requires admin. User registration requires a request as we've seen lots of bots creating users and spamming the pages, but i create users for anyone who asks. Unfortunately, I currently have no team to support it actively and produce nice examples. I'm working on this to change, but i cannot promise timeline at this point. Again, if you have the db, or any set of articles from the vectorlab, i can merge it in.
  9. @SeanR @maccadingo @loretta.at.large I just confirmed, the build is ready and it will be released tomorrow morning EST
  10. @SeanR @maccadingo @loretta.at.large hi all, there have been a problem with a different issue that the release was fixing which delayed the release. At the moment it is scheduled to be released on monday, Dec 16
  11. Hi @SeanR, great. a patch for this will be released very soon. Regards, Vlado
  12. Hi @SeanR, this sounds like a known problem of Vectorworks 2020 SP2. The plant tool misbehaves when the user origin is changed. can you confirm that it works correctly if you don't change the user origin? a fix for the issue i'm thinking of will be released very soon. Regards, Vlado
  13. @JeremyLondonRMLA I should clarify that I don't think this will compromise the accuracy of the drawing as the geometry wont move. It will be a script that calculates the adjust origin's lat-long based on the current user origin so the internal origin is at the same place.
  14. Hi @JeremyLondonRMLA This change was needed to make things more stable. You see the User Origin is something that is not fixed and can be changed freely, typically for adjusting the numerical values of the geometry. Essentially relying on the User Origin was requiring the user to be aware of its significance and this was leading to misalignment and confusion. So, in Vectorworks 2020 it's the Internal Origin that is the point that matches the GIS and CAD layers. It was there before, but it wasn't enforced as much as now. Basically, the GIS layers (the layers marked as Georeferenced) are layers that belong to the Earth and they will move when you use the Geolocate tool. Then, the 'adjust internal origin' option will define the lat-long coordinate that the CAD layers will be placed at. That is correct, the Geolocate tool is just a visual way to set the 'adjust internal origin' options. This sounds to me like an issue of setting up appropriate georeferecing as your old drawings are already located around the internal origin, but if the shapefile import doesn't match means the the 'adjust origin' options are not matching. That would be easy to calculate and set via a script. Please contact me at vstanev@vectorworks.net and i can develop a script for you to use in these cases. Regards, Vlado
  15. @ericjhberg message received. these are the things at the top of our list.


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

  • Create New...