Notes on the philosophy of CUI

[jgratton]

Thanks for the help, I did as you said and it worked. Now, does it matter which profile I use as current from which to load the inhouse developed menus? They should be loaded as partial menus under the enterprise cui?

[Steve Johnson]

If you want the users to have the ability to modify those inhouse menus, load them as a user. Otherwise, load them as a manager, so they are partial menus under the user's enterprise menu and are therefore read-only.

[RobertB]

I would like to know if I am interpreting this correctly. Are you saying that this diagram is incorrect and that Acad and Expess should appear as partial menus of Main and not Enterprise? I hope this is the case, because every time I attempt to put them as partials under enterprise, they appear under main instead. Is there some way to move them over or are the OK as is?

I see that Steve helped you (thanks Steve!) but I thought I'd post better pictures of what I stated in the initial post and the clarification post.

The Profiles.png file shows 3 profiles; "MW" for normal users, "MW CUI Edit" which is on my laptop only, and "Vanilla" which is just plain out-of-the-box AutoCAD.

The other two files show what the CUI editor looks like when you load one of the two MW profiles.

[jgratton]

If you want the users to have the ability to modify those inhouse menus, load them as a user. Otherwise, load them as a manager, so they are partial menus under the user's enterprise menu and are therefore read-only.

I carried on before you posted your reply, got so jumbled up (something to do with same menugroup names as I vaguely recall), at one point I had my custom menus appearing twice in the pulldowns) In my attempts to fix things, I ended up losing what I had gained. I started to notice the main cui seemed to change on its own back to acad. I took that as a sign and so I started again using Steve's proposed method of making acad the main menu and not having an enterprise cui. Sorry, Robert, your way may be good, but it was hard for me to do on my own without more hand holding. Guess there's still too much background knowledge I do not have and the information available assumes I already know it.

On the bright side I got my slides and some lisp working!!! It sure helps if you load apps and have all the correct pathing in the profile!!! Thanks for your patience, even if I sometimes lose mine.

[Steve Johnson]

I started again using Steve's proposed method of making acad the main menu and not having an enterprise cui.

Just to clarify, I didn't propose that method (unless you mean a different Steve, in which case, please ignore the rest of this post ). That's what I have in 2005 and below, but for 2006 I agree with the general thrust of Robert's suggestions. As noted some way above, here's what I intend doing:

-User (Main)
-OfficeMain (Enterprise)
--Acad
--Express
--OfficeDisciplineA
:
--OfficeDisciplineZ

So I do have an enterprise menu, and Acad is a partial menu of that enterprise menu.

[jgratton]

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)

This is what I was referring to, if you are not the author, sorry, my bad.

[Steve Johnson]

Yes, that's what I wrote, but I was describing the system I currently manage (i.e. a 2005 system), not the 2006 system I am designing and setting up. See later posts of mine for what I intend doing in 2006.

[RobertB]

This thread fails to take into account multiple verticals. In the posted scheme, Acad.cui resides off of the enterprise cui. Obviously you cannot attach multiple vertical's .cui files to the same enterprise cui or you will run into unresolved elements. <blech>

I have given this some thought over the last month and cannot come up with a scheme that I would be happy with. I guess I'm glad I don't need to support multiple verticals!

One of the issues that perplex me is that if you want to permit users to create and modify their own workspaces and add commands of their own, you really need to have custom.cui or the vertical's .cui as the main cui file. However, the user's will hate losing their work in one version of the main cui file when they switch to another vertical. <blech>

One approach at this point is to have unique custom for each vertical, and to partially load the vertical's cui into that custom.cui. In fact, Autodesk itself leans towards this (unintentionally?) by placing a Custom.cui in separate support folders for each vertical (e.g. I have both AutoCAD and ABS here, with two separate support folders). This means the user will need to transfer common commands between the multiple custom.cui files. Too bad, I guess.

I'm unhappy with that approach because the vertical's .cui is exposed to user abuse.

So the only other approach would be to have a "framework" enterprise cui that is unique to each vertical, and located on the server, that partially loads the true Office.cui and the vertical's .cui files. This "framework" cui file would hold the workspaces for that vertical. And the user could store their common cui commands in a .cui file that is partially loaded into the unique Custom.cui in each vertical's Support folder. Yeah, baby! (Too bad that's a lot of partial loads.)

[RobertB]

Or, as opposed to a "framework" cui, use the vertical's cui as the enterprise cui, and partial load the office.cui into that. However, that would mean either moving the vertical's cui up to a central location, or doing some tricky deployment.

[sinc]

This thread was pretty useful. It could use a bump. Maybe even sticky-worthy?