PDA

View Full Version : Enterprise CUI's - What's the advantage



pmedina
2005-04-18, 04:53 PM
I have been involved in menu customization for my company. Our company menu is out on a network location where cad users have read-only access. It has worked well for us.

So in this case is there some advantage to using an Enterprise type of cui, since our users can't change it anyway?

Since the Enterprise type of cui is something new, I'm trying to make sense of it.

Thanks

Robert.Hall
2005-04-18, 08:38 PM
It works great for when multiple cad users are assigned to the same directory on the network. One person sets up the CUI and has sole rights to make changes. This would be a scenario where users are in a shared drive where Read Only access is not set.

pmedina
2005-04-19, 03:38 PM
Thanks.
So, my interpretation is that the Enterprise CUI security is a bit redundant (in our case) since our users don't have write access anyway.
...Any other comments?

Robert.Hall
2005-04-19, 04:57 PM
Now if we were talking about dynamic block editting........keep it so one person has
access to editing so that the block library doesn't get messed up due to several people making multiple changes.

stilesj
2005-05-04, 06:57 PM
I could see one advantage being if you wanted them to have a customizable area, so they could create their own workspaces using the main cui and have yours locked down as the enterprise one. But I'm still trying to figure this out myself (I think I have a similar setup to you), so I would love to hear what you've been trying and if anything has worked/not worked for you.

pmedina
2005-05-05, 12:26 AM
This is what we've settled on.
We will set our company cui as the enterprise one so that it cannot be edited. Leaving the acad.cui as the main one that can be edited. We will have a backup copy, in case the user messes it up. We'd rather allow that, than have them mess up our company standard menu.

The real reason it cannot be edited in our case, is that its called from a network drive, which is read only to our users. I call this the 'real' reason because a user can edit it if he has access rights by switching it out of the enterprise mode.

Another advantage, we found out, is that you can deploy the enterprise cui during installation. In our case, where we have many cad users, they won't have to learn how to get our menu to show up. It will be there as soon as they fire up acad for the first time! That's a big plus for us.

The real disadvantage with the changeover to the cui format is that we could not find a good explanation of how to set things up. The acad help was not enough. We had to use more of a trial-and-error technique to figure it all out.

In previous releases, we had several independent department menus, which a user would import using a profile (arg file type) for their department. We merged them all into a single cui because we think a lot of effort would be involved in training our users how to get our company and their department menus to show up. Using a profile now does not work for us. One thing is that the new "workspaces" do not come in. By having just a single company menu we are able to create department workspaces & have the company and department menus and toolbars show up. When I say we merged them all, it does not mean several menus cannot exist. You can have several menus in the one cui. The only thing is you have to have control over who is allowed to edit the cui.

Additionally, if a workspace comes in with your deployed enterprise cui, it too will be read only. This is a plus in our case, since the user can always recall the original workspace we set up for them. After opening up their department's workspace, the user can set up their toolbars, etc. and then save it as their own named workspace. That's why I've named the enterprise cui's workspaces as "Default Aviation" "Default Electrical", etc.

Hope the information helps.

P.S. Maybe someone should add cui to the spell checker. It sure is nice to have the spell checker. Thanks!