pathing and profiles

[Anonymous]

tried this in another forum, with no results. Thought I'd try here.

question:
If I have 5 seats of autocad, and want each to be the exact profile, can I
just set one up the way I want, and export the profile, and then import to
the other 4 computers. I just worry that the file paths might not be right,
since xp saves paths under your user name. Wondering what everybody else
thinks.

Mike

[Anonymous]

When I setup a new workstation for our dept. I import a standard template
profile (note: this profile sets the paths "docs/settings/temp" to
"C:/temp", for the most part and sets up the network paths which is the same
on all workstations). Now when the workstation has been setup and tested
and it is ready to run I instruct the user to export there profile whenever
they make any changes so the they can import there profile if needed. Does
not always work because they do not export the profile when they make
changes at which point I instruct them again to make there profile changes
and export and then walk away.

ACote

"mkh" wrote in message
news:5542546@discussion.autodesk.com...
tried this in another forum, with no results. Thought I'd try here.

question:
If I have 5 seats of autocad, and want each to be the exact profile, can I
just set one up the way I want, and export the profile, and then import to
the other 4 computers. I just worry that the file paths might not be right,
since xp saves paths under your user name. Wondering what everybody else
thinks.

Mike

[Anonymous]

Just because XP saves everything under the user name path, doesnt mean you
can't change those paths in the profile. When 2k6 first came out I created
a profile that pathed everything directly to the C:\program files\Autodesk
Arch... folder. It worked on stand-alones, networked together. I'm not
sure how it would work with roaming profiles though.

--
Mike Edmiston

[Anonymous]

I really don't want roaming profiles, I just want the inital setup to be the
same. Thanks for the reply.

MKH


"Mike Edmiston" wrote in message
news:5542785@discussion.autodesk.com...
Just because XP saves everything under the user name path, doesnt mean you
can't change those paths in the profile. When 2k6 first came out I created
a profile that pathed everything directly to the C:\program files\Autodesk
Arch... folder. It worked on stand-alones, networked together. I'm not
sure how it would work with roaming profiles though.

--
Mike Edmiston

[Anonymous]

I agree Mike, especially when, by default, some of the folder locations are
in hidden folders, go figure.

ACote

"Mike Edmiston" wrote in message
news:5542785@discussion.autodesk.com...
Just because XP saves everything under the user name path, doesnt mean you
can't change those paths in the profile. When 2k6 first came out I created
a profile that pathed everything directly to the C:\program files\Autodesk
Arch... folder. It worked on stand-alones, networked together. I'm not
sure how it would work with roaming profiles though.

--
Mike Edmiston

[cprettyman]

When you export a profile, a lot of those directories that are buried in your windows profile are written to the arg file using variables, like:

PlotToFilePath"="%UserProfileFolder%\\My Documents

which will then be resolved to a particular path when the arg is imported. An arg is just a text file, you can open it in notepad, or any other text editor and read it. It's not a bad idea to check the path exported in any of the settings you chose to customize to make sure that they did, in fact, get exported using a variable when appropriate. You can change them manually if you need to.

[Anonymous]

It has always been generally considered "best practice" to leave everything supplied by Acad strictly alone, and put all your customizations somewhere other than the OOTB install folders. Strictly segregating your stuff from what comes OOTB makes it a lot easier to upgrade, apply patches, or reinstall without messing up the customizations.

There's no reason the custom folders have to be buried where Acad puts things. Your stuff can be anywhere you want it to be. Just add your folders to the search path, and put them earlier than the standard stuff in the event of conflicting filenames.

FYI, as Charles says, when you import a profile, Acad does substitute the appropriate login name iin the docs and settings path. So you can bury stuff down in there if you want to, but I don't know anyone who prefers this. If you insist on hiding your customizations there, I would at least give them subfolders of their own for the reasons above.

[Anonymous]

On Thu, 5 Apr 2007 13:18:51 +0000, mkh
wrote:

>tried this in another forum, with no results. Thought I'd try here.
>
>question:
>If I have 5 seats of autocad, and want each to be the exact profile, can I
>just set one up the way I want, and export the profile, and then import to
>the other 4 computers. I just worry that the file paths might not be right,
>since xp saves paths under your user name. Wondering what everybody else
>thinks.

Yes, you can do this.

If you load the exported "template" Profile (the .arg file) into a Text editor,
you will see references to %RoamableRootFolder%, which is specified elsewhere in
the registry, usually as "C:\Documents and Settings\\Application
Data\Autodesk\\\enu."

Other Profile path values may be logical or explicit but are automatically
derived from the Windows environment (e.g., %USERNAME%, %TEMP%, etc.) which are
machine-agnostic.

The trick is to understand where these settings are, which requires some careful
study if the .ARG file.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

On Thu, 5 Apr 2007 16:29:45 +0000, Tom Smith <> wrote:

>There's no reason the custom folders have to be buried where Acad puts things. Your stuff can be anywhere you want it to be. Just add your folders to the search path, and put them earlier than the standard stuff in the event of conflicting filenames.

This is not always true - some things are hardcoded inside of AutoCAD to place
user-centric data in particular locations. Tool Palettes, for example.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

Huh?? Tool Palette locations can be change in Options - I have ours located
on the network.

John

"Matt Stachoni" wrote in message
news:5543132@discussion.autodesk.com...
On Thu, 5 Apr 2007 16:29:45 +0000,

This is not always true - some things are hardcoded inside of AutoCAD to
place
user-centric data in particular locations. Tool Palettes, for example.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

On Thu, 5 Apr 2007 18:10:44 +0000, John Schmidt
wrote:

>Huh?? Tool Palette locations can be change in Options - I have ours located
>on the network.

What about where the various AWS files are located?

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

You may be correct about the .aws file. That said, I only have one on my
computer, from Civil3D 2007. In R2005 Tool Palettes definitely couldn't care
less where they're located, and while I haven't customized, (added new
ones), in R2007 yet, (waiting for R2008), it still looks like they can be
located wherever you want.

John

"Matt Stachoni" wrote in message
news:5543286@discussion.autodesk.com...
On Thu, 5 Apr 2007 18:10:44 +0000, John Schmidt

wrote:

>Huh?? Tool Palette locations can be change in Options - I have ours located
>on the network.

What about where the various AWS files are located?

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

>What about where the various AWS files are located?

I haven't had any reason to care where they're located, though they appear to follow the same rules you describe below -- the point being that the user's names will be automatically substituted in the path, so the OP's original point of concern is moot.

[Anonymous]

On Thu, 5 Apr 2007 21:07:24 +0000, Tom Smith <> wrote:

>>What about where the various AWS files are located?
>
>I haven't had any reason to care where they're located, though they appear to follow the same rules you describe below -- the point being that the user's names will be automatically substituted in the path, so the OP's original point of concern is moot.

Well, you're lucky, because they dictate your tool palette's groups
configuration, which has a tendency to get hosed from time to time. I've found
that backing up the AWS files from time to time has really saved time when
things go awry.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

Haven't had any reason to use tool palettes at all, so thanks for the information.

Going back to the topic, tool palettes were nowhere near ready for prime time in 2004. Even after the patch, I couldn't find anything that they were capable of doing that we weren't already doing simpler, more easily, more maintainably, and flat-out better, with pre-2004 dinosaur menu methods.

In the context of the OP, which is the same transition I'm making, it sorta sounded like tool palettes might really have become a worthwhile customization direction by 2007. You're telling me that however cool they are, routinely they get hosed and screw up. and it will take an extra maintenance effort to keep them working at all. So fine, that's useful information which I'll factor into the decision of whether that's a direction we want to go in company CAD customizations.

A reasonable person might decide to stay "lucky," if the choice amounts to taking on a new problem versus luckily deciding to not do so.

[Anonymous]

On Fri, 6 Apr 2007 03:38:53 +0000, Tom Smith <> wrote:

>In the context of the OP, which is the same transition I'm making, it sorta sounded like tool palettes might really have become a worthwhile customization direction by 2007. You're telling me that however cool they are, routinely they get hosed and screw up. and it will take an extra maintenance effort to keep them working at all. So fine, that's useful information which I'll factor into the decision of whether that's a direction we want to go in company CAD customizations.

You will find opinions all over the place, and I was highly skeptical myself
because they were so new and unexplored. But generally, I found that Tool
Palettes are well worth the time and effort it takes to implement them. In ADT
(er, I mean ACA) they integrate with Tool Catalogs via drag and drop, and
corporate standard palettes can be set to be refreshable from a central server
repository.

They aren't perfect (I don't know of many specific TP enhancements since 2004),
and there are a few options that would be welcome. In ADT, the ability to key a
block insertion tool to a Layer Key instead of a specific layer would be nice,
and the ability to preset an Insertion Point would be awesome.

The main problem with TPs is that they are written in XML (as are CUI files).
Those files are essentially rewritten when you exit the program. Sometimes, if
the user exits ADT un-gracefully, those files get zeroed out or corrupted, so
when you restart the program it rebuilds them from scratch - meaning you lose
your TP groups and other things. I've seen the same thing has happened with CUI
files too.

But, if you preconfigure a dummy user profile as a template, then it's resy to
copy a "good" profile.aws to the user's Profiles folder and get back on track.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

Matt, thanks for the thoughtful reply and unvarnished opinions.

As far as TP history, I think the downloadable "extensions" added during 2004 allowed for command type input and a bit more control, and presumably became part of the core in 2005. The big news for me was the addition of TP groups, which I think came with 2007. But judging by recent posts, people are still struggling with updating corporate groups over a network. I think that if I began to implement TP's, they would be entirely locked down as corporate-standard, unless and until somebody found a need for personalizing them. I don't really foresee that.

To digress a bit, my lack of interest inTP's as a replacements for existing methods of doing the same things is mainly founded on interface philosphy. We have a large number of blocks in quite a few categories, and they just don't fit nicely in the tabbed TP format. Groups might add one more dimension and finally make them workable.

Example: we use quasi-standard assemblies for most of our residential sections and details. The user is to begin with the standard and then adapt it minimally for the specific project. Let's say we have exterior wall sections for 2x4 vs 2x6 construction, 1-story vs 2-story, brick veneer vs cultured stone vs siding vs stucco, and crawlspace vs slab vs basement foundation. That would be 2x2x4x3=48 possibilities to choose from.

Now the last thing I want to do is slam the user with choosing from among 48 possibilities. For one thing, it's too much to take in at a glance. Compounding that is the fact that when the choice is presented in a "flat" manner, all choices must be uniquely described. So the user would see labels such as:

Exterior Wall, 2x4, 1-Story, Brick, Crawlspace
Exterior Wall, 2x6, 2-Story, Stone, Slab
etc
etc

Too hard to read and pick from. I'd much rather present the choices as a decision tree, where there are never more than a few options for each sub-decision. Of all the built-in methods, I think pulldown menus with flyout submenus are by far the easiest way to implement this. Then the user can successively pick:

Ext Walls...
_2x4...
__1-Story...
___Brick...
____Crawl

Not that I "like" pulldowns so much as an interface, but they let me present a heirarchy of choices in a logical way, which I don't think I could do otherwise (pre-2007) without the cumbersome task of creating a custom dialog. I'd be interested in TP's if they'd allow being structured more in that manner.

Note that in the flyout structure, each item label is shorter, because it doesn't have to fully describe all previous choices too. This matters to me because I think that in most cases a text label is more meaningful than an icon. In this example, if the wall sections themselves were reduced to icons, they'd be unreadable/useless, and I can't think of a way to "abstractly" iconize those 48 alternatives. IMO this is a problem with the increasingly iconized interface that Acad seems to be encouraging. I don't mind so much having a useless image displayed, if Acad doesn't let me eliminate it, but I want the text labels to be short and sweet.

Thanks again. I'm sure I'll be back for help if I start trying to implement TP's.

[Anonymous]

On Sun, 8 Apr 2007 17:08:17 +0000, Tom Smith <> wrote:

>Matt, thanks for the thoughtful reply and unvarnished opinions.
>
>As far as TP history, I think the downloadable "extensions" added during 2004 allowed for command type input and a bit more control, and presumably became part of the core in 2005. The big news for me was the addition of TP groups, which I think came with 2007. But judging by recent posts, people are still struggling with updating corporate groups over a network. I think that if I began to implement TP's, they would be entirely locked down as corporate-standard, unless and until somebody found a need for personalizing them. I don't really foresee that.

To my knowledge, Groups have been part of the core Tool Palette feature list
since day one. I know they were there in 2005 (I skipped 2004).

"Corporate" palettes (those which are linked back to a central catalog on a
server) are problematic in that the updating mechanism is way too slow and
klunky (you have to update them one at a time, as updating the entire set will
take forever and probably bomb out).

I decided to put together a core set of corporate palettes, and when updates
occur, I email everyone which palettes need to be updated. I don't update them
too often (it's often preferable to wait until the new release)

Although you can provide a script which manually copies the palettes and
associated AWS files to the local machine, outside of AutoCAD.

>To digress a bit, my lack of interest inTP's as a replacements for existing methods of doing the same things is mainly founded on interface philosphy. We have a large number of blocks in quite a few categories, and they just don't fit nicely in the tabbed TP format. Groups might add one more dimension and finally make them workable.

I grouped our block library by CSI division, which made a lot of sense. Other
stuff - details, legends, notes - is handled by old-skool pulldown menus.

>Example: we use quasi-standard assemblies for most of our residential sections and details. The user is to begin with the standard and then adapt it minimally for the specific project. Let's say we have exterior wall sections for 2x4 vs 2x6 construction, 1-story vs 2-story, brick veneer vs cultured stone vs siding vs stucco, and crawlspace vs slab vs basement foundation. That would be 2x2x4x3=48 possibilities to choose from.

>Now the last thing I want to do is slam the user with choosing from among 48 possibilities. For one thing, it's too much to take in at a glance. Compounding that is the fact that when the choice is presented in a "flat" manner, all choices must be uniquely described. So the user would see labels such as:

But once drawn, such details are done and saves your company 2x2x4x3=48 times
the effort.

I would not suggest that TPs solve every problem. We use them for block
libraries and drafting tools in ADT, because they lend themselves to that kind
of application.

For details and assemblies, we use a system of predrawn content that lives on a
server and is accessed through pulldown menus and inserted via some simple VLISP
programming. The user simply navigates a tree to get to the proper construction
detail, or selects one based on its file name.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

[Anonymous]

I see the problem I was asking about might be linked to this, I want the .aws file, from my "Company"arg file to always load first, like the other settings when someone first uses cad from that cpu. well how do I have this copy over, should I add this to my "custom" folder as well
?