Notes on the philosophy of CUI

[Anonymous]

Most of us used to use Acad.mns as the root of our menu structure, and then
MenuLoad (partial) the rest of our menus. So this was the structure:

-Acad.mns
--Express.mns
--Custom.mns
--Office.mns

However, the CUI has flipped our tidy lives. And the tendency is to try to
shoehorn the CUI into how we've always done things. I propose an
alternative, taking advantage of the Enterprise CUI in the process.

It is no longer necessary to make Acad.cui the root of structure. Think
about it; we did that before so that we could always insure that at least
Acad's menu structure was there. But CUI does some undesired things if you
continue this approach. More will be said on that later. 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

Why?

> Well, the Custom.cui can be modified by the user to their heart's content
> in most shops. So that's a good starting place. As CAD Managers we don't
> want the users mucking with the Acad.cui, but if you leave it as the main
> .cui file, it is going to get mucked up.

> With the Custom.cui as the main .cui file, the users can make their own
> workspaces, and stand a reasonable chance that their customizations make
> the next round of hardware/software upgrades. Far easier to backup/migrate
> the user's Custom.cui, IMHO, than worrying about a mucked up Acad.cui
> file.

> Making the Office.cui the Enterprise .cui file is an obvious choice. It
> will be read-only inside AutoCAD to the users, and any workspaces defined
> in the Office.cui are available to the user.

> If you need to run a test environment, say, a "vanilla" AutoCAD profile,
> and your normal profile, you are actually forced (!) not to use Acad.cui
> as you main .cui file. The reason for this is that you need the Acad.cui
> to be the main .cui file for the vanilla profile, but if you leave the
> Acad.cui as the main .cui file in your normal profile, changes you make to
> the CUI will be evident in the vanilla profile. The largest visible effect
> is that your Custom/Office.mnl files will execute in the vanilla profile,
> since the Custom/Office.cui files are MenuLoaded in the main Acad.cui
> file. This will "pollute" the Visual LISP environment in your nominally
> vanilla profile.

> And speaking of profiles, as a CAD Manager you can setup another profile
> that makes the Office.cui the main .cui file so that you, the CAD Manager,
> can edit the file!

I hope that this post helps you in your efforts with the CUI.


--
R. Robert Bell

[Anonymous]

With this discussion (editing the acad menu) it is really a matter of preference and opinion.
If you have a CAD guy that takes advantage of customizing often, then I would steer him towards using a custom menu or cui file. Most people I worked with do not take the initiative to learn to do that, unfortunately. They may add a button here and there but nothing major.

When we first installed 2006, we backed up the acad.cui file.
So, if the user were to leave or move out of CAD and another person inherited their machine, I would simply over ride the existing acad.cui with the original and they are up and running.

That is probably also why Autodesk has the acad.cui as main to start and they have the default CAD Workspace as well.

Mark

[Anonymous]

Aside from migrating cui's, plotters, plotstyles, and folder paths, could we also get it to migrate settings in the options menu as well. I.e. right-click options, background color, default plot to file location, lisp startup suite (though less an issue with the cui editor). I think these settings are things that we each hate looking for and resetting.

[Anonymous]

Yes,

All (or most) of those things get saved with your profile.
So, Make sure you name your profile. If you never created a new one, you can just name your current one, then export it out to somewhere safe. When you go to the next version, or even if you have to reinstall, on your machine only, you should be able to import this profile and be up and running.

Toolbar and pulldown menu locations use to be stored with the profile but now Autodesk has introduced workspaces. The workspaces will come in with your cui files. Make sure you back then up as well

Mark

Mark

[Steve_Johnson]

Bud , heloooooo! Anyone hoooooome? 🙂

I get the feeling you're not answering specific questions about what migration will mean because you guys have no idea yourselves yet. Tell me I'm wrong, please!

[Anonymous]

One other thing that is very important to remember and AutoDesk does not mention is backing up.

They package a custom.cui file with 2006 but all of the support files, including the custom.cui file are now loaded to C:

So, you have a coworker that sees 2006 and says, WOW, I can handle customizing in this version, they get into months of work, assuming that some IT guy has them backed up and BAM, their hard drive or OS goes. And with it is months of work.

Now, guess who they look at? You got it, The CAD Manager.


Mark

[Anonymous]

So my understanding is I want a Main CUI that points to Custom.CUI in the user's Docuements & Settings labrynth, and an Enterprise CUI that points at Office.CUI on the network, which then partial loads Acad.CUI and Acetmain.CUI. My Office.CUI also contains the pulldown menus from Acad.CUI.
However, when I make my Office.CUI with partially loaded Acad.CUi and Acetmain.CUI the Enterprise CUI, and Custom.CUI (with nothing at this point) my Main CUI, I also get no Acad pulldowns. I get the pulldowns from the actual Office.CUI, but not any of the pulldowns from the partially loaded stuff.

Any suggestions?
Best,
Gordon

[Anonymous]

Hi Steve,

It's been really busy lately and on top of that I am trying to rehabilitate
my self from the broken hip. So my days are very long and I don't have as
much time as I would like to get into the News Groups. So I'm not ignoring
anyone, just really busy.

I'm not sure what your asking here, I already posted to you how Migration
works. It's an existing feature that has been around since AutoCAD 2005 and
we talked to hundreds of sites about what and how they wanted it to work.
We spent over 6 months researching what needed to go into the feature before
we started programming it. So there is not really anything to explain
here, it's implemented and used by lots of sites. I even did a class on it
at AU last year. And I'm doing one on it again this year.

As far as what will change in the future you know we are not allowed to talk
about unreleased features and how they will work. This has been the case
for many years now, including way back when both you and I were TMs on
CompuServe in the Pre R14 days.;-).

Thanks.

Bud who is off to the Gym to ride the bike. I really want to walk again
;-)...


wrote in message news:4858399@discussion.autodesk.com...
Bud , heloooooo! Anyone hoooooome? 🙂

I get the feeling you're not answering specific questions about what
migration will mean because you guys have no idea yourselves yet. Tell me
I'm wrong, please!

[Steve_Johnson]

Bud - Sorry to bother you, particularly with your busyness and hip and everything, but you did ask for feedback, I gave some, and it was kind of left hanging with some unanswered questions...

Sorry, but you've only given the vaguest of ideas about how the migration will work. Yes, I'm very familiar with the general way migration has worked in the past couple of releases. CUI migration is a whole new ballgame, given the extensive list of complications I described. To narrow it down, I gave you a specific example situation and asked very specific questions about how migration would be expected to handle it. So yes, there certainly *is* something to explain.

As you're well aware, many people are struggling with the new CUI world, and trying in the face of a half-baked implementation, poor documentation, design faults and bugs to set things up in a way that will work well into the future. The primary reason Autodesk has given for inflicting this new system on us is migration. But we're not being given any but the most nebulous of ideas about exactly what that means! The devil's in the details, and we don't have any.

If you don't have the authority or the time to describe what migration will do in a year's time to the systems we're setting up now, then please, please, ask somebody who does. Leaving us struggling in the dark like this is really not nice.

Bud, nothing personal, and I wish you all the best with your recovery.

[Anonymous]

Hi Gordon

The way I have tackled it is to have The Acad.cui file as the Main Customization File with the partials loaded into it. On the users machines, have them mapped to the office cui as enterprise. As enterprise, they will have Read-Only access to the office menu and be able to do their customizations in the acad.cui file (main).

Now, when you want to edit the office cui file, you must map to it as the main customization file.
The way I handled it was to have 2 profiles, one with acad.cui as main, office as enterprise (same as the users) and another profile with the office as main (so I customize when necessary) and acad.cui as enterprise so that I can still use the acad menus while customizing the office cui file.

Now, the reason you are seeing and not seeing pulldowns lies in the new workspace feature. If you type cui at the command line, you will see that The acad.cui file has a Default Workspace; If you right click on it (I would make a copy of and rename that one for all users), you can then turn on and off toolbars (in that workspace) and move pulldowns around etc.

Every cui file must have a workspace before you can customize it. Remember the toolbar and pulldown menu locations etc no longer lie with the profile, they are held in the workspace itself.

Hope this helps?

Mark

[Anonymous]

Gordon

After you right click on the workspace, you can choose customize workspace. They (workspaces) are a little weird at first but once you start really understanding them, they make a lot of sense

Mark

[Anonymous]

Use a workspace to set up your "standard" environment, including pulldown
menus. I've used one called "MW Default" which is made active every time
AutoCAD starts up.

--
R. Robert Bell


wrote in message news:4859344@discussion.autodesk.com...
So my understanding is I want a Main CUI that points to Custom.CUI in the
user's Docuements & Settings labrynth, and an Enterprise CUI that points at
Office.CUI on the network, which then partial loads Acad.CUI and
Acetmain.CUI. My Office.CUI also contains the pulldown menus from Acad.CUI.
However, when I make my Office.CUI with partially loaded Acad.CUi and
Acetmain.CUI the Enterprise CUI, and Custom.CUI (with nothing at this point)
my Main CUI, I also get no Acad pulldowns. I get the pulldowns from the
actual Office.CUI, but not any of the pulldowns from the partially loaded
stuff.

Any suggestions?
Best,
Gordon

[Anonymous]

That's correct

You will need one for every cui file you intend to modify but within each cui file, you can have many workspaces.
I have one called My CAD Workspace and one called 3D

Out of curiosity, how did you get that profile to go active when AutoCAD started? LISP or VBA?
I could use a drawing open event in VBA I suppose

Mark

[Anonymous]

A (setvar) statement in Acad.lsp. That way, at the start of a session they
get the default, but they are going to work on HVAC the rest of the day, in
multiple drawings, I'm not forcing the default on them after that (as
opposed to AcadDoc.lsp or an event handler as you surmise).

--
R. Robert Bell


wrote in message news:4861106@discussion.autodesk.com...
That's correct

You will need one for every cui file you intend to modify but within each
cui file, you can have many workspaces.
I have one called My CAD Workspace and one called 3D

Out of curiosity, how did you get that profile to go active when AutoCAD
started? LISP or VBA?
I could use a drawing open event in VBA I suppose

Mark

[Anonymous]

Robert,

Do you use multiple profiles?
I have a profile with The ACad.cui file as main with our Office.cui file as Enterprise, and I have another with our ofice.cui file as main (so that I can modify it when necessary) and Acad.cui as enterprise.

Anyhow, I use 2 VBA macros to switch between the two.
Near the end of each macro, I use a send command to the commandline to tell AutoCAD which profile to make active.
Then at the very end of each macro, I use the variable cprofile so that I can get confirmation at the command line that I have the right profile.

[Anonymous]

Correction:

The sendcommand I use tells AutoCAD which Workspace to make active. That is after the profile has been made active by The VBA Module. If you are interested, I would be glad to share it with you.

Mark

[Anonymous]

Thanks for the offer, but I don't need it. The only profile switching I do
is for the rare enterprise menu edit. Our users never switch profiles. Upon
deployment, the desktop icon is configured to use the profile switch for the
user's profile. So they never even need to think about what profile is
loaded.


--
R. Robert Bell


wrote in message news:4861627@discussion.autodesk.com...
Correction:

The sendcommand I use tells AutoCAD which Workspace to make active. That is
after the profile has been made active by The VBA Module. If you are
interested, I would be glad to share it with you.

Mark

[Anonymous]

I understand. Users here never need to switch profiles either.
I created the macros because I was editing the enterprise cui file quite a bit. I was bummed out when I saw that the Customization File paths and workspaces were not included in the VBA object model for 2006. I would prefer to have one macro that switches my office cui file to main when needed as opposed to multiple profiles but no such luck, may be next version.

Mark

[Anonymous]

Robert,

Speaking of profiles.

We have several work stations on a network, each with an installation of AutoCAD R2005.

Each work station may be used by 2 or 3 different users that have different job descriptions during a 24 hr period.

The way that we are now handling this now:
I have created a separate username.mns for each user.
At startup, I have a lisp that checks for each users profile.
So each one works off their own menu and profile.
They never switch profiles.


Help me out here. If I want to change over to R2006, what hurdles are we looking at.

I understand that the profiles are now workspaces and the menus are now the .CUI's (at least I think I do).

TIA

Bill

[Anonymous]

Ahhhh,

We have now gone full circle. Every thing I have been discussing with you is absolutely relevant to 2006.
In customization there will be some challenging hurdles but have adapted and you will also.

Robert I and others have created many posts in this particular forum. If you start from the top and read down, I think you will learn a wealth of info on 2006.

After you have read through, please write back, I will be glad to answer any other questions you may have.
After you get started with 2006, I think our whole discussion of profiles will have a whole new meaning as well.

Look forward to hearing from you.

Mark

[Anonymous]

Your understanding is incorrect. Profiles are still profiles and play the
usual important role.

Workspaces are _saved user interface settings_. This includes what is
displayed on the menu bar, toolbar visibility _and_ position, and more.

The cui files are MTNG (Menus, The Next Generation). Mns/Mnu files will be
migrated to the cui format when they are 1st loaded.

As for the proposed structure, I would recommend:

UserName.cui (Main)
OfficeStd.cui (Enterprise)
---Acad.cui (partial cui to enterprise)
---AcETMain.cui (partial cui to enterprise)

Note that the mouse buttons bug means that the mouse items need to be
located in the UserName.cui at the moment. I will post later if I find a way
to _reliably_ include the mouse items after a cui has been created/modified.
(Copy and paste of the xml ought to work, but I won't recommend that until
thoroughly tested.)

R. Robert Bell


wrote in message news:4861769@discussion.autodesk.com...
Robert,

Speaking of profiles.

We have several work stations on a network, each with an installation of
AutoCAD R2005.

Each work station may be used by 2 or 3 different users that have different
job descriptions during a 24 hr period.

The way that we are now handling this now:
I have created a separate username.mns for each user.
At startup, I have a lisp that checks for each users profile.
So each one works off their own menu and profile.
They never switch profiles.


Help me out here. If I want to change over to R2006, what hurdles are we
looking at.

I understand that the profiles are now workspaces and the menus are now the
.CUI's (at least I think I do).