There are other posts about this general issue, both in the Solidworks forum and at other places. I have been using those as a guide.
The kind of work we do needs to be viewed and considered in real size. We have need to calibrate the screen display of the part or assembly to 1:1 display on screen. The way that people solve this is to use modelView.Scale2 to manipulate the screen display. The code is simple:
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swModView As SldWorks.modelView
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
Set swModView = swModel.ActiveView
swModView.Scale2 = 1
The procedure is:
Draw a 10" line.
Run the macro
Measure the line length on screen (Say the line is 13")
Change the line to swModView.Scale2 = 10 / 13
This procedure is working fine but has one limitation:
You have to use the macro with your app sized to the same size as it was calibrated at. If you resize the Solidworks windows then the result will be wrong.
We are having a weird issue though. On one workstation locally the scale number keeps needing to change for some reason. We recalibrate the macro and it is good for a while and then the operator does something like opening a different file or perhaps closes and reopens Solidworks and suddenly the calibration is not accurate anymore. We have not been able to track that event down. The operator is using the macro with the app maximized (same way it was calibrated) to make sure that the window being the wrong size is not the issue.
A few questions...
1) What might be causing the one workstation to be changing in a seeming random way where it works reliably with the others?
2) Is there a better way that does not depend on calibrating with the application window always at the same size?
It would be easy to enter the pixel number for the width of the screen (1920 or whatever the resolution is) and enter an actual measurement of the screen width. The scale2 function just seems to be somewhat arbitrary. I am not opposed to an app from vb.net rather than VBA in order to use some windows API that might not be available in VBA.
Any help would be appreciated. This seems like a common issue out there.