TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Hangman on January 22, 2007, 02:25:12 PM
-
Aaaagghhhh, ... help
THEY (the bad guys) changed the server over the weekend.
We have just spent the last four hours trying to fix the mess THEY made for us.
I am in a bit of a pinch and need your help.
I'm not good enough with code to write one quickly that will do what I need.
Can you guys put together a code that will:
Search the drawing for xrefs &/or image files
Drawings have xrefs & image logo's - some are nested
If nested, ALERT user of such, nothing more for nested stuff.
check the path of these xrefs &/or image files
Original path = D:\Drawings ... (Drawings 2005, 2006, or 2007)\ ...
(The path change was only the drive. It changed from D: to X: Everything else in the path is the same)
If the path is D:\Drawings ...
Then change path to X:\Drawings ...
The image logo's are all in the same directory. The only thing that changed was the drive letter, from D:\ ... to X:\ ...
Uuummm, ... what other info do you need ??
ACAD 2007
...
-
Would it not be easier to talk to "the bad guys" and have them change the drive mapping back to the way it was? IMO that seems like a much better\easier solution.
Ron
-
You might be able to change this to suite your needs. Right now it doesn't change anything paths, it just lists them.
(defun Testing (/ Doc LayoutCol EndList)
; Returns a list of list of all the Xrefs and Images with their paths within a drawing.
(setq Doc (vla-get-ActiveDocument (vlax-get-Acad-Object)))
(setq LayoutCol (vla-get-Layouts Doc))
(vlax-for i LayoutCol
(vlax-for Obj (vla-get-Block i)
(cond
((= (vla-get-ObjectName Obj) "AcDbRasterImage")
(if (not (assoc (vla-get-Name Obj) EndList))
(setq EndList (cons (cons (vla-get-Name Obj) (vla-get-ImageFile Obj)) EndList))
)
)
((and (= (vla-get-ObjectName Obj) "AcDbBlockReference") (vlax-property-available-p Obj 'Path))
(if (not (assoc (vla-get-Name Obj) EndList))
(setq EndList (cons (cons (vla-get-Name Obj) (vla-get-Path Obj)) EndList))
)
)
)
)
)
EndList
)
-
Would it not be easier to talk to "the bad guys" and have them change the drive mapping back to the way it was? IMO that seems like a much better\easier solution.
Ron
Ditto ^^
-
This might help the xref issue.
http://www.theswamp.org/index.php?topic=11274.0
-
They're old farts, set in their ways. You can't teach an old dog new tricks.
No, it appearantly was the decision of the IT manager and the big man who signs the pay checks. Their response is, "Deal with it, it's here to stay."
Thanks for the thought though.
To my understanding, they decided to change it when they updated the server because there are too many engineers and others having issues with USB keys and external drives and other things with their laptops that conflict with a servers drive letters being D: E: & F:. So they decided to move the drive letters to the end of the alphabet so there would be no conflicts with external connections and automapping.
-
. . . there are too many engineers and others having issues with USB keys and external drives and other things with their laptops that conflict with a servers drive letters being D: E: & F: . . .
Well, as long as their priorities are straight . . . who should give a rip if production drawings get hosed until multiple manhours are spent cleaning up their mess.
-
. . . there are too many engineers and others having issues with USB keys and external drives and other things with their laptops that conflict with a servers drive letters being D: E: & F: . . .
Well, as long as their priorities are straight . . . who should give a rip if production drawings get hosed until multiple manhours are spent cleaning up their mess.
Six hours so far (per drafter) and I have a deadline today, due in two. Grrrrrr ... :realmad:
-
this thread (http://www.theswamp.org/index.php?topic=7628.0;all) helped me when our server changed and we lost the xrefs
-
You can try this. It will only work if the path is saved to the xref with the drive letter.
(defun c:ChangeDriveLetters (/ Doc LayoutCol tempPath)
; Change the drives from "D:\" to "X:\" for xrefs and images.
(setq Doc (vla-get-ActiveDocument (vlax-get-Acad-Object)))
(setq LayoutCol (vla-get-Layouts Doc))
(vlax-for i LayoutCol
(vlax-for Obj (vla-get-Block i)
(cond
(
(and
(= (vla-get-ObjectName Obj) "AcDbRasterImage")
(= (strcase (setq tempPath (substr (vla-get-ImageFile Obj) 1 3))) "D:\\")
)
(vla-put-ImageFile Obj (strcat "X:\\" (substr tempPath 4)))
)
(
(and
(= (vla-get-ObjectName Obj) "AcDbBlockReference")
(vlax-property-available-p Obj 'Path)
(= (strcase (setq tempPath (substr (vla-get-Path Obj) 1 3))) "D:\\")
)
(vla-put-Path Obj (strcat "X:\\" (substr tempPath 4)))
)
)
)
)
(princ)
)
-
All would be okie-dookie if the ``projectname'' variable was set. (please look into it.)
-
The "projectname" variable for most all my drawings is "".
-
I guess this is what would happen if the "projectname" variable is "".
Command:
Command:
Command: changedriveletters
Command:
Command:
Absolutely noth'n.
-
I guess this is what would happen if the "projectname" variable is "".
Command:
Command:
Command: changedriveletters
Command:
Command:
Absolutely noth'n.
I don't use projects, so I don't know the variable "projectname". Did you look at the xrefs after you ran the command? Did they not change? If not can you post a small sample drawing? or is it to late?
-
You can store list of paths to be searched for xref files in the registry. Projectname controls which project paths are used. Look in options under Files > Project Files Search Path to add paths.
If you have a startup routine set the projectname for each drawing, then if the saved xref path isn't found it will look in the registry path list. If the server drive changes you could search/replace the registry to fix the paths (or do it with lisp).
Used to be a command called xpath that would let you change paths for entire directories. Can't seem to get it working in my 2005.
Dan
-
I'm sure I'm late to the party, but might I suggest only fixing what needs to be fixed, when it needs to be fixed and not try fixing everything at once. I went through that once. The one saving grace we had, was that the guy before me was smart enough to not list any xref's through path names, but used the complete path instead. Smart guy. Everyone else had problems. We got a good laugh out of it.
-
scuse me for this simple answer...
referencemanager and change the paths of the xref's in there?
-
Just a thought on this, do you have permissions to map your own additional network drives? If so, you can map to the data using the old drive designations as long as they are not assigned to a different location on your system and even if they are you can disconnect them temporarily. You will have two drives mapped to the same location, but it should work in a pinch.
-
To my understanding, they decided to change it when they updated the server because there are too many engineers and others having issues with USB keys and external drives and other things with their laptops that conflict with a servers drive letters being D: E: & F:. So they decided to move the drive letters to the end of the alphabet so there would be no conflicts with external connections and automapping.
I've run into this problem. It's VERY annoying, and it was very hard to figure out the first time it happened. Unfortunately, it's part of Windows (Windows fails to notice the network drive when mounting new removable disk drives, which is what most of these devices look like to the system), so yeah, the only way to deal with it is to mount your network drives on letters further down the alphabet. We use N: (for network) without a problem, but X: seems to be pretty common.
-
All would be okie-dookie if the ``projectname'' variable was set. (please look into it.)
That's not really intended as a fix for this problem.
We actually use the PROJECTNAME variable for some of our larger projects (we use it to link related Land Desktop projects together), and it's a solution that causes problems in itself. It is stored in the registry of each machine, which makes it hard to administer. I think the only way to do it in any coherent manner is via Windows Group Policies, but I haven't had the time to experiment with those yet. (I'm not really an IT person, I just get drafted into the position whenever something needs to be done.) The whole PROJECTNAME thing seems like a potentially-good idea Autodesk had at one point, then they completely dropped it after it's initial (limited) implementation.
I'd second the reference manager (which WAS designed for this problem), or maybe Tim's Lisp or the things in the link Mark mentioned.