Notes on the philosophy of CUI

[Glenn Pope]

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

Good idea. This thread is now sticky.

[Birdy]

Awesomely helpful thread. Thanks. Coupla questions:
We just got on subscription (up from 2004) so's I'm lookin at this CUI implementation process.

My idea is:
-custom.cui (main)
-office.cui (enterprise)
-acad.cui (partial in office)
-acetamain.cui (partial in office)

office.cui will reside on the network drive, and custom.cui on each users (default acad) support path.
> Where should acad.cui and acetamain.cui reside?
> Will there be conflicts if they're on a local drive?
> What if there's one on the network and one local?
> Would it be better (for future migration) to have each custom.cui in a user folder on the network?

I'll add a profile on my machine called "EDITOFFICECUI" with
-office.cui (main)
-acad.cui (partial in office)
-acetamain.cui (partial in office)
for management purposes. This seems to make sense.

Robert, still soaking in your "What to Do with the New CUI" AU handout. Wish I'dve taken the class. Good stuff. Succinct even!

Currently, we autoload all LISP files, have all .ctb files, .dwt files, .dws files, all block libraries, etc, located on the network (read only, 'cept for me).
> Am I missing anything critical?
> It can't be this easy, can it?

TIA

[Glenn Pope]

office.cui will reside on the network drive, and custom.cui on each users (default acad) support path.
> Where should acad.cui and acetamain.cui reside?
> Will there be conflicts if they're on a local drive?
> What if there's one on the network and one local?
> Would it be better (for future migration) to have each custom.cui in a user folder on the network?

You can have the acad.cui and acetamain.cui on the network or local drive. If they are on the local drive just make sure that everyones install is the same. Can cause some problems if the office.cui as acad.cui attached from C: but one users has acad.cui on D:. Having the CUIs on the network eliminates that.

I am assuming about your conflicts question that you are asking if you using the CUIs on the network but also have the CUIs on the local drive that were placed during the install. If so, then no there shouldn't be any conflicts.

I would place each custom.cui file somewhere other then the default install location. I use a place that is common for all machines so its setup with the profile and I don't have to path each individual computer.

In the past I have created a Folder on C: called Acad and placed all custom files there. You can have the user back this folder up on the network. One place I worked for gave each employee their own H: drive on the network. I used the same concept as before but just placed in on the H: drive instead.

[Birdy]

You can have the acad.cui and acetamain.cui on the network or local drive. If they are on the local drive just make sure that everyones install is the same. Can cause some problems if the office.cui as acad.cui attached from C: but one users has acad.cui on D:. Having the CUIs on the network eliminates that.

Thanks. I already got started with this and put 'em on the network. Seemed like a better idea.

I am assuming about your conflicts question that you are asking if you using the CUIs on the network but also have the CUIs on the local drive that were placed during the install. If so, then no there shouldn't be any conflicts.

That's part of it. The other part is a local .cui loaded as a partial in a network (enterprise) .cui. I guess, like above, it's a non-issue if acad & acetmain are loaded from the network. That's the route I went.

I would place each custom.cui file somewhere other then the default install location. I use a place that is common for all machines so its setup with the profile and I don't have to path each individual computer.

Yeah, I agree. Same as we been doing before with custom files of any type to protect them when upgrading or (shudder) reinstalling.

In the past I have created a Folder on C: called Acad and placed all custom files there. You can have the user back this folder up on the network. One place I worked for gave each employee their own H: drive on the network. I used the same concept as before but just placed in on the H: drive instead.

Doing this also, we are.

Thanks Glenn

[RobertB]

Awesomely helpful thread. Thanks. Coupla questions:
...
Robert, still soaking in your "What to Do with the New CUI" AU handout. Wish I'dve taken the class. Good stuff. Succinct even!

Currently, we autoload all LISP files, have all .ctb files, .dwt files, .dws files, all block libraries, etc, located on the network (read only, 'cept for me).
> Am I missing anything critical?
> It can't be this easy, can it?

TIA

Thanks! Actually, it can be easy, as long as you work with the new scheme, instead of trying to force-fit it into some old way of working. The biggest change I made was to dump menu swapping and to use workspaces to affect the interface instead.

[jorgeledezma]

What Caracas has to do with this?

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.

[RobertB]

What Caracas has to do with this?

I do not understand what you are asking.

[jpaulsen]

I have been planning to implement the Enterprise CUI ever since AU. I've had it all planned out for months and thought I knew exactly what I was going to do. I finally had some time to set it up but the Unresolved problem is throwing a monkey wrench in the works.

All CUIs are on the network in a read-only folder except the User.cui. The User.cui is on the network on a user drive. Every employee has a user drive and has modify permissions.

The AutoCAD support file search path is such that it finds the CUI on the network before the local drive. I think this may be important because I believe partials are loaded based on the search path.

Here was my original plan:

For Land Enabled Map
-User.cui (main)
-Acmap.cui (enterprise)
--Express
--JR (company)
--Rasterdesign

For Land Desktop
-User.cui (main)
-Land.cui (enterprise)
--Acmap
--Civildesign
--Survey
--Express
--JR (company)
--Rasterdesign

In theory this should have worked just fine. However, when you look at the workspace contents all CUI items from partial menus show as unresolved.

I changed my setup based on a post from Robert Bell but I think I must have misunderstood him because it only made things worse. I made my company CUI the enterprise and partially loaded the others.

For Land Enabled Map (modified)
-User.cui (main)
-JR.cui (enterprise)
--Acmap
--Express
--Rasterdesign

Since I am using a vertical and cannot load the Land, Civildesign or Survey CUIs in Land Enabled Map this would not have been a permanent solution for me anyway. I just wanted to try it.

With this scenario I just created more unresolved items since the Acmap.cui was also partially loaded. As I stated earlier any items from a partial loaded CUI show as unresolved.

I don't quite understand this error / message. To me unresolved means it cannot be found but the toolbar / menu shows in AutoCAD. I can turn it on and off in the CUI when I customize my workspaces. It is definitely not missing. AutoCAD knows exactly where it is but just doesn't know how to name it in the CUI editor.

So my questions are:

What causes the unresolved error / message?

Did I misunderstand Robert when I created my modified configuration?

How do I get rid of this error / message?

Can a path be specified for a partially loaded CUI or does it just load the first one found in the search path?

[mcoffman]

I've got some questions regarding the behavior of the ACAD.cui when configured as partial vs. main cui.

I had the ACAD.cui loaded as a partial cui and lost the workspace toolbar as well as the recent files portion of the file pull down menu. Any ideas on why this would be happening? When I reloaded it as the main cui those features returned.

Another question regards the custom.cui. When I set it up as the main.cui w/ acad being a partial, the above issues occured. However, when ACAD was the main and custom the partial, changes made to the ACAD cui were copied to the custom. Not sure what exactly is going on there.

My goal in this is to set up a custom cui local to the users computers in my office and then have a enterprise cui that has acad and some other office cui's as partials under it. I just want to make sure that all functionality will remain.

I hope all that makes sense as it's still fairly early in the morning.

Thanks,
MC

[RobertB]

You will not be able to use the same user.cui file for each vertical. You will need separate cui files that rely on vertical-only cui files. Getting rid of the unresolved items is a whole other issue. You will probably need to rebuild the workspaces to getrid of them.