Notes on the philosophy of CUI

[RobertB]

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.

Edit: I now recommend creating a new blank CUI via the transfer tab. You can save that to Custom.cui (overwrite) if you don't have any items in there. Later parts of this thread explain why.

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

Edit: If you want to use Custom.cui, and it is currently empty, use the Transfer tab to SaveAs the blank cui on the right pane to Custom.cui, overwriting it.

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

[mtlynn]

I keep seeing this CUI file in the forums. But for us who are not up on 06 terminology yet what does it stand for?

[lance.81922]

A couple of Autodesk definitions:

Customization (CUI) file
An XML-based file that stores customization data. You modify a customization file through the Customize User Interface dialog box. CUI files replace MNU, MNS, and MNC files that were used to define menus in releases prior to AutoCAD 2006.

Main customization file
A writable CUI file that defines most of the user interface elements (including the standard menus, toolbars, keyboard accelerators, and so on). The acad.cui file (the default main CUI file) is automatically loaded when you start AutoCAD.

Thus the CUI contains everything that used to be in both menus AND toolbars, which are themselves custom menus.
RobertB's points are well taken, and I'm going to mull them over before I do anything rash. Now I wish I'd saved a backup copy of ACAD.CUI..........

[RobertB]

...RobertB's points are well taken, and I'm going to mull them over before I do anything rash. Now I wish I'd saved a backup copy of ACAD.CUI...

You can copy the default installed version from C:\Program Files\AutoCAD 2006\UserDataCache.

[lance.81922]

Thanks. I figured that out (location of the unaltered ACAD.CUI) from looking at the dates of all my CUI files. I'm still trying to figure out the intricacies of what goes where.

[Steve Johnson]

OK, I'll try thinking upside down and see if I can make things work.

Here's the system I manage, let's see if I can make it fit into 2006. Names are changed to protect the guilty.

-Acad (main)
--Express
--OfficeMain (toolbars/pop/image/helpstrings)
--OfficeKeys (accelerators + 1 dummy pop)
--OfficeSheet (1 toolbar / 1 pop)
--OfficeDisciplineA (1 toolbar / 1 pop)
--OfficeDisciplineB (1 toolbar / 1 pop)
--OfficeDisciplineC (3 toolbars / 1 pop)
--OfficeDisciplineD (1 toolbar / 1 dummy pop)
:
:
--OfficeDisciplineZ (1 toolbar / 1 pop)
--User (1 toolbar / 1 dummy pop)

- All of these menus are kept on the local PC. This allows people to keep drawing productively if there is a network problem (which has happened from time to time).

- All menus except the Acad and User ones are subject to automated update / replacement from the server, where the latest versions of all custom files are kept. Although this is automated, the users have an optional interface that allows them to delay such updates or initiate them themselves. This is because network speeds are slow in some of our locations, and it allows them to update at convenient times (e.g. during lunch).

- If users want to do customisation, they do it based on the User menu, which they are encouraged to modify and enlarge as they see fit. This is considered sacrosanct: I give them a simple example one and let them go for it, and I never touch it unless asked.

- The various OfficeDiscipline menus are loaded and unloaded as and when the user needs them, using menu items in OfficeMain to load them, and an Unload Menu item in each OfficeDiscipline menu.

- The various OfficeDiscipline menus are separate for ease of maintenance. This allows me to modify them without forcing every user to have their OfficeMain menu updated.

- The OfficeKeys menu is separate for historical reasons (an old AutoCAD bug meant that accelerators in partial menus needed to be unloaded and reloaded at the start of each drawing), and this could be absorbed into OfficeMain these days.

- The OfficeSheet menu is separate for historical reasons because it is part of a software package we distribute to external contractors to allow them to use our title blocks, check the drawings against our standards, etc. This could also be absorbed into OfficeMain.

- The various dummy pop menus are used purely to allow me to check to see if the menu is already loaded. If there's a real pop, I don't need a dummy. Here's an example:

***POP1
ID_Sheet [User]
ID_User [User Command]^C^CUSER_COMMAND

Which I check for with code like this (the real code doesn't contain hardwired names) before attempting a MENULOAD:

(menucmd "GUSER.ID_User=?")

- My menu loading code automatically places any non-dummy pops in the right place (i.e. to the left of the Help item).


So, here's what I propose for 2006, based on Robert's suggestions:

-User (1 toolbar / 1 dummy pop)
--OfficeMain (toolbars/pop/image/helpstrings/accelerators)
--Acad (or copy thereof)
--Express
--OfficeDisciplineA (1 toolbar / 1 pop)
--OfficeDisciplineB (1 toolbar / 1 pop)
--OfficeDisciplineC (3 toolbars / 1 pop)
--OfficeDisciplineD (1 toolbar / 1 dummy pop)
:
:
--OfficeDisciplineZ (1 toolbar / 1 pop)

I don't propose using the Enterprise feature, unless someone can suggest a good reason for doing so in our environment. If I did have an Enterprise menu, I suppose it would be OfficeMain. I assume I can only have one read-only partial menu, is that right?

Comments? Suggestions? Implications of doing it this way? How do I make sure the pops end up in the right places, and ensure that the dummy ones don't appear? How do workspaces fit into this scenario? What is the capital of Venezuela?

[RobertB]

I don't propose using the Enterprise feature, unless someone can suggest a good reason for doing so in our environment. If I did have an Enterprise menu, I suppose it would be OfficeMain. I assume I can only have one read-only partial menu, is that right?

Comments? Suggestions? Implications of doing it this way? How do I make sure the pops end up in the right places, and ensure that the dummy ones don't appear? How do workspaces fit into this scenario? What is the capital of Venezuela?

I think your questions at the end of your post highlight exactly why you should use an Enterprise .cui file.

You can create office standard workspaces to position the interface exactly how you require it. And since the workspaces will be in the Enterprise .cui file, they will be available, read-only, and a fall-back to office standards.

I would also advise using workspaces to switch your discipline-specific elements on and off. I also see no real reason for dummy elements due to Enterprise/workspace features.

Oh, and by the way... forget all the sub .cui files. Get all the Office stuff into one .cui and control the interface via workspaces.

[Steve_Bennett]

What is the capital of Venezuela?

I don't know about the other stuff, but here is the capital of Venezuela: Caracas

[Ron Oldenbeuving]

What is the capital of Venezuela?

Caracas. The only question I could answer with some surety.

[Steve Johnson]

I think your questions at the end of your post highlight exactly why you should use an Enterprise .cui file..

Hmm, possibly, but there is a lot to be considered first. Help states that it has to be in a shared network location. If that were true, it would kill the idea right away. Is Help correct?

You can create office standard workspaces to position the interface exactly how you require it. And since the workspaces will be in the Enterprise .cui file, they will be available, read-only, and a fall-back to office standards.

Yes, having a standard workspace to fall back on would be handy, although very rarely used. However, in my environment I could do that in 2006 without using Enterprise files. If the canonical OfficeMain.cui gets copied from the server as part of our normal update mechanism, is will bring its virgin workspace(s) with it. However, I can see the benefit of preventing users from mangling them in the first place.

I would also advise using workspaces to switch your discipline-specific elements on and off.

I don't think that would work. We have 13 discipline menus at the moment. Users can have 0, 1, 2 or whatever of these menus open at any time, to suit the mix of drawing types that they're dealing with. It would be a practical impossibility to provide workspaces for all of the combinations. Also, wouldn't a user choosing an office-provided workspace have all their carefully placed toolbars messed up?

I also see no real reason for dummy elements due to Enterprise/workspace features.

OK, if you say so. How do I programatically detect the presence or abscence of a partial menu in the "new way"?

Oh, and by the way... forget all the sub .cui files. Get all the Office stuff into one .cui and control the interface via workspaces.

I don't think that would work either. I repeat, "The various OfficeDiscipline menus are separate for ease of maintenance. This allows me to modify them without forcing every user to have their OfficeMain menu updated." The logical reasons for keeping them apart appear to be unchanged: I would prefer not to wade through a huge menu file if I can avoid it, especially using the painfully slow CUI interface. Also, as cui files are much bigger than mn* files, the practical reason for keeping them apart has just multiplied, rather than reduced. I wouldn't want to inflict a large-file WAN transfer on all my users, when I'm just modifying a discipline-specific menu for a handful of them.

Please note that I'm not being deliberately argumentative, I'm just trying to work through all the implications of doing things, as they apply to my environment.

Caracas

Which is what understanding the new menu system's "logic" is sending me...