Notes on the philosophy of CUI

[jrebennack]

I searched and did not find an answer, so hopefully I have something new here.

We are about to deploy LDT2007. I've set up the following CUI tree:

Custom.cui (main, client load)
Land.cui (enterprise, server load)
-acad
-survey
-express
-lai (company)

OK, so here is the problem. I turn off a toolbar in LDT, Land Desktop workspace and then change the workspace to from Land Desktop to another workspace and back to Land Desktop and BOOM! the toolbar comes back, in a predefined location. I know this is because the toolbar is defined as being turned on and in said location in the Land.cui file. I'm thinking that if I turned off all the toolbars in the Land.cui file, I would have the opposite problem.

Workspaces are automatically saving, UI is unlocked.

Here is what I was aiming for with this particular CUI setup: I want a standardized location for all CUIs on the network, but still allow the client machines to do some customization, but to have that customization on there computer. I want the users to be able to turn on and turn off there toolbars and place them where they want (I'm not that much of a control freak). However, the one thing I don't want them to be able to do is to edit the predefined toolbars. If they want special toolbars, they have to be totally custom.

Any thoughts?

[Glenn Pope]

Have the users save their own workspace in the Custom.cui that is set as the main CUI. In this CUI the user can create their own workspace. Showing only the toolbars they want. The Enterprise CUI can contain default workspaces the user can change and save to there own CUI.

[jrebennack]

OK... That brings up another questions...

Could I transfer the Workspaces from the land.cui, survey.cui, and civil.cui files into a custom.cui file and delete the workspaces from the land.cui, survey.cui, and civil.cui files? Using batch files, I know I can seed files into client installs.

[jpaulsen]

You can transfer workspaces (edit: using the CUI editor) but I would not recommend it.

When you transfer a workspace from one cui to another all the commands are also transfered. If you leave them in the original cui (land, acad, etc) they will still be accessible to the users. If the user wants their workspace to be similar to one of the original workspaces they can restore the original, make changes, then save it with a different name. The new workspace will be saved in the custom.cui if it is set as the main.

[ccowgill]

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.

Robert, in using this method, if you have 09, could you check to see if the block editor ribbon gets messed up and no longer works? I have custom.cui set as main, and our office as enterprise, with acad as a partial load. When I edit blocks in the block editor, the ribbon no longer functions, and I must use the keyboard to bsave and bclose.

Thanks,

[RobertB]

Robert, in using this method, if you have 09, could you check to see if the block editor ribbon gets messed up and no longer works? I have custom.cui set as main, and our office as enterprise, with acad as a partial load. When I edit blocks in the block editor, the ribbon no longer functions, and I must use the keyboard to bsave and bclose.

Christopher,
There are a few quirks, but the context ribbons work ok in most circumstances.

Here is what I've noted:

• Be sure to start AutoCAD with your desired profile. (Switching to another profile after AutoCAD has started can get the Ribbon goofed up.)
• Be sure your Office and User CUI files were started as blank CUI files and not started from the Custom.cui file.
• The Block Editor context ribbon can get stuck "on" in some cases, but a restart of AutoCAD fixes it.

[ccowgill]

Christopher,
There are a few quirks, but the context ribbons work ok in most circumstances.

Here is what I've noted:

• Be sure to start AutoCAD with your desired profile. (Switching to another profile after AutoCAD has started can get the Ribbon goofed up.)
• Be sure your Office and User CUI files were started as blank CUI files and not started from the Custom.cui file.
• The Block Editor context ribbon can get stuck "on" in some cases, but a restart of AutoCAD fixes it.

is it safe to transfer commands and ribbon tabs from my cui that was possibly created incorrectly, or is there risk of corrupting the new CUI, it is a real pain to have to recreate everything from scratch.

[RobertB]

is it safe to transfer commands and ribbon tabs from my cui that was possibly created incorrectly, or is there risk of corrupting the new CUI, it is a real pain to have to recreate everything from scratch.

Commands are ok. If you created/modified ribbon tab/panels in an unpatched version of AutoCAD 2009, I would recommend recreating the panels/tabs.

[ccowgill]

I have noticed one ill side effect of this process, any doubleclick edits defined in the main cui are overridden by doubleclick edits defined in partially loaded cui files. so if you want double click to open ddedit when double clicking on dimensions, you must set that up in the main cui file, not the enterprise.

[RobertB]

I have noticed one ill side effect of this process, any doubleclick edits defined in the main cui are overridden by doubleclick edits defined in partially loaded cui files. so if you want double click to open ddedit when double clicking on dimensions, you must set that up in the main cui file, not the enterprise.

It would be an ill effect if you don't want to allow users to customize double-clicks. However, we permit user created double-clicks in most cases.