Jump to content

David Bengali

  • Posts

  • Joined

  • Last visited

Everything posted by David Bengali

  1. Hi I am wondering if anyone can advise - I have enabled the reset on move and reset on rotate flags in my PIO, and the handling of these events seems to work correctly when a single PIO is selected. However, if I select other objects along with the PIO, there are some issues. If the other objects are simple objects like rectangles, etc, their 'preview shadows' move as expected while the operation is in progress, but they do not redraw correctly after the move or rotate operation is completed. The other object appears to remain drawn in its old location. But if I move my mouse around, I can find that the object did in fact move / rotate correctly but is now invisible except to selection highlighting. If I select it and change an attribute, the drawing correctly refreshes. The incorrect 'old' object disappears. If I have multiple instances of my PIO selected, and perform a move or rotate, one of them behaves correctly. The others mostly behave correctly, but appear grayed. If I select them and change an attribute or otherwise force a reset, they return to normal. In addition, I sometimes observe drawing objects that were not part of the selection becoming grayed when I perform these operations. Is there something I am doing wrong or a step I need to add?
  2. Hi I am wondering where we can find documentation on new functions in 2020 such as vsoStateGetRotN and how they differ from the previous versions? The function reference wiki currently has no information other than the parameter names. thanks!
  3. Just one quick followup @Vlado - It looks to me that if a parameter is a Dimension or a Control Point, then indeed vs.GetRField returns the value with full precision. However, if the Parameter is a Number, vs.GetRField returns a string representation that is truncated at 8 decimal places, even if the value shown in the OIP has more precision. Not sure if this is related. best, David
  4. Thank you @Vlado (and @Pat Stanford and @MullinRJ ) for tracking this down with me! And for the current workaround info. David
  5. Hi Pat, I am working on a scale of meters and feet, and using the values of control points and other parameters to perform calculations that then determine how the object is drawn, as well as what the values of other parameters will be, in addition to the position of various control points, as a result of the math. The errors pile up surprisingly quickly with a series of relatively simple mathematical operations, which is how I discovered this issue -- in some cases I start to see numeric errors appear in the first three decimal places of results when the underlying Parameter values can only be accessed to 6 decimal places and this error propagates. Without going into to much detail, one of the main issues (but not the only one) is that this limitation also prevents control points or drawing elements whose position is driven by mathematical calculations (or even simply by the value of another parameter) from landing in the spot that one would expect when using snapping. Two drawing elements that should be in the same place in the drawing end up slightly offset, which is not what a user will expect from snapping. Since Vectorworks clearly has access itself to more precision, and can show it in the OIP, I am surprised that it prevents us from getting those values inside of a script, especially since the values are already stored in a float, which does not have this limitation intrinsically.
  6. Hi, thanks Raymond, Just to clarify, float variables in Python do have more decimal places than this, I believe the same internal precision as REALS in VectorScript. Float's in Python are already the equivalent of double's. Can you verify that, in the case of a PIO built with VectorScript, when you access the Parameter values inside the script, you are getting all the available decimal places of precision, e.g., matching what you see in the Object Info Palette with the document unit preferences set to display 9 or more decimal places? What I am observing is not an issue of float variable precision. It specifically refers to what Vectorworks does, not to variables in general, but to PIO Parameters when it accesses them, at which point it seems to truncate the value, even when more decimal places are displayed in the Object Info Palette. I can assign a float value with greater precision than this to any variable within Python. But Vectorworks appears to have dropped that available precision when it stores Parameter values in the vs object's "P" variables, which is where we must look up these values from within the code. So, the precision is not being lost when storing the parameter value into another variable. It seems to be gone from the beginning of execution. There is no way that I know of to access Parameter values other than via vs.P[parameter name], and it does not look like there is anywhere to specify greater precision in the plugin definition parameter list, at least that I have found so far. Also to clarify, I am observing this not just with Control Point parameters, but with other Number parameters as well
  7. To make matters worse, if I expose the control point fields in the OIP, and turn up the decimal places document unit preference to a high value, I can see that if I snap the control point to a reference object whose position requires a large number of decimal places to represent, the PIO's control point field shows the correct value, with all the decimal places. But I just am unable to access that value from inside the scripting environment. If I expand the Globals -> vs module in the variable inspector (I am using Aptana as recommended on the wiki), the value of PControlPoint01X or PControlPoint01Y is truncated to 6 decimal places even though the OIP field shows more decimal places. I have tried changing units between feet and meters to see if that makes a difference, but it does not. In fact, this is not limited to control points (perhaps I should change the post title). For example, if I type a value with 9 decimal places into the field for a plain Number parameter, the value is accepted and displayed. But if I inspect the value of that parameter from inside the scripting environment, it has been truncated to 6 decimal places. Is this simply a (severe) limitation of scripting in Vectorworks? Or is there a way around this?
  8. Wondering if anyone can advise on this - I'm having some trouble with control point precision that is leading to erroneous behavior in a plugin object. I detected this issue in part through the debugger. Basically, when I drag a control point, it seems that the values I get when I access its coordinates from inside the scripting environment are truncated to only 6 decimal places. This introduces error into calculations based on that value. I have tested further by creating an object to use as a snapping location, and setting the position of this object to coordinates that require more than 6 decimal places to represent. If I increase the decimal place precision in the document unit preferences, I can see all of these decimal places in the OIP for the reference object. If I drag a control point in my plugin object to snap to this reference object, and then, by setting a breakpoint, inspect the value I get inside my script by accessing the control point (with, for example, vs.PControlPoint01Y), I see the value is still truncated, regardless of the document unit / precision settings. At only 6 decimal places, this can introduce pretty significant error. Is there some obvious thing I am missing to correct this behavior? I would expect that when I snap a control point to a location, the control point would be assigned a value as accurate as possible, or at least as accurate as the document settings indicate. Not sure if this is specific to Python scripting or not.
  9. 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.
  10. 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
  11. 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?
  12. 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
  13. 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
  14. 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
  15. 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.
  16. 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.
  17. 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?
  18. 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.
  19. 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
  20. 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.
  21. 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?
  22. 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
  • Create New...