Absolute Origin

From Vectorlab
Jump to: navigation, search

The following article is not as such written to explain the origins to you, it is more an attempt to make things clear for myself. Any remarks or additions from somebody with more profound knowledge are very welcome and will most certainly find their way into this text. By Gerard Jonker

Absolute or Internal Origin: Originally

Originally the origin of VectorWorks was related to the position of the Print Area, fortunately this principle was abandoned around VectorWorks 9. Still the structure of VectorWorks leaves enough room for many misunderstandings. From this point the Absolute Origin will be referred to as Internal Origin. They are two words for the same thing. This in contrast to the User Origin, a user defined reference point, to which, ideally, all coordinates, as they are shown to the user, are referenced.

The origin(s) in VectorWorks

Internal Origin

Mathematically speaking the origin is defined as a point whose coordinates are declared to be (0,0). Within VectorWorks that is true too: the Internal Origin of Vectorworks is always the center of the Print Area as created when you open a new file.

Remark
The Internal Origin always stays in place. All other origins can be moved, including that of the Print Area. Moving the Print Area doesn't shift the Internal Origin.

The Internal Origin is what VW uses for all its calculations and how objects are stored.

User Origin

The User Origin allows us to use very large numbers and still work on the print area [1]. Since we can also move the Print Area there is a certain overlap in the functionality. As the internal origin is used for storage and calculation it is, in the case of working with large X and Y coordinates, always wise to set a new User Origin rather than moving the Print Area to the desired coordinates. (Only recently I ran into some sort of proof of the above statement, trying to render a project in VW 2009, that was placed on a moved Print Area rather than a newly set User Origin, the project refused to render in RenderWorks. Moving the whole model back to the Internal Origin and setting a User Origin fixed the problem.)

Using VectorWorks 9 or higher, the User Origin can always be reset to match the Internal Origin by using the menu command Set Origin and choosing the option: Set Origin to Drawing Center. Double clicking the Move Page tool, again, only true for VectorWorks 9 and higher, centers the Print Area to the User Origin.

Remark
In versions up to VectorWorks 8 the option: Set Origin to Drawing Center of the Set Origin menu command moves the User Origin to centre of the (moved) Print Area.

X, Y, Z

Unfortunately the User Origin is only editable in the X and Y coordinates or, if you wish: the user Origin can only be moved along the X and Y axes. This limitation is true for all versions of MiniCAD [2] and VectorWorks up to and including the current version (VW 2009).In VectorWorks, the Z coordinate of the User Origin is always equal to the Z coordinate of the Internal Origin.

Scales

Things get a tiny bit complicated when we use different scales within one file. VectorWorks stores only one set of (X,Y) coordinates for the User Origin, this means that on a layer Scale 1:100 the User Origin will be on a different position within the Print Area than on a layer 1:1. In general this is hardly noticed by the people using VectorWorks and I have never heard of any problems rising from it.

A similar effect, although not exactly origin related can be seen when you make a ViewPort to show a detail scale 1:5 of a floor plan scale 1:100 you will notice the viewport often appearing outside the Print Area. However, also in these cases I have yet to hear about serious problems rising from these differences in scale.

Sheet Layer Origin

Sheet Layers allow for another type of User Origin. This is not related to the User Origin valid for the document (Design Layers). The Sheet Layer Origin is valid for only one Sheet Layer and is relative to the Internal Origin. The Object Info palettes always displays values relative to this Sheet Layer Origin. But objects Copied and Pasted in Place between Sheet Layers ignore the different user origins on each of the sheet layers and are pasted relative to the internal origin. This is true for VectorWorks versions 11, 12 and 2008 (SP1)

See Sheet Layers below.

Rotate Plan View

In VectorWorks 2008 NNA introduced the Plan Rotation View. This allows you to work under an angle in your drawing, but in an orthogonal view, aligned with your screen. The coordinates displayed in the Object Info Palette are relative to the User Origin, aligned to the screen. No matter the rotation of the plan view or the position of the User Origin, the coordinates stored are always relative to the Internal Origin.

In the images below you see an example of a Rotated Plan View. And, although Point A is not moving (The view Rotates, the point stays in place), the Object Info Palette is suddenly displaying different data.

Rotatedplanview.gif

To prevent working with less nice numbers, it might be wise to set a User Origin at a suitable place in your file. Plan Rotation is saved with your views, the User Origin isn't. However you can paste a script in the Saved View that resets a User Origin together with a view.

To be able to switch between User Coordinates (the Data as displayed in the Object Info Palette) and the internally stored coordinates, when you are programming in VectorScript, you can use the following commands:


Warning

A warning is in place here. In Vectorworks 2008 the rotated plan view may cause serious problems in editing and creating objects through VectorScript. The VectorScipt functions always need to be checked for the use of the User Origin or Internal Origin, but now they also need to be checked for the use of the Rotated Plan View coordinates or the unrotated coordinate system.

Object origins

Many objects have their own origin from where they are built. The best known example is probably the symbol.

Symbols

The origin of the symbol definition is by nature the insertion point of the symbol, the centre of the cross-hair when you edit a symbol definition in 2D.

This has not always been such an logical assumption as in versions previous to VectorWorks 9 a moved origin was noticeable in the symbol definition, the insertion point showed coordinates equal to the negative of the distance the User Origin was moved. This was patched in VectorWorks 9[3]. History shows itself when you edit groups inside the symbol definition. The Object Info Palette will show (0,0) for a locus placed at the insertion point, but, when you group that locus and subsequently edit that group, will see the Object Info Palette shows the negative values of moved User Origin again as coordinates for that same locus. Without editing the group inside the symbol the difference between User Origin and Internal Origin also shows in the databar (if you have the "VectorWorks Preferences" option "Use Floating Datum" turned off).

Layerlinks

The origin of a layerlink is always the internal origin. This means that when you edit the original layer (the definition of the Layer link so to say), you will, of course, see the moved User Origin again.

Plug-In Objects

Plug-In Objects are pieces of written code executed when a change in data/parameters demands it. The code is read from the plug-in stored in the Plug-Ins folder inside the VectorWorks in the Application or user's Library folder on the Hard Disk, or from cache in case the object's code needs executing again. The resulting objects are drawn and stored in the file. (Unlike symbols the use of Plug-In objects does not reduce file size) Again, the insertion point is the Plug-in's origin.

VectorScript allows the programmer of the Plug-In object access to all predefined parameters. The user edits those parameters in the Object info Palette. The coordinates of the insertion point (the position of the object) can be read by the object's code too however, they always return the position of the Plug-in Object relative to the Internal Origin, whether the User Origin was moved or not. It seems like the User Origin is temporarily is reset to (0,0), making it impossible to let the object retrieve it's own location relative to the User Origin. Of course there are only a small number of Plug-In Object types that really need such possibilities. Therefore there has been only a limited number of complaints about this issue on the VectorScript list, showing a false image of reality. I ensure you that every end user who has ever tried to make a Plug-In object will immediately write a simple "I Show My Current Location" type of Plug-In once that barrier is lifted.

This problem exists in all VectorWorks versions that allow VectorScript Plug-In objects, up to and including the current version (VW 2008).

Here is a small sample code for a plug-In Object (Point) that shows it's current location (relative to the Internal Origin) in a text block, it uses the functions GetCustomObjectInfo and GetSymLoc to retrieve the position.

Example <pre=vss>Procedure HereAmI; VAR

    hParm, hParmRecord, hWall : HANDLE;
    PIOName, txtStr: STRING;
    x, y : REAL;

BEGIN

    IF GetCustomObjectInfo(PIOName, hParm, hParmRecord, hWall) THEN
    BEGIN
         GetSymLoc(hParm, x, y);
         txtStr:= Concat(x, '   /   ', y);
         Locus(0, 0);
         TextOrigin(0, 0);
         BeginText;
         txtStr
         EndText;
    END;

END; Run (HereAmI);</pre=vss>

Sheet Layers

Sheet Layers allow for each having their own user origin: this definitely adds up a lot of complexity to the VectorWorks origin theme: the sheet layer origin exists together with the normal user origin. In the same sheet layer.

The sheet layers' user origin can be set manually or programmatically.

Manually:
  • clicking on Navigation > Sheet Layers > select the sheet layer > Edit > edit the x, y values.
  • triggering the Set Origin dialog (the little square between the rulers, up on the right)
Programmatically:

Nevertheless, the normal user origin can be set only programmatically, when you are in a sheet layer.

Whenever you draw something programmatically, you should take into account the possibly shifted User Origin. But mind, the Object Info palette will always reflect the values according to the Sheet Layer Origin, while you are in a Sheet Layer.

Built-in Commands and Tools

The Set Origin command sets the User Origin. It will operate differently according to the active layer type:

  • Active layer is Design Layer: Set Origin sets the User Origin.
  • Active layer is Sheet Layer: Set Origin sets the Sheet Layer Origin (leaving the User Origin untouched).

The Move Page tool sets the Page Center relative to the User Origin. It will also operate differently according to the active layer type:

  • Active layer is Design Layer: double-click the Move Page sets the page center on the User Origin.
  • Active layer is Sheet Layer: double-click the Move Page sets the page center on the Sheet Layer Origin.
Note
place an Elevation Benchmark in the Annotation space of a viewport residing on a sheet layer whose normal user origin is shifted (programmatically with SetOrigin). The elevation benchmark displays the values of the internal (absolute, document) origin
  • NOT of the sheet layer origin.
  • NOT of shifted user origin
But the OIP data related to the same Elevation Benchmark will display the values related to the Sheet Layer -possibly shifted- origin. This might be regarded as a bug.

VectorScript

VectorScript is the powerful scripting language integrated into the core of VectorWorks based on the programming language Pascal. It has a rich set of functions and procedures to read and write data from and to the objects in the file, these can be found in the VectorScript Reference file, located in the Help folder inside the Vectorworks application folder.

Functions and Procedures

Unfortunately VectorScript is not always consistent in the origins used. I would have enjoyed the exclusive use of the internal origin. However, the worksheets use (parts of) the same set of functions and there the user origin is needed. But even when the procedures are not used in worksheets and are closely interrelated it makes use of different origins and the latter is even true for the 'origin' of the vertex indices as the example shows. This can make debugging your VectorScript code a demanding exercise.

Two VectorScript examples:

Procedure: Origin: index starts at:
GetPolyPt User Origin 1
SetPolyPt Internal Origin 1
GetPolyPt3D Internal Origin 0
SetPolyPt3D User Origin 0

Available routines

Routine Description Value returned/set
GetOrigin(x, y)
SetOriginAbsolute(x, y)
Gets the shift between User Origin and Internal Origin (should be renamed GetOriginAbsolute)
Sets the shift between User Origin and Internal Origin
Warning
you can use this command in Palette Scripts and External Scripts to change the User Origin. In Menu commands it only works within the scoop of that command, as soon as the command is finished, the User Origin is set back to the place it was before running the command.
Warning
GetOrigin began working in plug-in objects starting with VW 2010, but it outputs different values:
  • used in plugin objects: millimeters,
  • used in commands: current units.
Note
These calls should be used while on design layers. If your layer container is a Sheet Layer you should take into account SetSheetLayerUserOrigin, GetSheetLayerUserOrigin.

Current units (commands)

Millimeters (plug-ins)

GetSheetLayerUserOrigin(ShLayH, x, y)
SetSheetLayerUserOrigin(ShLayH, x, y)
Gets the shift between User Origin and Internal Origin in Sheet Layers
Sets the shift between User Origin and Internal Origin in Sheet Layers.

Since Sheet Layers can have each an own Sheet Layer User Origin, these routines take a Sheet Layer Handle as argument.

If you draw a locus on drawing using Locus{x, y}, the x and y will be related to the User Origin. You should keep this in mind while you program something in Sheet Layers. Nevertheless the values relative to the locus in Object Info will be relative to the Sheet Layer origin.

Current units
GetSymLoc(x, y) Gets the shift between User Origin and Internal Origin valid for objects inside symbols: it is the reverse value of the value returned by GetOrigin.
If you shifted the User Origin by {1, 1}:
  • GetOrigin will return {1, 1}
  • GetSymLoc will return {-1, -1}
  • If you were to apply the correction on a Design layer you would then use {-1, -1} (reverse of GetOrigin)
  • If you were to apply the correction on a Object inside a Symbol definition you would then use {1, 1} (reverse of GetSymLoc )

You can also use <code=vss>GetSymLoc(NIL, symLoc.x, symLoc.y);</code=vss> for getting the User Origin shift valid for symbols. See Experiment 3.

Since the issues with Moved Origin arise specially when dealing with symbols, you better keep this in mind. Seldom you are to correct origin issues outside symbols. And you cannot apply any correction for Plug-In objects, since the values returned are always 0,0 (personal internal origin of the PIO instance on drawing).

Current units
SetOrigin(x, y) Sets the new User Origin relative to the current User Origin
SetOrigin should be renamed to SetUserOriginRelative
Note
please be WARNED that every time you run SetOrigin, the value added is relative to the previous User Origin! See Experiment 2
Note
You can use this command in Palette Scripts and External Scripts to change the User Origin. In Menu commands it only works within the scoop of that command, as soon as the command is finished, the User Origin is set back to the place it was before running the command.
Current units
x := GetPrefReal(68)
y := GetPrefReal(69)
SetPrefReal(68, x)
SetPrefReal(69, y)
Gets/sets the Page Center relative to the Internal Origin
If you need to convert to page millimeters you can use the following standard subroutine: Page Inches to Page Millimeters.
Page inches
x := GetPrefReal(80)
y := GetPrefReal(81)
SetPrefReal(80, x)
SetPrefReal(81, y)
Gets/sets the Page Center relative to the Internal Origin.
Like the routines above, but using current units divided for the current scale. If you have a scaling active, this infuence the value too, if you wish to set it.
Thus, if you have:
  • units: meters
  • scale 1:100
  • and apply a shift {1, 0}

the page center will move exactly 1 meter from the Internal Origin

  • units: meters
  • scale 1:50
  • apply a shift {1, 0}

the page center will move exactly 1/2 meter from the Internal Origin.

If you have a printer scaling factor applied (Page Setup > Print Setup > VectorWorks Scale) this will influence the value to set:

  • you wish to shift the page of {1, 0}
  • you have a printer scaling factor of 50%,

due to the scaling factor the page will shift of the half of what you need for centering the page. So you should take into account the scaling factor in order to correct the viewed page position.

I find this most confusing (orso). <pre=vss> { read page origin relative to internal origin } layScale := GetLScale(layHandle);

pageOrig.x := GetPrefReal(80) * layScale; pageOrig.y := -GetPrefReal(81) * layScale;

{ set the page origin to a point "c"} GetOrigin(orig.X, orig.Y); scalingFact := GetPrefReal(70);

SetPrefReal(80, (c.X + orig.X) / layScale / scalingFact); SetPrefReal(81, -(c.Y + orig.Y) / layScale / scalingFact);</pre=vss>

Current units / current scale

Set the origin

You can set the Origin through a script so you can store a few often used User Origins in your document.

  • Choose "New Resource in "Your File Name" From the Resource Palette and choose for "VectorScript Palette..."
  • Call it "My Origins".
  • Choose again "New Resource in "Your File Name" From the Resource Palette, but this time choose for "VectorScript".
  • Paste into the VectorScript Editor dialog the next script:
PROCEDURE SetTheUserOrigin;
 VAR
   newOrX, newOrY, curOrX, curOrY :REAL;

BEGIN    
    newOrX := 0; {Change this 0 to the desired horizontal shift of your User Origin}
    newOrY := 0; {Change this 0 to the desired vertical shift of your User Origin}

    GetOrigin(curOrX, curOrY);   {getting the position of the current User Origin}
    SetOrigin(-curOrX, -curOrY); {setting the User Origin to the Internal Origin}

    ModelPt2DToScreenPt(newOrX, newOrY); {Translating the User Origin to the current Plan View Rotation}
    SetOrigin(newOrX, newOrY); {setting the User Origin relative to the Internal Origin}
END;
Run(SetTheUserOrigin);

Instead of using separate scripts to store your User Origins, you can also paste the above script into the script section of a saved view. So every time you want to go to a certain area of your file the View gets set, the Plan Rotation gets set and even the Origin gets set. A Detailed instruction of this can be found in the OriginExampleFile.

Download the OriginExampleFile here (VectorWorks 2008 or higher. On 31-12-08 I changed the script so you can jump from one rotated plan view to another rotated plan view, without going to 0° rotation first).

Reset the origin

By far the easiest 'fix' for the origin problems within VectorScript is to reset the User Origin to the Internal Origin and to restore the User Origin at the end of the code.

Please remember that:

  • if you run the code in a command, the applied shift is nevertheless only temporary: it will last only during the script execution.
  • if you run the code in a plug-in object the origin shift is useless: pios only see their own space.
...
GetOrigin(originX, originY); { store user origin }
SetOrigin(-originX, -originY); {reset user origin to internal origin: This also works in Rotated Plan Views}

{ ... do something ... }

SetOrigin(originX, originY); { restore user origin, within the same Plan View rotation!!}

This is not the best solution: if the user breaks off the execution of the code by using [Cmd period] (s)he is left with a file that has the User Origin reset.

BTW: In Rotated Plan Views I found the command

 SetOriginAbsolute(0, 0); { reset user origin to internal origin }

to cause problems. You probably need to use ModelPt2DToScreenPt(--,--); first.

It is better to test the functions you use for different origin settings and correct the code where needed by adding or subtracting the User Origin values:

<pre=vss>GetOrigin(originX, originY); { user origin coordinate relative to the internal origin AND relative to the current Plan View Rotation }

GetPolyPt(h, i, px, py); SetPolyPt(h, i, px + originX, py + originY); {Adding the User Origin X and Y values!}</pre=vss>

<pre=vss>GetOrigin(originX, originY); GetPolyPt3D(h, i-1, px, py, pz); SetPolyPt(h, i-1, px - originX, py - originY, pz); {Subtracting the User Origin X and Y values!}</pre=vss>

Make sure to always test drive your code with a shifted User Origin AND inside symbols, too. I have a big wish for the Vectorscript language: Please NNA programmers, let the VectorScript functions and procedures use, as much as you can, the Internal Origin. And let the index always start at 1, not zero.

Conclusion

VectorWorks is a great tool. I would like to thank the NNA programmers who write and maintain this "Quality of Life Enhancer" I use at a daily bases. I use VectorWorks for 2D drafting and 3D modelling too. It has its limitations but in my humble opinion they can easily be overcome as long as we are aware of them, and that is the reason behind this article. The real fun (and challenge) starts when we have to write Plug-Ins when we need functionality that is not provided in the standard package.

If you like to see how I stumble along with VectorScript and its origins in real life then please feel free to use and explore my "Move or Snap Page.vsm". It is open code. You can find it here

I'd like to take the opportunity to thank Orso for the additions in the form of experiments and images.

Thank you for reading, Gerard Jonker

Notes

  1. Holland has the origin of her National Cartesian Grid placed about 100 kM southwest of Paris to ensure we always work with positive numbers in the X and Y coordinates and to avoid mix up between X and Y as Y is always a much higher number than X.
  2. MiniCAD 7 was the last version that linked the Y and the Z coordinates. Instead of not moving the Z =0 coordinate as is done now. MiniCAD is the previous name for the same product line. The name was dropped after version 7 when Nemeteschek North America introduced VectorWorks 8. Nemetschek North America was previously known as Diehl Graphsoft and before that as Graphsoft just to mention some more historic names.
  3. The patch is only hiding the shifted User Origin in the Object Info Palette. The programmatical access is not patched. When accessing coordinates of objects in Symbol Definitions through VectorScript the values returned in case of a shifted User Origin are the inverse of the shift returned by GetOrigin: see Experiment 3

Experiment

The Page Origin is always relative to the Internal Origin. In order to better understand the origin issue and the different values returned between shifted page or shifted user origin, do as follows:

  • Create a blank document
  • draw a locus at insertion point (0, 0)
  • and launch the following scriptlet:
PROCEDURE CheckOrigin;
VAR
    pageShiftedBy, originShiftedBy: POINT;
BEGIN 
    { check for the shift between User Origin and Internal Origin }
    GetOrigin(originShiftedBy.x, originShiftedBy.y);
    
    { check for the shift between User Origin and Page Center }
    pageShiftedBy.x := GetPrefReal(80);
    pageShiftedBy.y := GetPrefReal(81);
    
    AlrtDialog(Concat('Shift User Orig./Internal Orig: ', originShiftedBy, Chr(13), 'Shift Page origin/Internal Orig: ', pageShiftedBy));
END;
Run(CheckOrigin);
  • The script will return an alert with the following values:

<pre=vss>Shift User Orig./Internal Orig: {0, 0} Shift Page origin/User Orig: {0, 0}</pre=vss >

  • Now shift the user origin. Double-click the small square in the intersection point between the rulers.
Set Origin button.gif
The Set Origin dialog opens (should be called Set User Origin). The cursor changes form. The user origin is set at the next click. The internal origin doesn't change, cannot change.
Set Origin Dialog.gif
  • Relaunch the script above, you'll get some values like the following (dependent on your units settings):

<pre=vss>Shift User Orig./Internal Orig: {-12.568, 55.899} Shift Page origin/Internal Orig: {0, 0}</pre=vss >

  • Now shift the page origin. Go to the Move page tool and move the page somewhere else.
MIND: Double-clicking on the Move Page tool centers the page on the User Origin! But the value of the page center as returned by the preferences 80, 81 or 68, 69 is relative to the Internal Origin! (I am so sorry, it is so confusing...)
Set Page Origin.gif
  • Relaunch the script above:

<pre=vss>Shift User Orig./Internal Orig: {-12.568, 55.899} Shift Page origin/User Orig: {78.651, -45.782}</pre=vss >

  • Now bring the user origin to the internal origin. Double-click again the small square, when the dialog Set Origin appears (call it Set User origin), click on Set Origin to drawing center (this is highly misleading: it should be called: Set User Origin to Internal Origin.
    Relaunch the script above:

<pre=vss>Shift User Orig./Internal Orig: {0, 0} Shift Page origin/User Orig: {78.651, -45.782}</pre=vss >

You'll notice that the page shift is equal to the one before: the page is shifted from the internal origin, as before.
  • Now bring the page to the internal origin. Double-click Move page tool (please MIND that this tool centers the page on the User Origin!). The page centers on the User Origin. If the user origin is shifted, the page center value returned by our script is nevertheless always relative the Internal Origin. In our case, below, the User Origin is equal the Internal Origin.
    Relaunch the script above:

<pre=vss>Shift User Orig./Internal Orig: {0, 0} Shift Page origin/User Orig: {0, 0}</pre=vss >

Everything went back to the internal origin.

Experiment 2

A true pitfall to be minded, is that the user origin as set by SetOrigin is relative to itself. That is, every time you run SetOrigin, the value is reset starting from the previous:

  • Create a blank document
  • draw a locus at insertion point (0, 0)
  • and launch the following scriptlet:
    Run it more times, the value returned by GetOrigin will always increase.
PROCEDURE CheckUserOrigin;
VAR
    originShiftedBy: POINT;

BEGIN 
    {SetOriginAbsolute(0, 0);} { uncomment this to reset the values to the Internal Origin }
    SetOrigin(0, 10);
    
    { check for the shift between User Origin and Internal Origin }
    GetOrigin(originShiftedBy.x, originShiftedBy.y);
    
    AlrtDialog(Concat('Shift User Orig./Internal Orig: ', originShiftedBy));
END;
Run(CheckUserOrigin);
  • In order to reset the values to the true Internal Origin, you can use SetOriginAbsolute(x, y).

Experiment 3

In Symbols, the shift between User Origin and Internal Origin is different than what is returned in Design Layers: it is the negative value of the Layer's shift. The experiment below shows the issue:

  • Create a blank document
  • move the User Origin by a round value (just for easing up things), for example: {1, 0}
  • create a symbol with a locus at insertion point {0, 0}, select it,
  • and launch the following scriptlet:
    • it returns the shift between User Origin at design layer level
    • it returns the coordinates of the center of the locus INSIDE the symbol definition.
    While you would expect the center to be located at {0, 0} this is not true: the value returned is the negative of the shift between User Origin and Internal Origin:
PROCEDURE CheckUserOrigin_InSymbols;
VAR
	origin, cenH, symLoc: POINT;
	symH	: HANDLE;
BEGIN
	{ get shift between User Origin and Internal Origin at Design Layer level }
	GetOrigin(origin.x, origin.y);
	alrtDialog(concat('Shift User Origin/Internal origin: ', origin));

	{ please make sure FSActLayer to be your symbol.... just to avoid getting even more confused :) }
	symH := GetObject(GetSymName(FSActLayer));

	HCenter(Fin3D(symH), cenH.x, cenH.y); { center coordinates of the first obj inside the selected symbol }
	alrtDialog(concat('center: ', cenH)); { it is not 0,0! }

	{ passing NIL as argument to GetSymLoc 
	will return a shift value valid for syms, 
	or reverse the getOrigin values }
	GetSymLoc(NIL, symLoc.x, symLoc.y);
	alrtDialog(concat('symloc: ', symLoc));

END;
Run(CheckUserOrigin_InSymbols);
Origin1 internal.png
Origin2 user.png
Origin3 page.png
VectorScript, VectorWorks are registered trademarks of Nemetschek North America.
Please go to the official Nemetschek home page for more information.

VectorWorks
Third Party
VectorScript
Recent Changes: