PDA

View Full Version : Setting up Network CUI files in '06



nickeshaffer
2006-06-06, 07:54 PM
What we did, was I (as the head draftsman dude) created the first CUI file, then saved a copy into a certain folder on the network with each individual's name on it so they could personalize (to an extent) what i had created.

Does anyone have a better way of doing this?

thanks!

.T.
2006-06-06, 08:04 PM
Hi Nick,


THIS (http://forums.augi.com/showthread.php?t=18955)may be of some value to you.

sinc
2006-06-07, 03:15 PM
Yep, definitely check into Enterprise CUIs.

jpaulsen
2006-06-07, 04:15 PM
Tim and Sinc are pointing you in the right direction.

I would look at a combination of cui's. Set the default AutoCAD cui (or vertical) as the enterprise and the custom.cui as the main. Any customizations that your users do will be saved in the main cui.

This type of setup makes upgrading a lot easier since your user's customizations are in one location.

Ken Cover
2006-06-13, 05:40 PM
I made a standard cui for the Company to use as my enterprise. Then I loaded submenus into that such as ACAD, Express, and other standard menus that everyone uses.

For the main menu, I used what you described for each individual because there are some menus that one department uses that others do not use. This helped with the engineers messing with the ACAD menu file. It has also made the transition from 2006 to 2007 very easy.

Hope this helps,
Ken

sinc
2006-06-14, 09:12 PM
For the main menu, I used what you described for each individual because there are some menus that one department uses that others do not use. This helped with the engineers messing with the ACAD menu file.

If all you are worried about is which menus are displayed on screen, that can be handled via workspaces.

Otherwise, I suspect you would be better-served with a slightly different arrangement. The whole point of having a Main CUI and Enterprise CUIs is that the Main can be customized by the individual user. So you should not create any company-wide presets there (at least in theory - in practice, it may not work, as I'll get to in a moment...).

If you have any company-wide customizations, they should go in your Company.CUI file. If you have different departments with different demands, you can create several of these, say Company1.CUI, Company2.CUI, Company3.CUI, etc. These files will be loaded as PARTIAL CUIs, inside your Enterprise CUI.

Now create the Enterprise CUI. If you use a vertical, start with a copy of the CUI for the vertical. For example, I use LDD, so I'll make a copy of the Land.CUI and call it Company-Land.CUI (where "Company" is actually the name of my company).

In the end, users configure Autocad as follows:

Main CUI:
User.cui (Custom.cui)

Enterprise CUI:
Company-Land.cui
-- ACAD.cui (or ACMAP)
-- EXPRESS.cui
-- CIVIL DESIGN.cui
-- COMPANY.cui

The CUI files preceded by dashes are loaded as partial CUI files in the Enterprise CUI.

Now say you have two different departments. Let's assume both departments should get the custom routines provided in your COMPANY.cui file. But only Department A should get the commands in the COMPANY-A.cui file, and only Department B should get the commands in the COMPANY-B.cui file. In this case, all users still use the User.cui file as their Main CUI file. But for Department A, they should use the DEPT-A.cui file as the Enterprise, and the Department B should use a DEPT-B.cui file. They each have different partials, as follows:

Enterprise CUI for Department A:
DEPT-A.cui
-- ACAD.cui
-- EXPRESS.cui
-- COMPANY.cui
-- COMPANY-A.cui

Enterprise CUI for Department B:
DEPT-B.cui
-- ACAD.cui
-- EXPRESS.cui
-- COMPANY.cui
-- COMPANY-B.cui

This goes a long way toward defeating the whole point of having an Enterprise CUI for everything that should be Read-Only to your users, but it keeps the CUI editor from crashing on Unresolved Reference errors.

The problem with this setup is that if you make any changes in your DEPT-A.cui, and you want the same changes made in your DEPT-B.cui, you must make the same changes in both places. This is something that Autodesk does not seem to have thought through. The same basic problem occurs for any user who uses two different vertical products from Autodesk. Each vertical product requires a different Enterprise CUI, similar to the way each department would need a different Enterprise CUI. If you use more than one vertical and want to change something in the Enterprise CUI for all users, you must make the same change in the Enterprise CUI for each vertical.

Now for the caveats. First, the CUI in 2006 was really buggy, almost unusable. One of the big problems is Unresolved Reference errors. These often occur when you create a Workspace in your Main CUI (the User.cui, e.g. Custom.cui), but all the commands are defined in partials that are loaded in your Enterprise CUI. You can get around this by also including all the partials in the Main CUI. That means that, in 2006, the first example above would look like this instead:

Main CUI:
User.cui (Custom.cui)
-- ACAD.cui (or ACMAP)
-- EXPRESS.cui
-- CIVIL DESIGN.cui
-- COMPANY.cui

Enterprise CUI:
Company-Land.cui
-- ACAD.cui (or ACMAP)
-- EXPRESS.cui
-- CIVIL DESIGN.cui
-- COMPANY.cui

Another caveat is that the load order of Partial CUIs matters, and different CUIs can "clobber" each other. For example, there is a serious problem where the only shortcut menus that you get are the ones loaded in the last CUI menu. So you can't put all your company-wide custom shortcut menus in the Enterprise CUI, while the user has custom ones in the User.cui file. This is really annoying, and blows the whole thing I described at the beginning, where all company-wide presets go in the Enterprise CUI. If you want your users to be able to create custom shortcuts, you need to move ALL the shortcut definitions out of ACAD.cui and into the USER.cui. This means that if you do this, and ever want to make a change to your company-wide shortcut menus, you must change EVERY SINGLE USER CUI. It's really annoying.

FWIW, they improved the CUI in 2007 by quite a bit. It still has issues, but not as many, and it doesn't crash anywhere near as often.