Xref Paths
Hi all,
Let's say you are moving from Windows/AutoCAD to Linux/Bricscad. How do you handle the dependencies' paths stored inside all the existing drawings?
For example, a drawing has an xref with a path "driveletter:\path\to\another\drawing" or perhaps "\\servername\sharename\path\to\another\drawing". Bricscad on Linux won't recognize these paths. Due to the large number of existing drawings and xrefs (or other dependencies) it is not practical to change them individually.
Is there a tool in Bricscad Linux that will help migrate the drawings on a Linux system by allowing mass path changes of existing dependencies? I wonder if there is an obvious solution I'm missing here. (I know there are some tools on the Windows/AutoCAD side, but it would be much better if it could be done on the Linux/Bricscad side.)
Comments
-
Hi!
I am also looking for a solution for the XREF problem. In our office unfortunately we will have to work in a mixed enviroment, with Windows and Ubuntu installs. Until we find a way to solve the XREF paths problem we won't be able to work with the Linux version in a production enviroment.
PASTE CODE HERE
0 -
Next summer I am going to come up with a solution for this. I know that may be too long or that someone else may come up with one before then, but I have no time and cannot come up with a lisp routine now.
Regards,
Daniel
0 -
Something you might consider: Don't use harded code paths in your xref's.
We first noticed a problem years ago with hard coded paths when we started archiving drawings to CD's or sections of the server that was not backed up daily. If the paths change, the file can't be found. When we moved the files to a CD, the drive letters changed and drawings would not open.
I used to have a lisp routine that would strip paths from xref's, it still works with AutoCAD but it no longer with Bricscad. Maybe you could help find the problem? In Bricscad the routine can no longer tell the difference between a BLOCK and an XREF (it process all entries in the block table instead of only the xref's) and it cannot update the xref path when it finds an xref.
;; NoXRefPath - Removes paths to XRef's
;;
;;
(DEFUN C:NoXREFpath (/ tmp1 xfname pathname pathnone ct c test)
(princ "\nRemove XRefs Paths in Drawing, 3-1-00...\n")
(setq tmp1 (tblnext "BLOCK" 1))
(WHILE (/= tmp1 NIL)
(IF(/= (assoc 1 tmp1) nil)
(PROGN
(SETQ xfname (cdr (ASSOC 2 tmp1)))
(princ xfname) (princ "\n Current: ")
(setq pathname (cdr (assoc 1 tmp1)))
(princ pathname)
(setq pathname (strcat "\\" pathname))
(setq ct (strlen pathname))
(setq c ct)
(setq test (substr pathname ct 1))
(while (/= test "\\")
(setq test (substr pathname c 1))
(setq c (1- c))
) ;while
(setq c (+ c 2))
(if (/= c 2)
(progn
(setq pathnone (substr pathname c ct))
(if (= (findfile pathnone) nil)
(princ "\n File not found, Path not Changed")
(progn
(princ "\n New: ")
(princ pathnone)
(command "-xref" "p" xfname pathnone)
);progn
);if
);progn
(princ "\n No Change in Path")
);if
(princ "\n")
) ;progn
) ;if
(setq tmp1 (tblnext "block"))
) ;while
(PRINC)
)0 -
Clifford, your can exclude non-xref BLOCKS with the following if command (replace it into your code):
(WHILE (/= tmp1 NIL)
; This is an extra test, if 70 has flag 4 set (for xref, see AutoCAD 2010 DXF reference, page 58)
(IF (and (/= (assoc 1 tmp1) nil) (= (logand (car (assoc 70 tmp1)) 4) 4))0 -
Thank you all for your replies, suggestions and solutions.
When I wrote the first post I had in mind a migration scenario where the need would be one-off. But, as Marcelo Braga clearly indicated, the case applies equally well on a daily operational basis. This, I think, elevates its gravity. Let me put it this way: if we are going to suggest the combination Bricscad/Linux to anyone who has not heard of it, we cannot afford to have such bottlenecks.
I could stop using hard-coded paths, as Clifford Hood correctly points out, but this would still leave me with (a) my legacy drawings and (b) drawings from other sources. I'll have closer look at your code Clifford after the holidays, but a first thought is that it would also need to switch the backslashes (\) to forward slashes (/).
In the first post, I wrote about 'dependencies'. While the xrefs are the most ubiquitous, they are not the only ones. Another example may be a ctb attached to a layout. These also need re-pathing.
It seems to me there is a need for a new, Linux-only, Bricscad command which would facilitate the round-trip of drawings between Bricscad/Linux and AutoCAD/Windows.
0 -
Merry Christmas everyone!
1. At least Linux version of Bricscad should check on loading a drawing, if all the xref-s are present.
2. If not, then try to find these (possibly check numerous path combinations, let's say the drawing is /home/me/DWG/drawing.dwg and it has xref to C:\Docs\Drawings\Kitchen\Sinks\cool_sink.dwg, then it would check /home/me/DWG/Docs/Drawings/Kitchen/Sinks/cool_sink.dwg, then /home/me/DWG/Drawings/Kitchen/Sinks/cool_sink.dwg, then /home/me/DWG/Kitchen/Sinks/cool_sink.dwg, until /home/DWG/cool_sink.dwg, or the other way around. Maybe it should go up to /home/me in the next round, so it would check /home/me/Docs/Drawings/Kitchen/Sinks/cool_sink.dwg etc on the next round, maybe up until /home/me/ (if it starts with /home, otherwise not).
3. If any match is found, it would show a dialog asking, if you want to change the paths to relative ones. Yes/No
4. If some matches were not found, it would say so, maybe asking if you want to open xref editor or open dialog to point to files one by one.
Is this automatic matching scheme reasonable? Please share your thoughts.
0 -
my 2c
I think bricscad should recognize that it doesn't know where the file is, then ask the user for its location. After it's found, then bricscad should try to fix others based on that ones path. So, if you tell it one files in the directory it should search for others in that path
regards,
Dan
0