Notes on the philosophy of CUI

Notes on the philosophy of CUI

Anonymous
Not applicable
7,788 Views
231 Replies
Message 1 of 232

Notes on the philosophy of CUI

Anonymous
Not applicable
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
0 Likes
7,789 Views
231 Replies
Replies (231)
Message 21 of 232

Anonymous
Not applicable
Can you explain what can be put where and work?
Here are the rules I have derived so far:

1) Toolbars and pulldown menus can be placed anywhere
2) Everything else only works when in the main cui

Should item 2 be expanded to "a combination of the main and enterprise cui"?
I am trying to picture how to deal with say, workspaces that have the same name, or other things with the same name.

You mentioned most people did not think of the structure below, but I think it did because everyone immediately wants to
let users make workspaces, and those must be in the main cui. So the idea of loading the custom.cui pops (pardon the
pun) into your head. Then it is nixed when you realize the mouse buttons and other highly standard stuff needs to be in
there too.

So this leaves you back at the beginning - unless my understanding of where mouse button and other assignments must be -
is not correct.

I'll wait on responses before my next comments, they may answer them...
thx


Structure mentioned:

|>-Custom.cui (Main)
|>-Office.cui (Enterprise)
|>--Acad
|>--Express
0 Likes
Message 22 of 232

Anonymous
Not applicable
That's exactly how I want it. In my vanilla profile I don't want Express
Tools mucking things up. I want as pristine an environment as possible for
debugging code.

--
R. Robert Bell


wrote in message news:4838625@discussion.autodesk.com...
That's very similar to an approach I was considering, where the custom menu
file is set as the "main" one. (You actually replied to another post of
mine) So it's good to hear someone else come to the same basic conclusion.
But, you brought up something that now raises a question for me. Under your
proposed "main" and "enterprise" configuration, Express is not a partial
menu of Acad - they are both partials of your Office menu. So, if you were
to now want to launch a vanilla profile, Express would not load. Am I
missing something?

Shawn
0 Likes
Message 23 of 232

Anonymous
Not applicable
Workspaces can also be defined and used from the enterprise .cui file.

Your statement #2 is far too global.

For instance, all the context-sensitive menus in Acad.cui are available to
me when I have my office .cui as the enterprise .cui file (my office .cui
has Acad.cui as a partial menu). Note that when I'm editing my office .cui
(as the main .cui file in my edit profile) that the context-sensitive menus
*are not* available, but will be as soon as I switch to the enterprise
profile. (IMHO, this is a CUI interface issue.)


--
R. Robert Bell


"James Maeding" wrote in message
news:4838951@discussion.autodesk.com...
Can you explain what can be put where and work?
Here are the rules I have derived so far:

1) Toolbars and pulldown menus can be placed anywhere
2) Everything else only works when in the main cui

Should item 2 be expanded to "a combination of the main and enterprise cui"?
I am trying to picture how to deal with say, workspaces that have the same
name, or other things with the same name.

You mentioned most people did not think of the structure below, but I think
it did because everyone immediately wants to
let users make workspaces, and those must be in the main cui. So the idea
of loading the custom.cui pops (pardon the
pun) into your head. Then it is nixed when you realize the mouse buttons
and other highly standard stuff needs to be in
there too.

So this leaves you back at the beginning - unless my understanding of where
mouse button and other assignments must be -
is not correct.

I'll wait on responses before my next comments, they may answer them...
thx


Structure mentioned:

|>-Custom.cui (Main)
|>-Office.cui (Enterprise)
|>--Acad
|>--Express
0 Likes
Message 24 of 232

Anonymous
Not applicable
If I partially load the local Acad.cui into my enterprise menu.
C:\\Document and Settings\\.... \\...\\acad.cui
I am assuming that when someone else load the same
enterprise file that AutoCAD will (automatically load and) use
the acad.cui file that is found on that system, ignoring the path
from which I loaded the acad.cui

Or are you suggesting that the acad.cui is also in a network
location, rather than the local machine?

--
Autodesk Discussion Group Facilitator



"R. Robert Bell" wrote in message
news:4838919@discussion.autodesk.com...
???

The main .cui file can also have partial menus menuloaded. And those would
not be read-only.

--
R. Robert Bell
0 Likes
Message 25 of 232

Anonymous
Not applicable
It finds Acad.cui on the local user's profile just fine and dandy. (No, it's
not up on the network.)

--
R. Robert Bell


"Jason Piercey" wrote in message
news:4838963@discussion.autodesk.com...
If I partially load the local Acad.cui into my enterprise menu.
C:\\Document and Settings\\.... \\...\\acad.cui
I am assuming that when someone else load the same
enterprise file that AutoCAD will (automatically load and) use
the acad.cui file that is found on that system, ignoring the path
from which I loaded the acad.cui

Or are you suggesting that the acad.cui is also in a network
location, rather than the local machine?
0 Likes
Message 26 of 232

Anonymous
Not applicable
ok, so how about this:
Custom.cui - (main) for custom user toolbars, pulldowns, workspaces
Office.cui - (enterprise) for standard workspaces and everything else...mouse buttons, keyboard shortcuts...
Acad.cui - (partial) for acad toolbars and pulldowns

to Do this, you would copy the acad.cui to the office cui, strip out the acad toolbars, pulldowns, workspaces and add
yours.

Then go into the acad cui and strip out mouse buttons, shortcut menus, keyboard shortcuts and so on.

Its like we need to undertstand where things can go and still work, and what the precedence is for duplicate names of
things like workspaces for items that can be in several places and "work". Then we can answer our own questions
according to our needs.

This is good timing as I am putting together our 2006 transition files right now...

thanks


R. Robert Bell
|>Workspaces can also be defined and used from the enterprise .cui file.
|>
|>Your statement #2 is far too global.
|>
|>For instance, all the context-sensitive menus in Acad.cui are available to
|>me when I have my office .cui as the enterprise .cui file (my office .cui
|>has Acad.cui as a partial menu). Note that when I'm editing my office .cui
|>(as the main .cui file in my edit profile) that the context-sensitive menus
|>*are not* available, but will be as soon as I switch to the enterprise
|>profile. (IMHO, this is a CUI interface issue.)
0 Likes
Message 27 of 232

Anonymous
Not applicable
I am getting ready to switch over from 2005 to 2006. After reading the
following posts.
I get the impression that the documentation and help files are lacking....is
this true?

I have seperate menus for each of my four disciplines: Stru, Mech, Civl and
Elec along
with my main Arch menu. They all have their own mnl support files. The Arch
menu
is the main loaded menu and the other four are loaded as needed. We have no
user custom menus. Taken the above info into account, how should I proceed?

--
Gary Fowler - Architect
gdfowler@hotmail.com


"James Maeding" wrote in message
news:4839041@discussion.autodesk.com...
ok, so how about this:
Custom.cui - (main) for custom user toolbars, pulldowns, workspaces
Office.cui - (enterprise) for standard workspaces and everything
else...mouse buttons, keyboard shortcuts...
Acad.cui - (partial) for acad toolbars and pulldowns

to Do this, you would copy the acad.cui to the office cui, strip out the
acad toolbars, pulldowns, workspaces and add
yours.

Then go into the acad cui and strip out mouse buttons, shortcut menus,
keyboard shortcuts and so on.

Its like we need to undertstand where things can go and still work, and what
the precedence is for duplicate names of
things like workspaces for items that can be in several places and "work".
Then we can answer our own questions
according to our needs.

This is good timing as I am putting together our 2006 transition files right
now...

thanks


R. Robert Bell
|>Workspaces can also be defined and used from the enterprise .cui file.
|>
|>Your statement #2 is far too global.
|>
|>For instance, all the context-sensitive menus in Acad.cui are available to
|>me when I have my office .cui as the enterprise .cui file (my office .cui
|>has Acad.cui as a partial menu). Note that when I'm editing my office .cui
|>(as the main .cui file in my edit profile) that the context-sensitive
menus
|>*are not* available, but will be as soon as I switch to the enterprise
|>profile. (IMHO, this is a CUI interface issue.)
0 Likes
Message 28 of 232

Anonymous
Not applicable
If you do not need to worry about where users put customization, anything that physically functions is good.
If your testing shows everything working, I would implement what you did.

The only trick is how to split things up when the user has to be allowed to customize, while keeping the default acad
and standard company stuff separate. I think we are getting closer.

Gary Fowler
|>I am getting ready to switch over from 2005 to 2006. After reading the
|>following posts.
|>I get the impression that the documentation and help files are lacking....is
|>this true?
|>
|>I have seperate menus for each of my four disciplines: Stru, Mech, Civl and
|>Elec along
|>with my main Arch menu. They all have their own mnl support files. The Arch
|>menu
|>is the main loaded menu and the other four are loaded as needed. We have no
|>user custom menus. Taken the above info into account, how should I proceed?
0 Likes
Message 29 of 232

Anonymous
Not applicable
Why do all that work with the Acad.cui?

In the Office.cui, simply _menuload_ the Acad.cui. No need to strip stuff
out of the Acad.cui, AFAIK.

Add desired Acad.cui stuff to the Office.cui workspaces.

--
R. Robert Bell


"James Maeding" wrote in message
news:4839041@discussion.autodesk.com...
ok, so how about this:
Custom.cui - (main) for custom user toolbars, pulldowns, workspaces
Office.cui - (enterprise) for standard workspaces and everything
else...mouse buttons, keyboard shortcuts...
Acad.cui - (partial) for acad toolbars and pulldowns

to Do this, you would copy the acad.cui to the office cui, strip out the
acad toolbars, pulldowns, workspaces and add
yours.

Then go into the acad cui and strip out mouse buttons, shortcut menus,
keyboard shortcuts and so on.

Its like we need to undertstand where things can go and still work, and what
the precedence is for duplicate names of
things like workspaces for items that can be in several places and "work".
Then we can answer our own questions
according to our needs.

This is good timing as I am putting together our 2006 transition files right
now...

thanks


R. Robert Bell
|>Workspaces can also be defined and used from the enterprise .cui file.
|>
|>Your statement #2 is far too global.
|>
|>For instance, all the context-sensitive menus in Acad.cui are available to
|>me when I have my office .cui as the enterprise .cui file (my office .cui
|>has Acad.cui as a partial menu). Note that when I'm editing my office .cui
|>(as the main .cui file in my edit profile) that the context-sensitive
menus
|>*are not* available, but will be as soon as I switch to the enterprise
|>profile. (IMHO, this is a CUI interface issue.)
0 Likes
Message 30 of 232

Anonymous
Not applicable
Hi Robert,

It is a pity that they didn't investigate that everything was made easier -
or even possible!!!

They have completely broken our install process with no meaningful notice
that they would do so. Even ADN has not been able to give us a satisfactory
method of setting up a menu display short of investing in C++, learning it
and invoking the code they can supply.

For the short term we have to get our users to hand load menu files.

In the longer term I expect we will find a work around.

--


Laurie Comerford
CADApps
www.cadapps.com.au


"R. Robert Bell" wrote in message
news:4838273@discussion.autodesk.com...
Autodesk itself would be in a better position to discuss the reasons...
however, some reasons I've heard are that Autodesk wants to make it easier
to migrate custom settings in future releases. The CUI provides versioning
to aid this process.

We are experiencing a bit of growing pains here, but bear with it.

--
R. Robert Bell


"Alfredo Medina" wrote in message
news:4838259@discussion.autodesk.com...
Robert,

What was wrong with the old set of .mn* files that moved Autodesk to switch
to this new set of "CUI's" ?
0 Likes
Message 31 of 232

Anonymous
Not applicable
Personally, I would have Arch.cui as your enterprise .cui file, which would
menuload all the other menus (partial menus). Use workspaces defined in
Arch.cui to display the correct stuff for Struct/Mech/Civil/Elec. Don't
forget to add Acad.cui & Express Tools to the partial menu list for
Arch.cui.

Custom.cui would still be the main .cui file.

--
R. Robert Bell


"Gary Fowler" wrote in message
news:4839053@discussion.autodesk.com...
I am getting ready to switch over from 2005 to 2006. After reading the
following posts.
I get the impression that the documentation and help files are lacking....is
this true?

I have seperate menus for each of my four disciplines: Stru, Mech, Civl and
Elec along
with my main Arch menu. They all have their own mnl support files. The Arch
menu
is the main loaded menu and the other four are loaded as needed. We have no
user custom menus. Taken the above info into account, how should I proceed?

--
Gary Fowler - Architect
gdfowler@hotmail.com


"James Maeding" wrote in message
news:4839041@discussion.autodesk.com...
ok, so how about this:
Custom.cui - (main) for custom user toolbars, pulldowns, workspaces
Office.cui - (enterprise) for standard workspaces and everything
else...mouse buttons, keyboard shortcuts...
Acad.cui - (partial) for acad toolbars and pulldowns

to Do this, you would copy the acad.cui to the office cui, strip out the
acad toolbars, pulldowns, workspaces and add
yours.

Then go into the acad cui and strip out mouse buttons, shortcut menus,
keyboard shortcuts and so on.

Its like we need to undertstand where things can go and still work, and what
the precedence is for duplicate names of
things like workspaces for items that can be in several places and "work".
Then we can answer our own questions
according to our needs.

This is good timing as I am putting together our 2006 transition files right
now...

thanks


R. Robert Bell
|>Workspaces can also be defined and used from the enterprise .cui file.
|>
|>Your statement #2 is far too global.
|>
|>For instance, all the context-sensitive menus in Acad.cui are available to
|>me when I have my office .cui as the enterprise .cui file (my office .cui
|>has Acad.cui as a partial menu). Note that when I'm editing my office .cui
|>(as the main .cui file in my edit profile) that the context-sensitive
menus
|>*are not* available, but will be as soon as I switch to the enterprise
|>profile. (IMHO, this is a CUI interface issue.)
0 Likes
Message 32 of 232

Anonymous
Not applicable
I'm sorry to hear that Laurie.

--
R. Robert Bell


"Laurie Comerford" wrote in message
news:4839183@discussion.autodesk.com...
Hi Robert,

It is a pity that they didn't investigate that everything was made easier -
or even possible!!!

They have completely broken our install process with no meaningful notice
that they would do so. Even ADN has not been able to give us a satisfactory
method of setting up a menu display short of investing in C++, learning it
and invoking the code they can supply.

For the short term we have to get our users to hand load menu files.

In the longer term I expect we will find a work around.
0 Likes
Message 33 of 232

Anonymous
Not applicable
Thanks, ut I'm still confused.

--
Gary Fowler - Architect
gdfowler@hotmail.com


"James Maeding" wrote in message
news:4839077@discussion.autodesk.com...
If you do not need to worry about where users put customization, anything
that physically functions is good.
If your testing shows everything working, I would implement what you did.

The only trick is how to split things up when the user has to be allowed to
customize, while keeping the default acad
and standard company stuff separate. I think we are getting closer.

Gary Fowler
|>I am getting ready to switch over from 2005 to 2006. After reading the
|>following posts.
|>I get the impression that the documentation and help files are
lacking....is
|>this true?
|>
|>I have seperate menus for each of my four disciplines: Stru, Mech, Civl
and
|>Elec along
|>with my main Arch menu. They all have their own mnl support files. The
Arch
|>menu
|>is the main loaded menu and the other four are loaded as needed. We have
no
|>user custom menus. Taken the above info into account, how should I
proceed?
0 Likes
Message 34 of 232

Anonymous
Not applicable
Thanks, I will try that approach.

--
Gary Fowler - Architect
gdfowler@hotmail.com


"R. Robert Bell" wrote in message
news:4839199@discussion.autodesk.com...
Personally, I would have Arch.cui as your enterprise .cui file, which would
menuload all the other menus (partial menus). Use workspaces defined in
Arch.cui to display the correct stuff for Struct/Mech/Civil/Elec. Don't
forget to add Acad.cui & Express Tools to the partial menu list for
Arch.cui.

Custom.cui would still be the main .cui file.

--
R. Robert Bell


"Gary Fowler" wrote in message
news:4839053@discussion.autodesk.com...
I am getting ready to switch over from 2005 to 2006. After reading the
following posts.
I get the impression that the documentation and help files are lacking....is
this true?

I have seperate menus for each of my four disciplines: Stru, Mech, Civl and
Elec along
with my main Arch menu. They all have their own mnl support files. The Arch
menu
is the main loaded menu and the other four are loaded as needed. We have no
user custom menus. Taken the above info into account, how should I proceed?

--
Gary Fowler - Architect
gdfowler@hotmail.com


"James Maeding" wrote in message
news:4839041@discussion.autodesk.com...
ok, so how about this:
Custom.cui - (main) for custom user toolbars, pulldowns, workspaces
Office.cui - (enterprise) for standard workspaces and everything
else...mouse buttons, keyboard shortcuts...
Acad.cui - (partial) for acad toolbars and pulldowns

to Do this, you would copy the acad.cui to the office cui, strip out the
acad toolbars, pulldowns, workspaces and add
yours.

Then go into the acad cui and strip out mouse buttons, shortcut menus,
keyboard shortcuts and so on.

Its like we need to undertstand where things can go and still work, and what
the precedence is for duplicate names of
things like workspaces for items that can be in several places and "work".
Then we can answer our own questions
according to our needs.

This is good timing as I am putting together our 2006 transition files right
now...

thanks


R. Robert Bell
|>Workspaces can also be defined and used from the enterprise .cui file.
|>
|>Your statement #2 is far too global.
|>
|>For instance, all the context-sensitive menus in Acad.cui are available to
|>me when I have my office .cui as the enterprise .cui file (my office .cui
|>has Acad.cui as a partial menu). Note that when I'm editing my office .cui
|>(as the main .cui file in my edit profile) that the context-sensitive
menus
|>*are not* available, but will be as soon as I switch to the enterprise
|>profile. (IMHO, this is a CUI interface issue.)
0 Likes
Message 35 of 232

Anonymous
Not applicable
I am finding out that I was wrong about mouse buttons and other things only working from the main and enterprise cui.

Now my question is how conflics are resolved for things like mouse buttons and keyboard shortcuts.
Is there a precedence rule? maybe its the order the menus are loaded in?
thx
0 Likes
Message 36 of 232

Anonymous
Not applicable
So, do I keep my seperate mnl files, one for each of my past menu files?
Or combine them into one mnl file?

--
Gary Fowler - Architect
gdfowler@hotmail.com


"R. Robert Bell" wrote in message
news:4839199@discussion.autodesk.com...
Personally, I would have Arch.cui as your enterprise .cui file, which would
menuload all the other menus (partial menus). Use workspaces defined in
Arch.cui to display the correct stuff for Struct/Mech/Civil/Elec. Don't
forget to add Acad.cui & Express Tools to the partial menu list for
Arch.cui.

Custom.cui would still be the main .cui file.

--
R. Robert Bell


"Gary Fowler" wrote in message
news:4839053@discussion.autodesk.com...
I am getting ready to switch over from 2005 to 2006. After reading the
following posts.
I get the impression that the documentation and help files are lacking....is
this true?

I have seperate menus for each of my four disciplines: Stru, Mech, Civl and
Elec along
with my main Arch menu. They all have their own mnl support files. The Arch
menu
is the main loaded menu and the other four are loaded as needed. We have no
user custom menus. Taken the above info into account, how should I proceed?

--
Gary Fowler - Architect
gdfowler@hotmail.com


"James Maeding" wrote in message
news:4839041@discussion.autodesk.com...
ok, so how about this:
Custom.cui - (main) for custom user toolbars, pulldowns, workspaces
Office.cui - (enterprise) for standard workspaces and everything
else...mouse buttons, keyboard shortcuts...
Acad.cui - (partial) for acad toolbars and pulldowns

to Do this, you would copy the acad.cui to the office cui, strip out the
acad toolbars, pulldowns, workspaces and add
yours.

Then go into the acad cui and strip out mouse buttons, shortcut menus,
keyboard shortcuts and so on.

Its like we need to undertstand where things can go and still work, and what
the precedence is for duplicate names of
things like workspaces for items that can be in several places and "work".
Then we can answer our own questions
according to our needs.

This is good timing as I am putting together our 2006 transition files right
now...

thanks


R. Robert Bell
|>Workspaces can also be defined and used from the enterprise .cui file.
|>
|>Your statement #2 is far too global.
|>
|>For instance, all the context-sensitive menus in Acad.cui are available to
|>me when I have my office .cui as the enterprise .cui file (my office .cui
|>has Acad.cui as a partial menu). Note that when I'm editing my office .cui
|>(as the main .cui file in my edit profile) that the context-sensitive
menus
|>*are not* available, but will be as soon as I switch to the enterprise
|>profile. (IMHO, this is a CUI interface issue.)
0 Likes
Message 37 of 232

Anonymous
Not applicable
Digitizer buttons do not work from a partial menu, or at least
I haven't been able to get them to work, each time I ask the
simple (yes or no) question it seemingly goes ignored 😞

Just FYI.


"James Maeding" wrote in message
news:4839212@discussion.autodesk.com...
I am finding out that I was wrong about mouse buttons and other things only
working from the main and enterprise cui.
0 Likes
Message 38 of 232

Anonymous
Not applicable
I guess the easy way to test is load the blank custom.cui as main menu and acad as partial.
I'm sure you are right though.

Do you mean all input devices, or just mice and tablet pucks?
thx

Jason Piercey
|>Digitizer buttons do not work from a partial menu, or at least
|>I haven't been able to get them to work, each time I ask the
|>simple (yes or no) question it seemingly goes ignored 😞
|>
|>Just FYI.
|>
|>
|>"James Maeding" wrote in message
|>news:4839212@discussion.autodesk.com...
|>I am finding out that I was wrong about mouse buttons and other things only
|>working from the main and enterprise cui.
0 Likes
Message 39 of 232

Anonymous
Not applicable
AFAIK, just tablet pucks. Haven't messed with
any other devices to this point.



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

Do you mean all input devices, or just mice and tablet pucks?
thx
0 Likes
Message 40 of 232

Anonymous
Not applicable
I want to highlight I point I made in the initial post for emphasis. Please
see below.

--
R. Robert Bell


"R. Robert Bell" wrote in message
news:4838060@discussion.autodesk.com...
... 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

***Please note that this diagram indicates that Acad.cui and AcetMain.cui
(Express) are *menuloaded as partial CUI files in the enterprise* .cui file!
This is a critical point. When you have those as partial files you can
easily maintain your workspaces for the enterprise .cui file. Otherwise, you
are going to run into unresolved references with workspaces.

If you assign those partial .cui files from your Windows profile location
the location *will resolve correctly* for your users. IOW, AutoCAD won't
look for Acad.cui under your login name, rather, will use the user's
Acad.cui in their support folder.
0 Likes