Jump to content

Hidden origin ????

Recommended Posts

Hi i've been fighting with RDLVP for a while now (see my past post on chained reference : http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Main=25754&Number=125369#Post125369)...

I feel there's a "hidden" origin in the file somewhere that make them move when in chained references is that possible???

the problem typically occurs when the origin of some file as been "reset" with the "set origin..." tool ???

>> Is this possible???

Here is what happens :

1. I've got 4 floors of the same building with their origin all set at the cross section of axe1 and axeA...

2. I reference them in a new file as RDLVP, they all come nicely one on the top of the others, nicely superposed. I save the file under i.e. the name "REFERENCES.vwx" The purpose is to create a reference file that contains all the floors and that I will attach (as a RDLVP) in all my sections in order to be able to draw them

3. whenever I create in a new section file a RDLVP with the external reference 'REFERENCES.vwx" all my floors are splitted as if they where having different origins...

=> I JUST DONT UNDERSTAND what happens !!!

=> it is as if the floors file remember "past" origins that they retain as a real origin

=> The floors plan are not splitted randomly, their positions seem to be in relation with some "initial" origin which setting I don't know how to see and how to change

=> in order to double check this, i've referenced the floors as referenced layers (the old way) : the result is that they all come nicely superposed. YET if I select "Ignore source user origin" they do the splitting... exactly in the same position as above...


Does anyone PLEASE have a clue on what's happening???????

Link to comment

Well as an after thought :

How come this mess happen at all?

Am I the only one that find this origin problem REALLY anoying?

How do you guys feel about it?

I mean this could be called a BIG BUG or not?

It's quite amazing that something as important as the origin of a file could'n't have a more fluid working process... !!!

What do you think ? Would you agree or do I have to question my methodoly???

Link to comment

it is not as if the origin has migrated by accident.

The problem happens whan the origin is set accurately with the set origin tools.

The fact is that if you have a file that has his "new" user orgini set with the "set origin" tools, it DOES NOT behave like the copy of the file where the full drawing has been moved to match the same origin...

>>> i'm not sure this is clear so put it this way :

1. we have file A and file B that are identical

2. In file A : we set a new origin by using the "set origin" tool at a distance x=100 and y=200 from the initial origin.

3. In file B : we select the whole drawing and move it by x=-100 and y=-200

=> the result is that we still have 2 identical file (they look totaly the same except for the position of the "page") yet they behave differently.

=> If you reference them as RDLVP ia a first file called "reference.vwx" they superpose nicely with the same origin.

=> YET if you reference the file "reference.vwx" you will see that the files split considering each different origins !!!!!!


=> if you reference them the old way and select "ignore source document origin" they split the same way

In my view this behaviours is A BIG AND ANOYING PROBLEM.

Link to comment

I've taken to turning off the "Rulers" display preference. The shortcut button to the "reset origin" tool is very close the the mode selection icon of all the other tools (top left). It's pretty easy to reset the origin and not notice by accidentally clicking on this icon.

Link to comment


The VW Parent File A declares the Drawing Origin ( default = 0,0 ) for all subsequent Container insertions.

If you desire a different Origin then create a Parent File B with Origin offset and it will be the overriding structure for all embedded child-Containers relative to it.

Each file will display data based on the relation to the ParentOrigin.

That being said VW allows for User declaration of unlimited Child-PageContainer Origins via "Set Origin ",

but these supplemental Origins are always relative to the Parent File Origin.

Therefore, since referenced files may be of kind Parent and/or Child, they import into the Parent File C with their Origin information relative to the existing Parent C Origin.

However, this rule does not apply to DWG/DXF imports which may override the VW File Origin in order to rectify the translation

( thereby creating endless hassle for VW Users, et al. ) .

Link to comment

Thank you for the explaination Islandmon.

What's the point of such a logic? I see no advantages and only anoying problem resulting ?

In particular, you can't trace where's the Parent Origin unless you draw it yourself manually and lock it at the very beginning and if you're not aware this should be done (why should it? ) it's a big mess !

Basically it means that VW cannot "really" change the origin. The set origin command is in fact only an artifact that only makes it look as if the origin had changed while in fact it just a kind of make up that adjust the value of the rulers.

Anyway if NNA doesn't intend to change this (or cannot) they should at least have a built in zero that is "unmovable", "unerasable" etc...

sorry I didn't answer earlier (work work work :-))

Link to comment
Guest Frank Brault

If you were to solve this problem, what would the rules be?

I am very interested in your ideas on how this would work better for you.


Link to comment

I am having the same set origin file problem. We have five working files, all referencing a title block. Only one of the files has a sheet layer with viewports. When the date is changed in the title block, the title block moves inside the viewport (the other drawings without viewports are still okay). Only fix is to delete the title block viewport and create a new one. This is the second job I've worked on in 6 months that I have had this problem. I definitely prefer AutoCad's viewport set up which is much simpler.

Link to comment

Fix the 'date changing TitleBlock problem' by editing the the TitleBlock Record Symbol

to eliminate the DateField text from expanding beyond the rightside title border

( which forces the VP TB to move to the left in order to maintain the declared VP center ).

Either reduce the DateField font size or shift the DateField to the left by a min. 2 character spaces.

Link to comment
  • 2 years later...

being able to move the origin of the drawing is crucial to my workflow: I get drawings from client and assorted venders with origins often in places which are worse than meaningless to efficient drafting (00@center of the plasterline in theaters). Any other position is detrimental to drafting quickly and efficiently. Being able to employ the Set Origin tool to position the origin where I need it is great. Subsequently, having the origin move randomly is extremely detrimental.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...