converting for document units....

[Jayme McColgan]

I recently ran into an issue where I haven't been accounting for the document units in my PIO... **facepalm** so I'm going back through my plugins and fixing any hard values. I have a plugin that does a lot of drawing using rect and arc... now that's a lot of values I have to convert (currently using vs.ValidNumStr(f'{-6.2}"')[1] format to convert).

 

below is an example of something I need to convert. is the way I'm doing it the best or is there a more easy "global" way of converting for the document units?

 

vs.BeginGroup()
vs.RectangleN(-12,-12,0.03,0,24,24)
vs.Arc(-8.9,3.0,-2.93,-3,90,360)
vs.Arc(2.93,3,8.93,-3,90,360)

vs.Arc(4.31,7.34,5.18,6.47,90,360)
vs.Arc(6.437,7.34,7.31,6.47,90,360)
vs.Arc(8.93,3.849,9.81,2.97,90,360)
vs.Arc(8.93,-2.97,9.81,-3.84,90,360)
vs.Arc(6.43,-6.47,7.31,-7.34,90,360)
vs.Arc(4.31,-6.47,5.18,-7.34,90,360)
vs.Arc(-5.18,-6.47,-4.31,-7.34,90,360)
vs.Arc(-7.31,-6.47,-6.43,-7.34,90,360)
vs.Arc(-9.81,-2.97,-8.93,-3.84,90,360)
vs.Arc(-9.81,3.84,-8.93,2.97,90,360)
vs.Arc(-7.31,7.34,-6.43,6.47,90,360)
vs.Arc(-5.18,7.34,-4.31,6.47,90,360)
vs.EndGroup()

 

[michaelk]

If you specify units it will honor those units no matter what the documents units setting is.

 

So vs.RectangleN(-12",-12",0.03,0,24",24") will draw the expected rectangle even if the units are millimeters.

 

 

[MullinRJ]

Hi @Jayme McColgan,

   You can also change your document units briefly to be in the units you need for the numerical drawing. Might save a bit of editing.

 

To draw in inches, precede your drawing code with:

UPI = vs.GetPrefReal(152)   # save document scale
vs.SetPrefReal(152, 1)           # Inches
 

And follow it with this:

vs.SetPrefReal(152, UPI)      # restore document scale
 

If you set Pref152 to 25.4 you will be drawing in mm, and if you set it to 0.083333333, you will be drawing in feet, etc.

 

HTH,

Raymond

[JBenghiat]

9 hours ago, michaelk said:

If you specify units it will honor those units no matter what the documents units setting is.

@michaelk does this also work in python? In VS, numerical constants can utilize both standard and metric unit marks, and the conversion is automatically handled. Last I checked, this didn’t work in Python, but that was a while ago. 
 

@Jayme McColgan a general coding best practice is to avoid “magic numbers,” basically un-named constants. In practice, this can become impractical if you are creating poly lines via script, but ind your case you do have a bunch of repetition, so, for example:

kLeftBound = -7.34

would reduce the number of conversions, as well as make maintenance and readability easier. 
 

Raymonds approach is fantastic for a quick fix, but I would do the opposite:

retrieve the UPI (Units Per Inch) and then multiply any constants defined in inches by the UPI.

 

If you’re specifying dimensions in mm, define UPMM by dividing the returned preference by 2.54

[Jayme McColgan]

@michaelk you can't do vs.RectangleN(-12",-12",0.03,0,24",24") in python... I would have to convert all those values to a string first and that defeats the purpose of all this... lol

 

@MullinRJ that seems like a good quick fix. Is there any downside to doing this?

 

@JBenghiat i ended up going that route lat night after posting this. converting everything to a variable and using vs.ValidNumStr(f'{-6.2}"')[1]. in another plugin I used 8.5*vs.GetUnits()[3]. they both seem to work fine.

 

[michaelk]

3 hours ago, Jayme McColgan said:

@michaelk you can't do vs.RectangleN(-12",-12",0.03,0,24",24") in python... I would have to convert all those values to a string first and that defeats the purpose of all this... lol

 

 

I did not know that.  What a bummer.  

 

Learning this is just going to delay my inevitable switch to python 🙂 

[MullinRJ]

28 minutes ago, Jayme McColgan said:

@MullinRJ that seems like a good quick fix. Is there any downside to doing this?

 

Not that I can think of.  

[Sam Jones]

4 hours ago, michaelk said:

Learning this is just going to delay my inevitable switch to python 🙂 

 

Why inevitable?  There are other downsides to python.  I must confess that I hear about them second hand, but if true, I'm never going there.

 

[MullinRJ]

Hi @Sam Jones,

   It is true, Python has its quirks, but so does the VS language. You've learned many of them over the years. In all, Python has more upsides than down. As you are very comfortable with VS, I wouldn't recommend moving for the sake of moving. Unless you you need something that Python can offer, like access to external packages, or superior list management, I'd say stick with Pascal. If you ever need Python help, you still don't have to learn it, just ask and Python help will come to you. 😉

 

Raymond

[michaelk]

@MullinRJ I have no idea what VS quirks you might be talking about 😱.  I'll keep an eye out for them.

 

@Sam Jones I just want to learn it better.  The few small things I've tried have all worked.  And there are more applications for it outside VW.  

 

If I ever get time to do something outside of VW…