Notes on the philosophy of CUI
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.
RE: Notes on the philosophy of CUI
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?
RE: Notes on the philosophy of CUI
A couple of Autodesk definitions:
Quote:
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..........
RE: Notes on the philosophy of CUI
Quote:
Originally Posted by lance.81922
...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.
RE: Notes on the philosophy of CUI
Quote:
Originally Posted by steve.johnson
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.
RE: Notes on the philosophy of CUI
Quote:
Originally Posted by steve.johnson
What is the capital of Venezuela?
I don't know about the other stuff, but here is the capital of Venezuela: Caracas
RE: Notes on the philosophy of CUI
Quote:
Originally Posted by steve.johnson
What is the capital of Venezuela?
Caracas. :Oops: The only question I could answer with some surety.
RE: Notes on the philosophy of CUI
Quote:
Originally Posted by RobertB
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?
Quote:
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.
Quote:
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?
Quote:
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"?
Quote:
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.
Which is what understanding the new menu system's "logic" is sending me...