Jump to content

David Bengali

Member
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

1 Neutral

About David Bengali

  • Rank
    Greenhorn

Personal Information

  • Occupation
    Theater Designer
  • Location
    United States

Recent Profile Visitors

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

  1. I think I may not have enough info to answer this regarding batch encryption. For one plugin at a time, I think that what I have done in the past is to delete the __pycache__ folder and the .pyc files within, leaving only the vsm or vso file, the xml file, and the source .py files, then following the steps in which describes encrypting a single plugin from the Plugin Manager (as an alternative to EncryptVSPluginFilePath call) holding Ctrl+Shirt+Alt on win or Ctrl+Option+Cmd+Shift+CapsLock on mac and double click on a plugin. I'm not sure how encrypted this actually makes things, and how easy it is or is not to decompile / unencrypt in some way, but I think the code is not listed in plain text at least @Vlado may be able to 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.
  2. Thanks Raymond, yes, that is what I had been doing essentially; I was just curious if there was a shorthand the way there is in VectorScript
  3. Vectorscript includes a way to specify points in distance-angle mode, by using a pound sign. Is there a way to do this as well in Python Scripting in Vectorworks?
  4. It has been a little while since I have dealt with this, but if I recall correctly, with python based plug ins, you have to get the code out of the main vso object in order to actually encrypt it and hide its code. i.e., make an external _main.py file, and then in the script that you can see from within the Vectorworks plugin manager, you would only have import _main _main.execute() You can use the xml file to identify this external file to be bundled
  5. Thanks Josh, and Julian from the other thread. Basically I'm looking to have part of the drawing in a PIO be scaled to the screen rather than to the layer, so that those elements always appear the same size regardless of zoom level. GetZoom seems like it might be intended for this sort of thing, but without the ability to listen for zoom changes all the time, it only gets checked when some other event causes a reset. Though I do see the issue with responding to all zoom changes. Is there another way to draw in 'screen space' ? If so, I suppose it may have the same performance risks
  6. Here is a conversion to 2010 format DWG. Let me know if you need the export to be to a newer DWG version, or with different options, and I can re export Dumpling Green 0002 v2019-dwg.zip
  7. Apologies for the cross post; I'm not entirely sure where to post general questions about Vectorworks scripting with the Vectorscript and Python categories separated. I'm wondering if there is a way from within a scripted plug in object to detect that the user has changed the zoom level of the document in order to trigger a redraw or other action whenever the zoom changes? I know how to get the current zoom level, but I don't know how to be alerted that it has changed.
  8. Apologies for the cross post; I'm not entirely sure where to post general questions about Vectorworks scripting with the Vectorscript and Python categories separated. I'm wondering if there is a way from within a scripted plug in object to detect that the user has changed the zoom level of the document in order to trigger a redraw or other action whenever the zoom changes? I know how to get the current zoom level, but I don't know how to be alerted that it has changed.
  9. Hi, I just stumbled across this thread while looking for info on what has become of the very useful information on Vectorlab. It is great to learn that much has been archived, including the very often cited Events page. Just wondering if there is any update on when these archives may again be visible somewhere, and if there is anything any of us in the community can do to help?
  10. I think I have solved this - It seems VW was not updated to the latest service pack for 2017 on the problem computers, and upon updating, the behavior appears fixed. I should have checked that first. I imagine this is a known bug that is documented in the release notes somewhere.
  11. Well, the relative value is really what I do want, and when I drag the control point, this is what I get. But I also want the user to be able to decide they want that control point, for example, to be 5 feet from the PIO's insertion point, and be able to type 5' and have it go there. It's this case that isn't working out so well. If there were a way to tell the difference between these two different ways in which that parameter can be modified (drag or type), I suppose I could "fix the fix" that vectorworks is applying, but they seem (I think) to be triggering the same event and param change ID. This is on a Linear type PIO, btw
  12. Yes, that should be the behavior, but it is not what is observed. It seems like it may have something to do with the statement on this page: http://developer.vectorworks.net/index.php/VS:Plug-in_Parameter_Types which says: "Control point parameters are sensitive to changes in the user origin of a document, and values displayed in the field will be corrected for any changes in the document user origin." As an example case, I made a file where the internal origin was at 0,0 and created an instance of the plugin object with its origin also at 0,0 If I drag the control point to x=5', y=0', the visible field for the x coordinate is correctly updated to 5' If I type 6' into that field, the control point correctly moves to 6' However, I then moved the User Origin to x=1', y=0' Then, when I drag the control point to 5', all is well, and the field in the OIP shows 5' However, when I type 6' into the field, vectorworks changes the value to 7', and moves the control point to x=7' It is as if the fact that the plugin object appears to now be located at (-1, 0') instead of (0,0) is causing vectorworks to 'correct' the value in the field by adding this additional foot. But only if I type a value into the field. There is a statement on the page linked by Pat which suggests there is some undesirable behavior regarding a plugin object's inability to retrieve its own location relative to the User Origin, but it is unclear if this observed behavior is related.
  13. I am running into an issue related to this topic, wondering if it has come up for anyone else: On the VW install on which I have been developing a plugin, I have had no problems when units are set to Feet and Inches, but when moving the plugin to other computers, suddenly I get an error trying to set the value of Static Text parameters when the units are in Feet and Inches. It looks like somewhere within vectorworks, beyond the level of my plugin's code, there is a problem escaping quote marks. I am building in Python. Here is an example of some code: diag = (width * width + height * height) ** (0.5) vs.SetRField(oh, objname, 'Diag', vs.Num2StrF(diag)) the variables width and height are all the result of calculations based on dimension parameter fields. On the computer where things function correctly, the math works out accurately, and the static text parameter called "Diag" is updated with a value that looks correct, and includes feet and inches quote marks however, on some other computers, I get this error: File "<string>", line 1444 vs.PDiag = '14'1.706"' ^ Syntax Error: invalid syntax There is no direct assignment to the "Diag" parameter in the code, as this error would suggest. Only the SetRField call shown above. This would suggest that somewhere behind the scenes, vectorworks is trying this assignment, and failing because of unescaped quote marks. I do not get this error in other unit modes. And it is strange that I do not get this error on every computer. Any ideas from the group?
  14. Hi, wondering if anyone has any advice -- Sorry for the cross post; I was in the wrong topic area before. I have a plugin that includes a control point that is draggable, but which also exposes one of its coordinate input fields in the OIP to allow the user to type a precise value. When the user origin has been dragged, typed values in this field get offset in ways that lead to "incorrect" values, but dragging the control point behaves as if the current User Origin is the Internal Origin. I imagine I could use GetOrigin() to find the offset and fix this behavior, but how do I detect whether the parameter changed from a drag operation (in which case I should leave it alone) or a typed value in the OIP (in which case I need to fix it)? Or is there a way to get Control Points to only look at the user origin? (the documentation on plugin parameters would suggest not) thanks

 

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...