Erasing a Dwg File After Closing It

[Bill Tillman]

I've tried this 9 ways to Sunday. With LISP, with .NET inside of AutoCAD and with .COM out side of AutoCAD. I can make it work with .COM and watch as it flawlessly works on AutoCAD 2010.

 

The problem comes that the users in the office are split with AutoCAD 2009 and AutoCAD 2005. I can create the success with 2009 but 2005 is a whack out. The references needed and the Libraries just don't seem to be available. I have another 2013 machine at this office which I can make it partially work because the docs show the commands needed to do it, but the new revisions to the .NET format are not the same. So I tried it with a batch file and had limited success.

 

I think the only way to get this done is to use VLISP. In a nutshell, there is a folder which had very restricted rights. The users can copy only, no save, no saveas. As long as the drawing we want to move there does not exist I can copy the file there. This kind of works:

 

(defun c:test (/ _originalfilename _tempfilename)
 (vl-load-com)
 (setq _originalfilename (strcat (getvar "dwgprefix") (getvar "dwgname"))
_tempfilename (strcat "C:/TEMP/" (getvar "dwgname"))
_expert (getvar "EXPERT"))

 (setvar "EXPERT" 5)
 (command "._SAVEAS" "2004" _tempfilename)
 (command "._SAVEAS" "2004" _originalfilename)
 (setvar "EXPERT" _expert)

 (vl-file-copy _tempfilename (strcat "//novell_path/" (getvar "dwgname")))
 (vl-file-delete _tempfilename)
 (vl-file-delete _originalfilename)
 (command "._CLOSE")
 
 (princ); exit quietly
); end function

 

The goal is to save a copy of the active drawing in this restricted folder and then close the active drawing. Typical house cleaning will be needed to erase the copy of the original active drawing. This works but since I have to close the active drawing LISP no longer runs if I move the CLOSE command above the last vl-file-delete line. If I move it where it's shown now, the drawing is apparently still open and the delete command has no affect on it.

 

It's a cluster+f*** I know but it's what I have been tasked with.

[BlackBox]

I'm not sure I understand why one would effectively 'archive' a drawing and delete the 'active' version, but you cannot delete the ActiveDocument while it is still open in the Editor.

 

In order for code to execute after the ActiveDocument is closed, you must operate from a separate Namespace, which is where .NET wins over Visual LISP, IMO.

 

It's time for a mandatory upgrade for those legacy users too, IMO.

[Bill Tillman]

I work for a bunch of people who hate to hear something is impossible. So I do my best and almost always come up with something but this one has me stumped. How to you close a file and then erase it after you've closed the file?

 

So I can just hear them tomorrow:

 

ME: I can't do it with the existing setup. It's impossible.

 

THE BOSS: Don't say that word in here. We refuse to accept it. What do you need to make it happen?

 

ME: We need to spend about $40K to upgrade all these legacy systems so we have a uniform platform to work on.

 

THE BOSS: No way. That's impossible.

[BlackBox]

I hardly think this to be impossible... I do not have the API Documentation for each version, but it sounds to me like a Class Library (.DLL) for newer version(s), and a Console Application for legacy version(s) in concert could do what you need. Using System.IO you can code the applicable Method(s).

 

Perhaps the legacy versions can call a Windows Command line script which invokes the console application gimmick. Newer versions can simply use the internal API

 

HTH

[BlackBox]

Another thought is to use the SaveAs Method on the ActiveDocument Object to create your Temporary file, Copy to 'archive', then Delete the original ActiveDocument (prior to SaveAs being invoked), then simply Close.

 

You *may* need to modify SDI System Variable... Not sure.

[irneb]

Yep, you already change the active document through the SaveAs command, then delete the previous doc. This is the trick, and also no need for SDI fiddling.

 

I'm a bit confused as to why create a temporary file, then overwrite the original, then copy the temp somewhere else, then delete the temp, then delete the original.

 

I'm assuming the copy needs to happen due to some network security issue - i.e. the saveas doesn't work on that folder. If so attempt this (a bit over the top maybe):

 

1. Remember original filepath
   
2. SaveAs 2004 to temp (make a "special" folder under temp for this file)
   
3. Delete original
   
4. Copy temp to network (perhaps shared copy due to ACad having source open already).
   
5. Close temp
   

Then as a routine to run on each dwg open / session start (acaddoc.lsp / acad.lsp). Check the contents of the special folder and delete all inside.

 

 

You can use startapp to send stuff like DELETE , or COPY/XCOPY instead of using the vl stuff (if those don't want to work in your older acads).

 

 

BTW, Are you looking at running this through a SCR on multiple DWG's? If so, have you looked at trying this with DwgTrueView instead? It can saveas to any selected version through a batch selection of DWG files. Then move all at once to the network folder - methinks this might work out quicker than scripting.

[Bill Tillman]

We haven't given up on it yet, but yesterday we did the soft roll out of it and there is this now known fact of life. Several of the short LISP routines I've written saveas "2004" then close the active drawing. And as long as it doesn't involve anything with that "restricted" folder, all goes well. The second I try to close a file after we've done anything with that "restricted" folder, AutoCAD 2009 locks up. Every user who tried it yesterday had the same thing happen. The computer stays active but AutoCAD locks up and the only way out is Task Manager and stop the application.

 

This network here is full of latency. I can't imagine any one thing doing this but add em all up and this is what we have. This simple set of commands locks up AutoCAD every time and only when we involve that "restricted" directory. I've thrown .NET COM apps at it and the 2005 users can't use it. I've thrown batch files at, batch file which create their own batch files on the fly and attempt it. Nothing has worked thus far. In the interim, we have a work around which is to leave the CLOSE command out of it and toss up an alert reminding the user that they can now close the drawing manually. Which by the way works. They click the X in the upper right corner and the drawing closes without incident. But try it with code and you get whacked.

 

When and if time permits we will revisit this.

[irneb]

I think using the command-line version of SAVE instead of SAVEAS allows for you to save the current DWG to a new location without actually setting the new location as current. It's more like a SaveCopy. Or you could use WBLOCK with * for "Entire Drawing". Thus you might be able to copy that DWG to the network, since it shouldn't be open after the Save/WBlock.

 

Unfortunately though both these don't have an option to choose the version of file, so you'll need to set the default version in the Options dialog. I can't remember any sysvar for this - it's probably saved somewhere in registry though. So it might be an EnvVar instead.

[BlackBox]

Several of the short LISP routines I've written saveas "2004" then close the active drawing. And as long as it doesn't involve anything with that "restricted" folder, all goes well. The second I try to close a file after we've done anything with that "restricted" folder, AutoCAD 2009 locks up. Every user who tried it yesterday had the same thing happen. The computer stays active but AutoCAD locks up and the only way out is Task Manager and stop the application.

 

Perhaps using the SAVEAS Method in lieu of the Command will yield a different result?

 

Another thought is to have a 'dropbox' location that everyone has write-access to, and employ a server monitor to react by moving the newly added file(s) to the restricted folder. This then removes the need for user(s) to interact with the restricted folder, and can automate the 'back end' all while your code can be simplified to work in all versions without issue. Just a thought.

 

We do this for .EPS files for publishing... Everything gets sent to an 'in' folder, and the server monitor employes a freeware software that converts the .EPS to .PDF for us... the resultant .PDF file(s) are automagically moved to the 'out' folder, and the original .EPS file(s) are deleted.

[irneb]

A server based one as RenderMan suggests would probably be your best bet. If you cannot (or may not) install extra services on the server, you can even do something similar on the local PC's. Either using a periodic copy or with a folder event watcher.

 

If you go with periodic one I know works very well is Karen's Replicator. It runs as a background process periodically comparing the pre-set source and destination folders copying any new files onto the destination. The only reason I mention this is because I used this thing previously as an automatic backup and was very happy with it. I'm sure there are others available as well - perhaps a google search might bring some others to fore.

 

Just one thing though ... you know that the way you guys have it setup means it's quite possible for more than one person to edit a DWG at the same time? If so only the last guy to save will get his edits onto the server, all others will lose their edits. IMO this system of server opens a lot of problems. Just be aware of that.

[irneb]

Actually this seems like the ticket if you have to work with local PCs only.

[Bill Tillman]

I think we can close this thread. I just came back from having lunch at my home office. I have a small LAN there with a 100 MB switch, Windows 7x64 desktops running AutoCAD 2012x64 and a BSD x64 file server where I store files. I prepared identical code to what I'm attempting at this office and it worked perfectly each and every time I tried it. Not 99%, not 99.9%. 100% success rate each and every time I executed the code. The temp file was saved as 2004, the file was then saved again as it's original name, the temporary file was copied to a location on the server (not local), then the temp file was erased (only the first one) and then AutoCAD closed down gracefully.

 

The IT guys here say I'm nuts, that there is nothing wrong with their network with the exception of a little more than normal latency. There is a gentleman back there in the cold room working on a stack of routers and switches. He may be doing traffic shaping of some kind, they won't say. But the code is rock solid. I've seen it work more than once. And I've seen it fail but only here on this LAN/WAN.

 

I'm now going to buy some voo-doo dolls of the IT guys and torture them over a open fire until they admit they have something going on back there which is causing this issue.

[irneb]

Yes! IT guy doesn't always mean "network specialist" ... especially on large networks and even more importantly on WAN. We've had to get some network specialists in from Cisco to get our network problems sorted (100+ people locally on 1G switches with 200 more linking to FTP/EMail/etc). We're still not perfect, but it's a lot better since the guy told our IT "gurus" that simply plugging switches together don't cut it - you have to plan it diagramatically so any link between PC and server uses as few switches as possible and keep congestion to a minimum.

 

Then our next major hurdle was to get the slow piece of M$ 2008 server (unfortunately out timekeeping software requires this piece of $HT for its Directory Service) to be used as little as possible. Returned back to the old CentOS file server - the Win-doze thing only works as domain & login now, thereafter it hands over to the Linux file/email/ftp/firewall/print/etc serverS. Our fridge contains about 7 machines, each with multi-core, multi-CPU, double 1G NICs.

 

And still we're getting lag on the network when working on large projects. Especially with Revit Central files - but worst is using PhotoShop PSD files (usually those become local C-Drive copies). Usually DWG's aren't a problem - open, save & close direct on server without hassles. Our biggest pain at the moment is actually internet connection, even with the direct fibre-optic line to our ISP we're getting extremely intermittent speeds (varies between 50kBi/s [500 kb/s] to 2MBi/s [20Mb/s]), but that may be due to everything running in-and-out of our servers (including all email & ftp for our international branches).

 

They've been "talking" about using a distributed file system for a set of projects we're in the process of starting on the other side of the planet. Setting up a new branch-office there, but most of the work will be done here at the head-office. And since the first 2 projects are basically at 20% constructed phase, they tend towards going the route we went with those - i.e. Revit with Worksets. I can just imagine how much issues this is going to cause!