Notes on the philosophy of CUI

Anonymous · ‎05-07-2005

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 · ‎05-10-2005

I'm not going to try to break the CUI by partial loading the same CUI in
both main & enterprise. I'll leave that up to you.

I don't think it is explicitly documented, but it makes sense when you think
about how all the pieces work.

--
R. Robert Bell

"James Maeding" wrote in message
news:4840310@discussion.autodesk.com...
oh, I see said the blind man.
Duh, I did not have an enterprise CUI loaded...got it now

How does that help resolve conflicts though?
Is this documented anywhere about the difference between loading partials
under the main or enterprise CUI?

thx

R. Robert Bell
|>A picture is worth...

Anonymous · ‎05-10-2005

I reread your previus post and realized you were not commenting on conflicts.
You were talking about where a menu would be looked for when a workspace went to find it.

I had not thought of that, since stuff in in our profile folder, our specific name is in it.
Are you saying Acad treats things generic when menus are loaded under the enterprise menu, but specific when unser the
main menu?

I guess we could hack the CUI file to change the paths to generic for any user and see if it works...
thx

James Maeding
|>oh, I see said the blind man.
|>Duh, I did not have an enterprise CUI loaded...got it now
|>
|>How does that help resolve conflicts though?
|>Is this documented anywhere about the difference between loading partials under the main or enterprise CUI?
|>
|>thx
|>
|>
|>R. Robert Bell
|>|>A picture is worth...

Anonymous · ‎05-10-2005

Hack what?

I think you are making this more complicated than it needs to be.

Acad's and Express Tools .cui will be found by AutoCAD using normal support
folder resolution.
If you specify a .cui at a location not on the support paths, then the
location specified at initial load time is the one used.

AFAIK, there is no need to hack the .cui itself for locations.

--
R. Robert Bell

"James Maeding" wrote in message
news:4840351@discussion.autodesk.com...
I reread your previus post and realized you were not commenting on
conflicts.
You were talking about where a menu would be looked for when a workspace
went to find it.

I had not thought of that, since stuff in in our profile folder, our
specific name is in it.
Are you saying Acad treats things generic when menus are loaded under the
enterprise menu, but specific when unser the
main menu?

I guess we could hack the CUI file to change the paths to generic for any
user and see if it works...
thx

Anonymous · ‎05-10-2005

That was my question regarding saved paths to partial
menus. Only menu names are saved in the cui file not
the path. Below is from my main cui file.

acad.cui
acetmain.cui

"James Maeding" wrote in message
news:4840351@discussion.autodesk.com...
I guess we could hack the CUI file to change the paths to generic for any
user and see if it works...

Anonymous · ‎05-10-2005

Got it, that does eliminate the need and desire to edit the CUI for menu paths.
I guess the desire never was there anyway 🙂

Jason Piercey
|>That was my question regarding saved paths to partial
|>menus. Only menu names are saved in the cui file not
|>the path. Below is from my main cui file.
|>
|>
|>
|>
|> acad.cui
|> acetmain.cui
|>
|>
|>
|>
|>
|>
|>
|>"James Maeding" wrote in message
|>news:4840351@discussion.autodesk.com...
|>I guess we could hack the CUI file to change the paths to generic for any
|>user and see if it works...

Anonymous · ‎05-10-2005

I found that in the main cui there where no Mouse Buttons definition. I
could not add any using CUI but had to create a new main cui by transfering
those from acad.cui to a new cui in this case custom.cui.

--
Best Regards, Jimmy Bergmark
CAD and Database Developer Manager at www.pharmadule-emtunga.com
Blog: http://jtbworld.blogspot.com
JTB FlexReport (FLEXnet / FLEXlm report tool) -
http://www.jtbworld.com/jtbflexreport
SmartPurger (Purges automatically) -
http://www.jtbworld.com/?/smartpurger.htm
or download some freeware at http://www.jtbworld.com
More on AutoCAD 2005 and 2006
http://www.jtbworld.com/autocad2005.htm
http://www.jtbworld.com/autocad2006.htm

"Jack G" wrote in message
news:4840188@discussion.autodesk.com...
Does that mean you're repealing "Maedings Laws" (1: Toolbars and pulldown
menus can be placed anywhere; 2: Everything else only works when in the main
cui)? That's too bad because that was the first clear statement I've seen
about the functioning of cui's!! I'm still desperately hoping that at the
end of this thread you or someone else will rewrite the laws in an equally
clear and precise statement to help me understand this stuff! I've been
unable to get Pop0's to work anywhere but in a "main" cui, so I keep reading
these threads with baited breath.

Interesting that the AutoCad guys don't chime in except when the cui
questions are easy! You might think they could give us the laws!

Jack

"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.

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

Anonymous · ‎05-10-2005

Unless the partial cui is *not* on the support folder path, e.g.
c:\documents and settings\robertb\my
documents\acadx.com\stuff\test.cui

--
R. Robert Bell

"Jason Piercey" wrote in message
news:4840409@discussion.autodesk.com...
That was my question regarding saved paths to partial
menus. Only menu names are saved in the cui file not
the path. Below is from my main cui file.

acad.cui
acetmain.cui

"James Maeding" wrote in message
news:4840351@discussion.autodesk.com...
I guess we could hack the CUI file to change the paths to generic for any
user and see if it works...

Anonymous · ‎05-10-2005

Hi all,

I'm currently struggling through this myself... comprehensive, and probably not even accurate> Here is my current theory
FWIW:

Precedence:
1. Main
2. Enterprise
3. Enterprise Partial #1
4. Enterprise Partial #2
5. Enterprise Partial #...
6. Main Partial #1
7. Main Partial #2
8. Main Partial #...
9. etc.

Availability:
Except for Workspaces, all items are available from any file. Workspaces
are only available from Main and CUI files.

Conflict Resolution:
Except for Workspaces, like names from separate files do not conflict, they
can be loaded/displayed simultaneously. Workspace name conflicts seem to
present an exception to the precedence list as well, as the Enterprise
Workspace takes precedence over a like-named Main Workspace.

Mouse Buttons:
The various key combinations cannot be added or removed through cui, only
Buttons and Button Assignments within those definitions. *All* button
assignments will come from the highest-precedence file that has *any* mouse
buttons defined, even if they are not assigned. The key combinations do not
have to be removed to allow definitions below to take effect, just the
Buttons deleted in the cui editor.

Proof (HA!):
Create a structure like that shown above, and give each file a single
shortcut menu with a unique command button and POP501 as one of the aliases.
Make sure you have a valid mouse right-click button defined. Right-click
and see which menu you get. Go down the precedence list one file at a time
removing the POP 501 menu alias and seeing which menu you get next. Keep in
mind you may have to go to extremes to make sure your changes have taken
full effect after each change. I found that manually removing, applying,
adding, and applying the Enterprise file in options helped force the
loading.

I hope this is at least a start in the right direction. I have done close
to nothing with legacy options.
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO

"Jack G" wrote in message
news:4840188@discussion.autodesk.com...
Does that mean you're repealing "Maedings Laws" (1: Toolbars and pulldown
menus can be placed anywhere; 2: Everything else only works when in the main
cui)? That's too bad because that was the first clear statement I've seen
about the functioning of cui's!! I'm still desperately hoping that at the
end of this thread you or someone else will rewrite the laws in an equally
clear and precise statement to help me understand this stuff! I've been
unable to get Pop0's to work anywhere but in a "main" cui, so I keep reading
these threads with baited breath.

Interesting that the AutoCad guys don't chime in except when the cui
questions are easy! You might think they could give us the laws!

Jack

Anonymous · ‎05-10-2005

Anonymous · ‎05-10-2005

ah, then a hack would be in order!
I prefer progs to look at the filename and see if it can be found, then use the full path if not.

R. Robert Bell
|>Unless the partial cui is *not* on the support folder path, e.g.
|>c:\documents and settings\robertb\my
|>documents\acadx.com\stuff\test.cui

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎05-10-2005

Stark confusion.

If I want something to come from a specific location only, I don't put that
location in the support folders search path. For instance, the
office-standard .cui is *not* located in the support folders. It is
explicitly found in one location only.

Acad.cui... let it load from where it is found on the support path, I don't
care.

I still don't see why you would want to alter the xml for this sort of case.
I wouldn't be surprised if your hack edit disappeared with the next edit you
make in the CUI editor anyway. So why fight it?

--
R. Robert Bell

"James Maeding" wrote in message
news:4840750@discussion.autodesk.com...
ah, then a hack would be in order!
I prefer progs to look at the filename and see if it can be found, then use
the full path if not.

R. Robert Bell
|>Unless the partial cui is *not* on the support folder path, e.g.
|>c:\documents and settings\robertb\my
|>documents\acadx.com\stuff\test.cui

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎05-10-2005

I'm talking about my own custom Pop0's. They only seem to work if they're in
the "main" menu, and I'd like to be able to control and revise them from an
"enterprise" menu.

"R. Robert Bell" wrote in message
news:4840234@discussion.autodesk.com...
Jack,

Are you talking about a custom POP0 or simply the default Acad one?

--
R. Robert Bell

"Jack G" wrote in message
news:4840188@discussion.autodesk.com...
Does that mean you're repealing "Maedings Laws" (1: Toolbars and pulldown
menus can be placed anywhere; 2: Everything else only works when in the main
cui)? That's too bad because that was the first clear statement I've seen
about the functioning of cui's!! I'm still desperately hoping that at the
end of this thread you or someone else will rewrite the laws in an equally
clear and precise statement to help me understand this stuff! I've been
unable to get Pop0's to work anywhere but in a "main" cui, so I keep reading
these threads with baited breath.

Anonymous · ‎05-11-2005

Thanks Bob.

"R. Robert Bell" wrote in message
news:4840679@discussion.autodesk.com...
Unless the partial cui is *not* on the support folder path, e.g.
c:\documents and settings\robertb\my
documents\acadx.com\stuff\test.cui

Anonymous · ‎05-11-2005

Hi Jack,

I'm partly just thinking out loud here, but hoping it will benefit you and
others as well. So hopefully I'm not too far off.

I see two basic concepts at work with the mouse buttons; Definition, and
Assignment. Definition simply means there is a placeholder present for the
button, and Assignment means a command has been assigned to it. Any buttons
you see listed under Click, Shift+Click, etc. are Defined. Any of those
buttons which say anything other than after the colon are Assigned.
So for example if you see "Button 4: ", then Button 4 is Defined but
not Assigned.

It seems that ALL of the mouse button Assignments are derived from the first
file found that has ANY mouse button Definitions, even if they are not
Assigned. So even if the main file only has "Click - Button 2: " and
no other button Definitions, no buttons from any other file will make any
difference and no mouse clicks will do anything. If there are NO buttons
Defined in the main file, and if an enterprise file is loaded and has any
mouse button Definitions, then all button Assignments will come from the
enterprise file.

Jack, for your particular issue I think you first need to figure out which
menu mouse button Assignments are coming from. If you have any mouse
buttons Defined in your main file, then that is where all the Assignments
are coming from. Once you determine which file is controlling the button
Assignments, you need to check the commands Assigned to the buttons in that
file. If you have a Snap (alias, not menu name) menu defined in the main
file and the enterprise file, and the button command reads "$P0=SNAP $P0=*
", then you will get the main file Snap menu, not the enterprise version.
If you want to leave the main file's Snap menu in place but use the Snap
menu from the enterprise file, then you can revise the command to read
"$P0=.SNAP $P0=* " and thus directly reference
your enterprise Snap menu. HTH

TWIMC, the proposed structure Robert started this thread with could have
some undesirable consequences if we're not careful. For example, if the
user adds a mouse button Definition to their file, then suddenly their menu
takes over all of the mouse button Assignments even if they did not assign
any commands to them. Similarly, if we reference a Snap menu without a hard
file reference, and the user adds their own Snap menu, then theirs will win.
Food for thought...
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO

"Jack G" wrote in message
news:4840850@discussion.autodesk.com...
I'm talking about my own custom Pop0's. They only seem to work if they're in
the "main" menu, and I'd like to be able to control and revise them from an
"enterprise" menu.

Anonymous · ‎05-11-2005

I'm trying out Roberts Method. I'd like ACAD.CUI to set the button
assignments. As I'm sure the next version of AutoCAD will change the
assignments and am ok with AutoCAD just doing it. I don't have any buttons
assigned under CUSTOM.CUI nor my enterprise CUI. ACAD.CUI is partially
loaded under the enterprise setup.

Configured like I have it my shift + right click doesn't work. I'm thinking
that to make this work I'd need to transfer those assignments to the
Main(custom.cui) or the enterprise CUI.

Are you seeing the same thing?

Sage

"James Allen" wrote in message
news:4841232@discussion.autodesk.com...
Hi Jack,

I'm partly just thinking out loud here, but hoping it will benefit you and
others as well. So hopefully I'm not too far off.

I see two basic concepts at work with the mouse buttons; Definition, and
Assignment. Definition simply means there is a placeholder present for the
button, and Assignment means a command has been assigned to it. Any buttons
you see listed under Click, Shift+Click, etc. are Defined. Any of those
buttons which say anything other than after the colon are Assigned.
So for example if you see "Button 4: ", then Button 4 is Defined but
not Assigned.

It seems that ALL of the mouse button Assignments are derived from the first
file found that has ANY mouse button Definitions, even if they are not
Assigned. So even if the main file only has "Click - Button 2: " and
no other button Definitions, no buttons from any other file will make any
difference and no mouse clicks will do anything. If there are NO buttons
Defined in the main file, and if an enterprise file is loaded and has any
mouse button Definitions, then all button Assignments will come from the
enterprise file.

Jack, for your particular issue I think you first need to figure out which
menu mouse button Assignments are coming from. If you have any mouse
buttons Defined in your main file, then that is where all the Assignments
are coming from. Once you determine which file is controlling the button
Assignments, you need to check the commands Assigned to the buttons in that
file. If you have a Snap (alias, not menu name) menu defined in the main
file and the enterprise file, and the button command reads "$P0=SNAP $P0=*
", then you will get the main file Snap menu, not the enterprise version.
If you want to leave the main file's Snap menu in place but use the Snap
menu from the enterprise file, then you can revise the command to read
"$P0=.SNAP $P0=* " and thus directly reference
your enterprise Snap menu. HTH

TWIMC, the proposed structure Robert started this thread with could have
some undesirable consequences if we're not careful. For example, if the
user adds a mouse button Definition to their file, then suddenly their menu
takes over all of the mouse button Assignments even if they did not assign
any commands to them. Similarly, if we reference a Snap menu without a hard
file reference, and the user adds their own Snap menu, then theirs will win.
Food for thought...
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO

"Jack G" wrote in message
news:4840850@discussion.autodesk.com...
I'm talking about my own custom Pop0's. They only seem to work if they're in
the "main" menu, and I'd like to be able to control and revise them from an
"enterprise" menu.

Anonymous · ‎05-11-2005

Sage,

The mouse buttons are a bit tricky, and the rules aren't obvious to any of
us yet.

For instance, the assumption has been made that if mouse buttons are defined
in a "higher priority" cui, that it rules all mouse button definitions.

That cannot be entirely true, as my environment has only two mouse buttons
defined in my enterprise cui, Ctrl+Click (Button 2) and Ctrl+Shift+Click
(Button 2). Both of those work correctly.

The interesting bit is that my Click group is only located in my partially
loaded Acad.cui (by the enterprise cui file) and it works correctly!
However, the Shift+Click that is only defined there does _not_.

I will explore this further in the next day or two.

--
R. Robert Bell

"Sage Cowsert" wrote in message
news:4841461@discussion.autodesk.com...
I'm trying out Roberts Method. I'd like ACAD.CUI to set the button
assignments. As I'm sure the next version of AutoCAD will change the
assignments and am ok with AutoCAD just doing it. I don't have any buttons
assigned under CUSTOM.CUI nor my enterprise CUI. ACAD.CUI is partially
loaded under the enterprise setup.

Configured like I have it my shift + right click doesn't work. I'm thinking
that to make this work I'd need to transfer those assignments to the
Main(custom.cui) or the enterprise CUI.

Are you seeing the same thing?

Sage

Anonymous · ‎05-11-2005

Well, I won't be editing any CUI's in a text editor, maybe only looking at them for info.
I always tell people here to add a support path to a given menu, then load the menu.

One thing I do here that I think some people do is to set back certain files every morning if they have been modified.
So the idea of an enterprise menu has already been in place for a long time.

One thing I have not figured out is how to get mu F11 key to bring up the osnap menu.
I do this so I can have mbuuton pan on and set my "thumb" mouse button to keystroke F11 to get the snap menu.

any suggestions welcome.
thx

R. Robert Bell
|>Stark confusion.
|>
|>If I want something to come from a specific location only, I don't put that
|>location in the support folders search path. For instance, the
|>office-standard .cui is *not* located in the support folders. It is
|>explicitly found in one location only.
|>
|>Acad.cui... let it load from where it is found on the support path, I don't
|>care.
|>
|>I still don't see why you would want to alter the xml for this sort of case.
|>I wouldn't be surprised if your hack edit disappeared with the next edit you
|>make in the CUI editor anyway. So why fight it?

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎05-11-2005

If anyone is interested, Shaan's blog has 4 videos on CUI's.
Intersting that they also recommend making the custom.cui the main cui.

http://autodesk.blogs.com/between_the_lines/

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎05-11-2005

James,

Here is how I did that.

Load your enterprise edit profile.
Add a new command. (I called mine "OSnap Menu")
The macro I provided was: (menucmd "POP0=ACAD.SNAP")(menucmd "POP0=*")
I changed the Element ID to fit my naming structure: MW_ShowSnap
Hit to save the new command.
Expand the Keyboard Shortcuts node for the MW.cui.
Expand the Shortcut Keys node.
Drag and drop the new "OSnap Menu" command into the Shortcut Keys node.
Edit the properties to use the F11 key.
Hit to save and exit the CUI dialog.

Test F11 now.

--
R. Robert Bell

"James Maeding" wrote in message
news:4841527@discussion.autodesk.com...
Well, I won't be editing any CUI's in a text editor, maybe only looking at
them for info.
I always tell people here to add a support path to a given menu, then load
the menu.

One thing I do here that I think some people do is to set back certain files
every morning if they have been modified.
So the idea of an enterprise menu has already been in place for a long time.

One thing I have not figured out is how to get mu F11 key to bring up the
osnap menu.
I do this so I can have mbuuton pan on and set my "thumb" mouse button to
keystroke F11 to get the snap menu.

any suggestions welcome.
thx

R. Robert Bell
|>Stark confusion.
|>
|>If I want something to come from a specific location only, I don't put
that
|>location in the support folders search path. For instance, the
|>office-standard .cui is *not* located in the support folders. It is
|>explicitly found in one location only.
|>
|>Acad.cui... let it load from where it is found on the support path, I
don't
|>care.
|>
|>I still don't see why you would want to alter the xml for this sort of
case.
|>I wouldn't be surprised if your hack edit disappeared with the next edit
you
|>make in the CUI editor anyway. So why fight it?

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎05-11-2005

Wow. I didn't know that. The first I heard of the videos was last night,
haven't even gotten the chance to view them yet.

--
R. Robert Bell

"James Maeding" wrote in message
news:4841723@discussion.autodesk.com...
If anyone is interested, Shaan's blog has 4 videos on CUI's.
Intersting that they also recommend making the custom.cui the main cui.

http://autodesk.blogs.com/between_the_lines/

Community

Notes on the philosophy of CUI

Notes on the philosophy of CUI

Notes on the philosophy of CUI