Notes on the philosophy of CUI

[Anonymous]

Most of us used to use Acad.mns as the root of our menu structure, and then
MenuLoad (partial) the rest of our menus. So this was the structure:

-Acad.mns
--Express.mns
--Custom.mns
--Office.mns

However, the CUI has flipped our tidy lives. And the tendency is to try to
shoehorn the CUI into how we've always done things. I propose an
alternative, taking advantage of the Enterprise CUI in the process.

It is no longer necessary to make Acad.cui the root of structure. Think
about it; we did that before so that we could always insure that at least
Acad's menu structure was there. But CUI does some undesired things if you
continue this approach. More will be said on that later. Instead, I
recommend making Custom.cui the main .cui file, and your Office.cui the
Enterprise .cui file.

-Custom.cui (Main)
-Office.cui (Enterprise)
--Acad
--Express

Why?

> Well, the Custom.cui can be modified by the user to their heart's content
> in most shops. So that's a good starting place. As CAD Managers we don't
> want the users mucking with the Acad.cui, but if you leave it as the main
> .cui file, it is going to get mucked up.

> With the Custom.cui as the main .cui file, the users can make their own
> workspaces, and stand a reasonable chance that their customizations make
> the next round of hardware/software upgrades. Far easier to backup/migrate
> the user's Custom.cui, IMHO, than worrying about a mucked up Acad.cui
> file.

> Making the Office.cui the Enterprise .cui file is an obvious choice. It
> will be read-only inside AutoCAD to the users, and any workspaces defined
> in the Office.cui are available to the user.

> If you need to run a test environment, say, a "vanilla" AutoCAD profile,
> and your normal profile, you are actually forced (!) not to use Acad.cui
> as you main .cui file. The reason for this is that you need the Acad.cui
> to be the main .cui file for the vanilla profile, but if you leave the
> Acad.cui as the main .cui file in your normal profile, changes you make to
> the CUI will be evident in the vanilla profile. The largest visible effect
> is that your Custom/Office.mnl files will execute in the vanilla profile,
> since the Custom/Office.cui files are MenuLoaded in the main Acad.cui
> file. This will "pollute" the Visual LISP environment in your nominally
> vanilla profile.

> And speaking of profiles, as a CAD Manager you can setup another profile
> that makes the Office.cui the main .cui file so that you, the CAD Manager,
> can edit the file!

I hope that this post helps you in your efforts with the CUI.


--
R. Robert Bell

[Anonymous]

You're welcome Sage. I haven't found any way to add or remove Button Groups
in an existing cui file. As installed, custom has none and acad has all
four Button Groups (click, shift-click, etc.). So you can start with a copy
of one of those two. You can also start from an mns file with only the
Button Groups you want. Opening the following mns in cui...

***MENUGROUP=Enterprise

***AUX1
^C

would result in just the Click Button Group being present with Button 2
defined and ^C assigned as the macro. I found that the cui ignores empty
Button Groups from an mns, so I just threw ^C in there to get the Button
Group to show up. Similarly, if AUX2, 3, and/or 4 are in the mns, their
respective Button Groups will show up in the cui.

James


"Sage Cowsert" wrote in message
news:4844441@discussion.autodesk.com...
Thanks James I appreciate the help.

So I set the cui that I want to add the button assignments as main. I don't
see the "Click" nor other mouse button combinations. How can I add those to
my main cui? I see the "Click" and other button combo's on the transfer tab
of both new and in the ACAD.CUI just not my existing new mns created cui.
Nor can I transfer them. On the bottom it says "This node cannot be
transferred" Well "g" ain't that helpful. 😉

Thanks again James

[Anonymous]

Hey Steve,

Yes it has been a long time. I hope every thing is going well for you and
your family ;-). It was funny, I was thinking about when we met at AU
(NAAUG) that first time. That was a fun time! I bet your daughter is very
grown up now ;-)... I know my daughter turned 18 back in February! They
grow up so FAST! Of course I'll NEVER forget her 18th birthday, the day I
fell and broke my hip ;-(.

Migration has been in the product for a couple releases now and we do allow
you to turn it off. Actually you have multiple options.
- Don't install it. You can find it as part of Custom and you can remove it
that way.
- When the Migration dialog comes up you can uncheck what you don't want to
migrate.
- You can cancle out of the dialog box and run it later or never run it.

See more comments below.

Thanks.

Bud



wrote in message news:4843969@discussion.autodesk.com...
Hi Bud! Long time no write! Still grinning? 🙂

I know the migration thing is the touted main reason for the change to CUI,
but it's making me very nervous. I think the main thing I would require of
2007's CUI update feature is an off switch. I think it would be almost
impossible to write a migration tool that will work completely correctly in
all circumstances, as you have discovered with your automatic migration from
MNU to CUI. Given the possible range of scenarios, it's hard to see how you
could write something foolproof. Here are some of the complications:

BUD: That is exactly why we did the work. As long as you use the CUI editor
to create your customization we will know what it is. But if you do it
manually in an XML editor we may have issues. And you can choose not to do
it at all. Actually you could take it into the Transfer tab and just take
what you want to your new menu.

Multiple users, some with admin rights, some without. Multiple profiles per
user. Multiple workspaces per user. CAD Managers and users that want this
handled automatically, others that want intelligent control and way want the
option disabled for some users. Multiple menu files, some shared between
users, some personal to users, some Main, some Enterprise, some partial
under Main, some partial under Enterprise, some stored locally, some stored
on the network, some stored where the user has write permission, some where
the user does not, some stored in global locations, some stored in
user-specific locations, some menus that will still need to be used by 2006
and stored in the same location, some that will be stored in 2007-specific
locations to be determined by the CAD manager, some toolbar buttons that use
Autodesk dlls for bitmaps, some that use my dlls, some that use my bmps,
some that still need to be used by 2006, menu items that answer AutoCAD
prompts with pauses or hardwired command input or in-line LISP or calls to
external LISP code, menu files that aren't in use right now but which are
loaded as required via LISP or other menu items or by profile change, menus
that come from third parties, menus that are still in mn* format... Get the
idea?

AutoCAD is a complex program and there are a lot of ways to customize it.
That is part of why I loved using it for so many years and back when I was
at NCPA we did a lot of customization! The nice thing here is that we have
been doing some of this for two releases now and it works very well. There
can be issues but there can always be issues. We also backup the default
profile so you can always go back to a clean state.

Do I trust Autodesk to make the right decisions about how to handle all of
those situations? Especially as what's "right" for me may be "wrong" for
Robert? Absolutely not!

BUD: That's why we allow you to turn it off or cancel out ;-)...

I'll do my own migration using human intelligence, thank you, just as I have
for the last 20 years. It hasn't been too onerous. In fact, it has always
been considerably less onerous than the MNU to CUI migration has been.

BUD: I have used AutoCAD since version 2.6 and I remember the early days of
migrating my customization. It was very error prone. Mostly because I was
still learning. But I also learned early on to move all my customization out
side of the install location so that I had full control of it. I also
learned that I was only as good as my last backup just in case something did
go wrong. That way I could always go back to a good known working state.

What I would like, ideally, is the availability of a simple CUI file
selection migration tool. If I decide to use it, it will migrate selected
file(s) from 2006 to 2007. Even that simple solution is fraught with
problems. It would need the option of either overwriting (with
multiple-level backups, of course!) or making renamed or relocated copies of
the menus and associated files, to avoid breaking the menus in 2006. For
menus with attached partial menus, you need to let the user choose whether
to migrate the partials automatically, ignore them or prompt the user. You
would, of course, not even think about contemplating the very idea of
merging partial menus into the main menu. You will need to provide a
command-line interface and/or other API, to allow the migration to be
performed under program control.

BUD: Take a look at the transfer tab of the CUI Editor. It was based on the
Menu and Toolbar porter so that you can do your own work here if you want.

The other thing that makes me nervous about this whole idea is that it
encourages Autodesk to tinker with the behaviour of commands in
menus/scripts/LISP. "Oh, it'll be OK to move that prompt around in response
to that wishlist item, that'll be taken care of by the migration tools."


BUD: Not sure what you talking about on this one. Migration is to bring over
your customization and we let you choose what to bring over or let you do it
your self. If I were still working for NCPA, I would setup a test machine
to see how it went before I did the office and other locations that used
AutoCAD. But even here at Autodesk when I role out new software I would
test before applying it to my production environment ;-)...


That's just the stuff I thought of, right off the top of my head. I'm sure
there are many, many other complications I haven't though of. Yet. 😉 I
envy you not.

BUD:You have some good points here and thanks for posting them. They
reinforce why we want to give options to do this.

Thanks for the feedback and my best to your family.

[Anonymous]

"Bud Schroeder [Autodesk Inc.]" wrote in message
news:4844859@discussion.autodesk.com...
Hey Steve,

Yes it has been a long time. I hope every thing is going well for you and
your family ;-). It was funny, I was thinking about when we met at AU
(NAAUG) that first time. That was a fun time! I bet your daughter is very
grown up now ;-)... I know my daughter turned 18 back in February! They
grow up so FAST! Of course I'll NEVER forget her 18th birthday, the day I
fell and broke my hip ;-(.

Daughter turns 18=Man breaking hip=Ready for the walker?

BwaHaHa!!!

[Anonymous]

Gee thanks Bob . This getting OLD is not fun ;-).

Have a good weekend.

Bud

PS They tried to get me to use a walker and I refused.

"R. Robert Bell" wrote in message
news:4844948@discussion.autodesk.com...
"Bud Schroeder [Autodesk Inc.]" wrote in message
news:4844859@discussion.autodesk.com...
Hey Steve,

Yes it has been a long time. I hope every thing is going well for you and
your family ;-). It was funny, I was thinking about when we met at AU
(NAAUG) that first time. That was a fun time! I bet your daughter is very
grown up now ;-)... I know my daughter turned 18 back in February! They
grow up so FAST! Of course I'll NEVER forget her 18th birthday, the day I
fell and broke my hip ;-(.

Daughter turns 18=Man breaking hip=Ready for the walker?

BwaHaHa!!!

[Anonymous]

Watched a tutorial video on Cadigest on workspaces and the enterprise.cui which set things up as the OP described. So the more I think about it, from a consistency standpoint, the more it makes sense to keep control over the acad.cui away from the average user. Which in the past, all they could do was modify toolbars, and relied on me to adjust everything else. For the sake of keeping things organized and consistent, I'll probably go in this direction.

Still, if possible, I'd like to get a better idea of how future migrations check, replace, add, subtract, etc.

[Anonymous]

Hello,

What would you like to see in Migration? Let me give you some examples...

1. ACAD.CUI is editable by you and any Drafter.

2. ACAD.CUI is your Enterprise CUI file and lives on a server.

3. You have partial menus loaded as partial menus.

4. You have your own menu file loaded as Enterprise with your company
customization in it.

5. You have edited ACAD.CUI file and added your company customization but
it's in a read only folder.

Let me know on each one how you think Migration should work. Also if you
have other ideas on how you think it should work let me know that as well.

Thanks

Bud Schroeder
AutoCAD Test Development




wrote in message news:4845143@discussion.autodesk.com...
Watched a tutorial video on Cadigest on workspaces and the enterprise.cui
which set things up as the OP described. So the more I think about it, from
a consistency standpoint, the more it makes sense to keep control over the
acad.cui away from the average user. Which in the past, all they could do
was modify toolbars, and relied on me to adjust everything else. For the
sake of keeping things organized and consistent, I'll probably go in this
direction.

Still, if possible, I'd like to get a better idea of how future migrations
check, replace, add, subtract, etc.

[Steve_Johnson]

Bud - 18: good. Hip: bad!

Things are fine here family-wise. Louise is 6 now and Emma will be 4 in a couple of days. They are, of course, very cute and intelligent, for which I can only blame their genes. 😉

Back to the menus... OK, so you intend to add this to the list of things the user can migrate at first startup per user, like you do with profiles, etc. now. That still leaves a whole bunch of questions outstanding about what you would do under various circumstances. Maybe it would be easier to use specifics.

Let's say a user has the menu structure below. This is similar to what I intend setting up for 2006, but I've added a couple of unneccesary complications to see how you cope. 🙂

-User (Main)
-OfficeMain (Enterprise)
--Acad
--Express
--OfficeDisciplineA
:
--OfficeDisciplineZ

The User menu is in an office-created user-specific folder (call it A), OfficeMain is in a shared read-only network folder (call it B), Acad and Express are in their AutoCAD-created user-specific folders, the OfficeDiscipline menus are in a local folder that is shared by multiple users on the same PC (call it C). The user may have any or none of the OfficeDiscipline menus loaded at any one time, including the time of the 2007 installation. The user will require 2006 to continue working as before for several months following the migration.

So, *exactly* how would this situation be automatically migrated? Which files would be modified in situ? Which would be copied and renamed or placed in new folders? How will you deal with the read-only location(s)? How will you cope with partial menus that aren't even loaded in 2006, but will be needed in 2007?

You can't be expected to even know the non-loaded partials need migration, but if you intend to do a proper job of the migration, they will need processing too. Which is why you need a standalone pick-the-files CUI migrator.

Also, although this won't affect me, I'd like to know how you would cope with a modified Acad menu. Lets's say a user has added a command or two to the File menu and removed a couple, and in 2007 you add a new command to that menu. What are you going to do with your new command in the migrated menu? How will you know where to put it? The commands between which you would normally place it might not even be there.

<< Steve: The other thing that makes me nervous about this whole idea is that it encourages Autodesk to tinker with the behaviour of commands in menus/scripts/LISP. "Oh, it'll be OK to move that prompt around in response to that wishlist item, that'll be taken care of by the migration tools." >>

<< BUD: Not sure what you talking about on this one. Migration is to bring over your customization and we let you choose what to bring over or let you do it your self. >>

This is more about development philosophy than any specific migration issue, but it is very important. I'll see if I can explain better by asking a question. Why is menu migration needed at all? Is it because command names, options and command sequences may change? If so, the idea of menu migration removes one of the obstacles to the Autodesk developers messing about with commands, perhaps to add some long-requested wishlist item? Autodesk can enhance AutoCAD commands without breaking people's menus! That can only be a good thing, can't it?

NO! Because command-line compatibility is vital in many more places than just menus, places that Autodesk is highly unlikely to ever be able to automatically migrate. Anything that encourages Autodesk developers to ignore command-line compatibility makes me rather nervous. If that's the effect it is likely to have, migration between releases would become *much* more work than it has been in the past. Thus, unless you're very careful, menu migration could result in the exact opposite effect from that you're trying to acheive.

[mike.burke]

I have only discovered this thread tonight and have just spent a good hour reading through 126 posts. What a thread Bob has started here!

Bud, Some answers to your questions from my point of view.

1. Any changes (including additions and deletions) made are migrated. So if a user deletes the Plot command from the File menu, it better not be there when the menu is migrated.

2. Same thing applies. In fact that is how I have been running it since I first tested CUI's. The only thing was different is that I have renamed the filename, and left the menugroup name as ACAD.

3. Partials should be copied and automatically loaded as partials in the new version.

4. Now I assume here you are meaning that the Enterprise CUI does not have the menugroup name = ACAD, but something different? That's a toughie isn't it? How do you check to see what is different between ACAD.CUI and the custom enterprise CUI. Maybe it should be copied as well and then the transfer window is shown.

5. Tell the user that the folder needs to be set to Read/Write before it can proceed with migration.

What I would like to see with migration is an option dialog that allows you to specify a new network directory loaction for the new version of the Enterprise CUI and any other files. What I have always done here is that our "enterprise" files (MNS/LSP/PAT/etc) are stored on a network directory called something like ACAD2005. When I go to the next version I set up a new directory called ACAD2006, so I can test the new version of ACAD without affecting any of my 2005 users. So when migrating, we should be allowed to specify a new directory so existing users do not get affected with updated files.

Cheers
Mike Burke

[Anonymous]

Please see comments below.

--
R. Robert Bell


"Bud Schroeder [Autodesk Inc.]" wrote in
message news:4845181@discussion.autodesk.com...
Hello,

What would you like to see in Migration? Let me give you some examples...

1. ACAD.CUI is editable by you and any Drafter.

[RRB] This is not applicable to us, the drafter will not be able to edit
Acad.cui. This, however, is the obvious scenario in a large number of shops.
It is probably the one that Autodesk planned for.

2. ACAD.CUI is your Enterprise CUI file and lives on a server.

[RRB] Acad.cui is *not* our enterprise cui file, but rather is partially
loaded by our enterprise .cui file. Acad.cui will live on the server so that
edits to it will be global for all.

3. You have partial menus loaded as partial menus.

[RRB] Yes, this will happen. In fact, it can happen both to the main and
enterprise cui files. Partially loaded menus will include both Acad and
AcETMain cui files at the enterprise level. Therefore migration will need to
look into the partial menus to see if those cui files are located there.
Users might have partial cui files loaded under the Custom.cui file.
(Retorical question, can you have partial menus loaded as anything *other*
than partial menus? )

4. You have your own menu file loaded as Enterprise with your company
customization in it.

[RRB] This is how we are set up. Migration should escentially leave this cui
alone. I see migration as looking in all known cui files for references to
Acad or Express menu group items (commands, in cui parlance) to migrate, but
the CAD Manager needs to excerise control over what happens to this file.

5. You have edited ACAD.CUI file and added your company customization but
it's in a read only folder.

[RRB] Not exactly applicable. The Acad.cui might have some edits to it, but
will not hold the company customization. A read-only folder from the users
standpoint would be ideal, to prevent their mucking with the file. Only the
CAD Manager would run migration on the enterprise files. By the time the
users see the upgrade, the only thing they would need (or be permitted) to
migrate would be Custom.cui and any partial .cui files loaded into Custom.

[Anonymous]

This all makes good sense to me here.

1. Both Mike and Robert say as I expect and currently have set up this way.

2. Migrate structure of setup. I would want to start acad.cui from way it ships, to give new stuff a chance.

3. As said. But I see little need for additional cui's beyond the three already mentioned. (Keep it simple).

4. Acad.cui has reigning control over right click menus, so customizations still need to be done to it, not sure it matters which one is partial to which. But I agree with what needs to be done when migrating. ( Leaning more towards setting up this way though.)

5. No opinion here, sounds good.

I thought that the server install method made it possible to specify pathing migrations. Didn't get a chance to look at it since the IT dept. made the installations and wouldn't let me check it out.

Message was edited by: tlindell Message was edited by: tlindell

[Anonymous]

Arrgg. What I'm trying to say:

2. Only the CAD manager needs to migrate acad.cui. and all other custom menus should only be copied over in migration.

Hopefully someone can see what I'm trying to explain.

[Anonymous]

I wanted to post my conclusions up to this point. I mentioned I would revise my "James Rules" as I figured them out....
I spoke to Autodesk on some of this stuff so hopefully it is correct:

1) The order that you see thing in the CUI editor is what resolves any duplicate items.
For example, F11 can be assigned to multiple items. The item that has it first wins.
It sounds like the mouse buttons does not necessarily follow this, but this is what Autodesk said.

2) The only thing that does not work in a partial menu is the workspaces, all other items should function including
keyboard shortcuts. This is a major divergence from the old situation where accellerators had to be in the "base" menu.
Do not overlook this, it frees things up in 2006.

3) Note that commands are no longer "individual" per each toolbar button or pulldown menu item. The CUI editor now has
a master list of "commands" that get assigned to a toolbar or pulldown item. This sets the tone for the CUI editor in
that you should now naturally expect a command to have to be present in the command list before you can make a pulldown
item or button. Also expect to drag and drop that command into a menu structure. Once you get this, the CUI editor is
not too bad, it even simplifies some things.

So this leads me to these conclusions (for my office situation):

1) The main CUI has to be the custom.cui since I want users to be able to create workspaces for themselves. This one
fact nails this down.

2) The enterprise CUI makes itself and its partial loaded menus read only.
I do not care about this since my startup sets the office standard stuff back to how I want it. So read-only is
irrelevent to me.

3) The enterprise CUI is the only place to store workspaces besides the main CUI. It is the place where I will provide
standard workspaces.

4) I have different flavors of Acad going so I do not want menus loaded under the enterprise CUI. It removes
flexibility from my setup. I want a user to be able to unload CUI's such as the Land.cui or Civildesign.cui at will

So here is how my final setup will go:

Custom.cui (main)
-Acad.cui
-Express.cui
-.cui
Std Workspaces.cui (enterprise)

The moral of the story here is that the only thing useful I have found for the enterprise CUI is its ability to provide
workspaces. As long as I handle keeping the "standard" stuff unmodified via login script, thats all I use it for.
I am basically running things exactly like in A2002 but with a workspace menu added in.

I thought about partial loading some menus under the enterprise menu, but that assumes too much. I might change this if
users get really confused by the ability to modify all menus. They can do that now and its not a problem, they know to
keep stuff in their personal menu.

The last thing I am tackling is what is going on when you start up a session.
It used to be that a given profile would look the same as you left it. Now it seems to make things how the last session
was, even if it was a different profile. For me, its the Land and Civildesign menus that keep loading in my "LDT LE
(land enabled)" profiles.
Not sure what the new rules are that describe what happens when you run a session with one profile, then close it and
starta a session with a new profile. Are they supposed to be the same as before (in 2005 and below)
thx







James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

James,

I think I have found the secret to that is to use a different custom?.cui
for each profile. Then you can have Land, etc. loaded in some profiles and
not in others.
--

Ken Krupa
Krupa CADD Solutions
www.krupacadd.com
Home of KCS Productivity Pack for ADT


"James Maeding" wrote in message
news:4846287@discussion.autodesk.com...

The last thing I am tackling is what is going on when you start up a
session.
It used to be that a given profile would look the same as you left it. Now
it seems to make things how the last session
was, even if it was a different profile. For me, its the Land and
Civildesign menus that keep loading in my "LDT LE
(land enabled)" profiles.
Not sure what the new rules are that describe what happens when you run a
session with one profile, then close it and
starta a session with a new profile. Are they supposed to be the same as
before (in 2005 and below)
thx

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

I think I just figured out why my startup is not behaving for different profiles.

One very important thing is that in the new CUI system, the main and enterprise CUI's "remember" what partials were
loaded. Therefore, if my custom.cui is the main cui, it will load in whatever partials were there before.

To me, this seems like a very bad thing. The fact is I want my custom.cui to be the main cui in all versions of acad.
I do not want it pulling in the same partials to each session type though. So I am stuck, I have to change my strategy
on what loads the menus specific to each session type.

The way I will handle this is to have different enterprise CUI's for each session type.
I have a strong feeling this is the weak link of the new CUI system.
They removed the freedom of the old system because now you essentially have two parents and their kids.
You used to have one "base" parent and "non-base" parents.

Dealing with this will involve some undesirable compromises.
thx

James Maeding


James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

I read you post right after posting my 2nd post...

Well, the chioce is to either have multiple main cui's or mult. enterprise cui's.
If you ask me, it is really confusing to have several custom cui's.

I will see if the enterprise approach works...I have not worked through the implications of this though...

Ken Krupa
|>James,
|>
|>I think I have found the secret to that is to use a different custom?.cui
|>for each profile. Then you can have Land, etc. loaded in some profiles and
|>not in others.

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

your rhetorical statement about partials NOT being associated with the main or enterprise CUI is the one big oversight I
think Autodesk made.

Its like taking away the "overlay" option for xref attachment type and only allowing us to xref in two files!
Think about that analogy for a while, it has major impacts to how we run things.

For me it means I cannot use the same combination of main and enterprise cuis for all the different types of sessions I
run (LDT, LDT LE, Map...). I really would prefer a way to add menus beside having to partial load them under the main
or enterprise CUI.
thx

R. Robert Bell
|>Please see comments below.

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Steve_Johnson]

Bud? You there? 🙂

[Anonymous]

Hi Robert

On all users machines, I have left the acad.cui as the main customization file. From experience I have found that no matter how much you try to teach someone to make their own menus, they still customize the acad menu.

So, from the get go, we backed up the acad.cui file in case we need to reload it to a user's machine.

So, all users are mapped to the acad.cui file as main and the company cui as enterprise.

Myself, I have 1 profile which is the same as the users, I have a profile with the company.cui file as main and "acad".cui as enterprise. That allows me to update the company cui file and still have all of ACAD menus available.

Also, when you have a cui file as enterprise in your profile, you can make its workspace current as well as the main cui workspaces.

Mark

[Anonymous]

Hi Mark,

FWIW, they probably customized the acad menu because that was easiest. If
they weren't carefully making a point to only edit their menus, then they
were editing acad since it was the base (default) menu.

With the structure Robert has proposed, this scenario is reversed. Now they
are editing their own menus by default, and would have to know what they are
doing AND go out of their way to edit acad stuff.
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO


wrote in message news:4850774@discussion.autodesk.com...
Hi Robert

On all users machines, I have left the acad.cui as the main customization
file. From experience I have found that no matter how much you try to teach
someone to make their own menus, they still customize the acad menu.

So, from the get go, we backed up the acad.cui file in case we need to
reload it to a user's machine.

So, all users are mapped to the acad.cui file as main and the company cui as
enterprise.

Myself, I have 1 profile which is the same as the users, I have a profile
with the company.cui file as main and "acad".cui as enterprise. That allows
me to update the company cui file and still have all of ACAD menus
available.

Also, when you have a cui file as enterprise in your profile, you can make
its workspace current as well as the main cui workspaces.

Mark

[Anonymous]

good point.
The easiest way to deal with users touching the "standard" menus is copy them new each login.
Then users learn real fast what works and doesnt.

James Allen
|>Hi Mark,
|>
|>FWIW, they probably customized the acad menu because that was easiest. If
|>they weren't carefully making a point to only edit their menus, then they
|>were editing acad since it was the base (default) menu.
|>
|>With the structure Robert has proposed, this scenario is reversed. Now they
|>are editing their own menus by default, and would have to know what they are
|>doing AND go out of their way to edit acad stuff.

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com