Notes on the philosophy of CUI

[RobertB]

Hmm, possibly, but there is a lot to be considered first. Help states that it has to be in a shared network location. If that were true, it would kill the idea right away. Is Help correct?

No, it does not [ihave[/i] to be in a network location. I'm doing my editing/testing on a laptop with only local files.

Yes, having a standard workspace to fall back on would be handy, although very rarely used. However, in my environment I could do that in 2006 without using Enterprise files. If the canonical OfficeMain.cui gets copied from the server as part of our normal update mechanism, is will bring its virgin workspace(s) with it. However, I can see the benefit of preventing users from mangling them in the first place.

Not just one standard workspace, rather, all the discipline toggling workspaces also!

I don't think that would work. We have 13 discipline menus at the moment. Users can have 0, 1, 2 or whatever of these menus open at any time, to suit the mix of drawing types that they're dealing with. It would be a practical impossibility to provide workspaces for all of the combinations.

I understand that comment. We are an MEP (I think you are too) and the Mechanical group might have HVAC, Hydronics, and Plumbing up at the same time, or maybe just HVAC. I prefer the KISS method. I'll give them the all menus/toolbars they need for the Mechanical workspace rather than make them toggle from HVAC to Plumbing to Hydronics workspaces.

Also, wouldn't a user choosing an office-provided workspace have all their carefully placed toolbars messed up?

<Hmm> I don't know. Items in the main .cui file should not be controlled by the enterprise workspaces, but I haven't tested that yet.

OK, if you say so. How do I programatically detect the presence or abscence of a partial menu in the "new way"?

<Booming spectral voice mode ON>Of course I say so!<Booming spectral voice mode OFF>
Let workspaces do the work. Examine the WSCurrent system variable. I'm serious here.

Steve, how many times in the past have we "battled" a change in AutoCAD for a few releases because it didn't work the way we were used to. I'm thinking plotting here, but the concept is the same. When the AutoCAD 2000 plot engine was released, many firms tried to shoehorn the new engine into how they always plotted in the past. With grief and frustration. When we migrated from R14 to 2000, I simply dropped how we plotted in the past, and wrote stuff to accommodate the new engine. And we had far less issues than many firms. It is the same with the CUI. You said workspaces "won't work for you because...", but are you working with the new approach, or fighting against it? I'm not saying you are right or wrong. Just consider using workspaces to do the work for you.

OK, I don't think that would work either. I repeat, "The various OfficeDiscipline menus are separate for ease of maintenance. This allows me to modify them without forcing every user to have their OfficeMain menu updated." The logical reasons for keeping them apart appear to be unchanged: I would prefer not to wade through a huge menu file if I can avoid it, especially using the painfully slow CUI interface. Also, as cui files are much bigger than mn* files, the practical reason for keeping them apart has just multiplied, rather than reduced. I wouldn't want to inflict a large-file WAN transfer on all my users, when I'm just modifying a discipline-specific menu for a handful of them.

Point taken. Note that items listed in the enterprise .cui under the MenuLoad section will appear readonly to the users. So you could still use the multiple file approach if you need to. Personally, I feel that it is more work that way, but you have valid reasons. Personally, I use syncing software to push updates to other servers across the WAN after-hours, but you seem uncomfortable with the servers (too bad).

Please note that I'm not being deliberately argumentative, I'm just trying to work through all the implications of doing things, as they apply to my environment.

I didn't take it that way. But thanks for saying it anyway!

[RobertB]

I want to highlight I point I made in the initial post for emphasis. Please
see below.

... Instead, I recommend making Custom.cui the main .cui file, and your Office.cui the Enterprise .cui file.

-Custom.cui (Main)
-Office.cui (Enterprise)
--Acad
--Express

Please note that this diagram indicates that Acad.cui and AcetMain.cui
(Express) are menuloaded as partial CUI files in the enterprise .cui file!
This is a critical point. When you have those as partial files you can
easily maintain your workspaces for the enterprise .cui file. Otherwise, you
are going to run into unresolved references with workspaces.

If you assign those partial .cui files from your Windows profile location
the location will resolve correctly for your users. IOW, AutoCAD won't
look for Acad.cui under your login name, rather, will use the user's
Acad.cui in their support folder.

[Mike.Perry]

Hi

Link "AutoCAD 2006 Tutorial Videos" (third from bottom as of 11th May 12:43 AM GMT) in this post might prove to be helpful / useful to someone...

Have a good one, Mike

[Steve Johnson]

No, it does not [ihave[/i] to be in a network location. I'm doing my editing/testing on a laptop with only local files.

Thanks. Joy! Joy! Help is lying!

We are an MEP (I think you are too)

I might be, but I have no idea what the MEP TLA stands for. Multi Enterprise Place? Massively Enormous Pe... maybe not.

<Hmm> I don't know. Items in the main .cui file should not be controlled by the enterprise workspaces, but I haven't tested that yet.

The users will have arranged their stuff (a tiny bit of it from the main User.cui, most of it from OfficeMain.cui) as they see fit. I don't want to mess that up when all they want is an extra pull-down inserted. Maybe I'm misunderstanding how workspaces work? Is there such a thing as a "partial workspace" that only affects a small part of the user interface, while leaving the rest alone?

Let workspaces do the work. Examine the WSCurrent system variable. I'm serious here.

OK, I'll look.

Steve, how many times in the past have we "battled" a change in AutoCAD for a few releases because it didn't work the way we were used to. I'm thinking plotting here, but the concept is the same. When the AutoCAD 2000 plot engine was released, many firms tried to shoehorn the new engine into how they always plotted in the past. With grief and frustration. When we migrated from R14 to 2000, I simply dropped how we plotted in the past, and wrote stuff to accommodate the new engine. And we had far less issues than many firms. It is the same with the CUI. You said workspaces "won't work for you because...", but are you working with the new approach, or fighting against it? I'm not saying you are right or wrong. Just consider using workspaces to do the work for you.

Well, I had a plotting system with 8 years development behind it that worked really well and the users knew and loved. I dropped it without regret when 2000 came along, so I don't have an inherent problem with change. I just want it to be a change for the better, or at least no worse. But I certainly need to learn more about workspaces before I can work out what is best.

Point taken. Note that items listed in the enterprise .cui under the MenuLoad section will appear readonly to the users. So you could still use the multiple file approach if you need to. Personally, I feel that it is more work that way, but you have valid reasons. Personally, I use syncing software to push updates to other servers across the WAN after-hours, but you seem uncomfortable with the servers (too bad).

It may be that combining all the Office* menus into one is the best solution for me, in which case syncing the local servers may be required. More stuff to look into.

[RobertB]

Workspaces will affect the whole layout of stuff, but with some planning the effect would seem to be only adding a pulldown.

P.S. MEP=Mechanical/Electrical/Plumbing design firm.

[Steve Johnson]

Any clues as to how I would do that planning? I've had a play with the CUI, implemented your basic structure, and made some workspaces, so I now have a basic understanding of how this stuff works.

If I enforced a rigid interface layout on my users, and if I only allowed one discipline menu to be loaded at a time, then I can see how it could be done. But neither is the case, so I'm clueless about how to comply with your suggestion. Unless you have some secret knowledge (quite possible!), it seems to me that switching workspaces to add a menu section or two is a sledgehammer / nut approach. It looks like the wrong tool for the job to me, but I'm ready to be convinced otherwise.

MEP: ah, I see. Sort of. Among other things*, I manage the AutoCAD for the Water Corporation of Western Australia, which is a state the size of Western Europe. We do those kind of drawings and lots more besides.

* Other things:
cad nauseam - http://www.users.bigpond.com/stevejohnson/
CADLock - http://www.cadlock.com/
Cadalyst - http://www.cadalyst.com/exclusive/

[RobertB]

Any clues as to how I would do that planning? I've had a play with the CUI, implemented your basic structure, and made some workspaces, so I now have a basic understanding of how this stuff works.

If I enforced a rigid interface layout on my users, and if I only allowed one discipline menu to be loaded at a time, then I can see how it could be done. But neither is the case, so I'm clueless about how to comply with your suggestion. Unless you have some secret knowledge (quite possible!), it seems to me that switching workspaces to add a menu section or two is a sledgehammer / nut approach. It looks like the wrong tool for the job to me, but I'm ready to be convinced otherwise.

Ah... that Steve Johnson! Good to be chatting with you.

What I might recommend is use Workspaces to switch disciplines, but provide a "control panel" toolbar to pop another discipline's menu up on the bar. You may even be able to keep the "poppers" on the menus. Granted, I haven't tested either method yet (only so many hours in a day), but menu swapping still works (Pop switching sample ).

[Steve Johnson]

Ah... that Steve Johnson!

There are others?

I've decided on my structure now, unless I learn something unexpected while I'm implementing it:

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

I'll keep the OfficeDiscipline menus apart, for the maintenance and performance reasons I already stated. However, I'll pre-load them under the OfficeMain menu so they are read-only. The standard workspace will have them loaded but not visible, and I'll provide menu items for turning them on and off.

Thank you for your advice. I didn't take all of it, only those bits that I think will work well here, but you've saved me a lot of fruitless messing about.

[jgratton]

I want to highlight I point I made in the initial post for emphasis. Please
see below.

Please note that this diagram indicates that Acad.cui and AcetMain.cui
(Express) are menuloaded as partial CUI files in the enterprise .cui file!
This is a critical point. When you have those as partial files you can
easily maintain your workspaces for the enterprise .cui file. Otherwise, you
are going to run into unresolved references with workspaces.

If you assign those partial .cui files from your Windows profile location
the location will resolve correctly for your users. IOW, AutoCAD won't
look for Acad.cui under your login name, rather, will use the user's
Acad.cui in their support folder.

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?

[Steve Johnson]

Set up two profiles: one as a user and one as a CAD manager. The user one is as Robert described, the manager one has the main and enterprise cui files reversed. While in "manager" mode, load your partial menus. This will put them under the main cui, which, when you are in "user" mode, will be the enterprise cui. You can open up the cui files in Notepad to see which partials are loaded under each main or enterprise cui.