File Loads?

[Anonymous]

Can anyone point me to some sites, or tell me where I can get the information on what the load sequences are for standard AutoCAD files? Such as, at what point does the PGP file load? Before or after LSP files? Also, a something I forgot, can a second PGP file be loaded? Some users have different command aliases they want to use, but instead of them editing the local PGP file, which could be deleted or otherwise, I watned to just create a separate PGP (i.e. username.PGP) that I could autoload w/ the office customization LISP file. I'm looking to eliminate as much 'local' customization' as possible, by setting up so the users have personalized PGP/MNU/LSP that is on the network, so it isn't lost when a machine crashes or I upgrade the software. Thanks.

[Anonymous]

There is no such thing as a user.pgp. Only one Acad.pgp. If the users want custom shortcut keys, and you don't want them mucking in the Acad.pgp, you must use lisp to do it. As an alternative, the user can place a copy of the Acad.pgp in a folder that is higher in the search path, so it is found and executed first. BTW, pgp load first, AFAIK. -- R. Robert Bell "Jason Wilder" wrote in message news:4050cf57_1@newsprd01... Can anyone point me to some sites, or tell me where I can get the information on what the load sequences are for standard AutoCAD files? Such as, at what point does the PGP file load? Before or after LSP files? Also, a something I forgot, can a second PGP file be loaded? Some users have different command aliases they want to use, but instead of them editing the local PGP file, which could be deleted or otherwise, I watned to just create a separate PGP (i.e. username.PGP) that I could autoload w/ the office customization LISP file. I'm looking to eliminate as much 'local' customization' as possible, by setting up so the users have personalized PGP/MNU/LSP that is on the network, so it isn't lost when a machine crashes or I upgrade the software. Thanks.

[Anonymous]

http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=2875421&linkID =2475323 is a partial list that doesn't include the pgp. Several releases back, I thought I'd seen a better discussion, but I can't find it. The pgp loads before lisps, as evidenced by the fact that when command aliases conflict, the lisp version wins. The way I handle this is to treat acad.pgp as a "user" file. Everyone initially gets an Acad-standard one, and they can muck it up all they want. All of our comapny-standard command abbreviations are done with lisp, even if it's as simple as a ZE for zoom extents. This means that in cases of conflict, the company version wins, unless the user is knowledgeable enough to do his customizations in his own lisp. (Which I allow, by the way. I leave a few loopholes in the setup for the smarter ones.) So in all their mucking about, most users will need to find different aliases that don't conflict with standards. What I'm aiming at is to retain a "core" of common functionality, while allowing as much personalization as I can without total chaos.

[Anonymous]

Thanks both. "Tom Smith" wrote in message news:4050d7fb$1_3@newsprd01... > http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=2875421&linkID > =2475323 is a partial list that doesn't include the pgp. Several releases > back, I thought I'd seen a better discussion, but I can't find it. > > The pgp loads before lisps, as evidenced by the fact that when command > aliases conflict, the lisp version wins. > > The way I handle this is to treat acad.pgp as a "user" file. Everyone > initially gets an Acad-standard one, and they can muck it up all they want. > All of our comapny-standard command abbreviations are done with lisp, even > if it's as simple as a ZE for zoom extents. > > This means that in cases of conflict, the company version wins, unless the > user is knowledgeable enough to do his customizations in his own lisp. > (Which I allow, by the way. I leave a few loopholes in the setup for the > smarter ones.) So in all their mucking about, most users will need to find > different aliases that don't conflict with standards. > > What I'm aiming at is to retain a "core" of common functionality, while > allowing as much personalization as I can without total chaos. > > > >