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]

Yes, anything customized in the main will be. So my last statement might not
be an issue. I was thinking of the enterprise .cui and upon reflection it
might not matter.

But the vanilla issue still exists.

--
R. Robert Bell


"Rick Moore" wrote in message
news:4842213@discussion.autodesk.com...
Interesting stuff, still trying to figure out how I want to handle this.
I was under the impression that anything customized in the main cui would be
migrated into the new one in the next release

[Anonymous]

I don't think that will matter Doug, as the Acad.cui is in each user's
profile.

What I don't want, is to bail out the user's that keep screwing up their
Acad.cui file. (Help, Bob, I've deleted all the toolbars and !)

--
R. Robert Bell


"Doug Bowers" wrote in message
news:4842184@discussion.autodesk.com...
As Robert says, it can be very important in some shops, including ours.
Since users will sometimes share computers, I don't want a user getting on a
computer and finding 3/4ths of the buttons missing from one of the standard
toolbars. I really want the default buttons to be available to all users on
a computer. If a person wants to remove half the buttons from a standard
toolbar, they can create a new personal toolbar that has their desired
buttons and just turn off the standard toolbar.

Using the Custom.cui as the Main allows this to happen.

Douglas Bowers, AIA
Director of CAD Technology
Bloodgood Sharp Buster Architects and Planners

[Anonymous]

Good point. I forgot that it is in the C:\Documents and
Settings\\Application Data\Autodesk\ADT 2006\R16.2\enu\Support
folder. I have been having it on the server so it never gets changed by the
users.

Your concern about bailing users out is very valid.

Doug

[Anonymous]

I am not seeing this occur. I have the same issues as Jimmy with the Pop0
menu.

When using the following structure, the Pop0 menu does not work:
-Custom.cui (Main)
-Office.cui (Enterprise)
--ADT (Partial under Enterprise)
----POP0
--Express (Partial under Enterprise)
--others (Partial under Enterprise)

When using the following structure, the Pop0 menu does work:
-Custom.cui (Main)
-ADT.cui (Enterprise)
----POP0
--Office.cui (Partial under Enterprise)
--Express (Partial under Enterprise)
--others (Partial under Enterprise)

I really like the idea of my office.cui being the Enterprise and just add in
the ADT.cui as a partial cui to the office.cui, but I just can't get the
Pop0 menu to work in this configuration. And that is not just during the
configuration time when I set my office.cui as Main. I know Robert said
that his problem with Pop0 went away when he made his office the Enterprise
after completing the configuration.

I don't really want to load the Pop0 into the Custom.cui as users won't do
that. I also had trouble get Pop0 to work if I copied the Pop0 from the
ADT.cui to the office.cui, where theoretically should have worked.

Is anyone else seeing this occur?

Thanks,
Douglas Bowers, AIA
Director of CAD Technology
Bloodgood Sharp Buster Architects and Planners.




"R. Robert Bell" wrote in message
news:4838548@discussion.autodesk.com...
Jimmy,

I don't have any items placed in my office's .cui file (yet). And I have
Acad.cui and Express.cui menuloaded into the office's .cui file. Please note
that *while I am editing* the office's .cui file (in my Edit CUI profile),
shortcut menus don't work.

However, as soon as I switch over to the normal office profile, where the
office's .cui is the enterprise .cui, the shortcut menu work fine, even
though they are _not_ placed in either the custom.cui or office's .cui
structure.

HTH

--
R. Robert Bell


"Jimmy Bergmark" wrote in message
news:4838436@discussion.autodesk.com...
Does anyone else get problem with "POP0 - Object Snap Cursor Menu" in a
setup like this?
If I press CTRL + right button on the mouse nothing happens.
-Custom.cui (Main)
-Office.cui (Enterprise)
--Acad
----POP0
--Express

--
Best Regards, Jimmy Bergmark
CAD and Database Developer Manager at www.pharmadule-emtunga.com
Blog: http://jtbworld.blogspot.com
JTB FlexReport (FLEXnet / FLEXlm report tool) -
http://www.jtbworld.com/jtbflexreport
SmartPurger (Purges automatically) -
http://www.jtbworld.com/?/smartpurger.htm
or download some freeware at http://www.jtbworld.com
More on AutoCAD 2005 and 2006
http://www.jtbworld.com/autocad2005.htm
http://www.jtbworld.com/autocad2006.htm


"R. Robert Bell" wrote in message
news:4838060@discussion.autodesk.com...
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]

Grr... don't need the Visual LISP code.

revised: The macro I provided was: $P0=ACAD.SNAP $p0=*


--
R. Robert Bell


"R. Robert Bell" wrote in message
news:4841784@discussion.autodesk.com...
James,

Here is how I did that.

Load your enterprise edit profile.
Add a new command. (I called mine "OSnap Menu")
The macro I provided was: (menucmd "POP0=ACAD.SNAP")(menucmd "POP0=*")
I changed the Element ID to fit my naming structure: MW_ShowSnap
Hit to save the new command.
Expand the Keyboard Shortcuts node for the MW.cui.
Expand the Shortcut Keys node.
Drag and drop the new "OSnap Menu" command into the Shortcut Keys node.
Edit the properties to use the F11 key.
Hit to save and exit the CUI dialog.

Test F11 now.

[Anonymous]

Are you using the menugroup name in the POP assignment? See my posts in this
thread dated 11 May 2005, 11:20AM on the Snap menu assignment. It might help
your issue.

--
R. Robert Bell


"Doug Bowers" wrote in message
news:4842772@discussion.autodesk.com...
I am not seeing this occur. I have the same issues as Jimmy with the Pop0
menu.

[Anonymous]

Hi Sage,

At this point I'd say yes, transfer the assignments and specify your ACAD
group in the assignment (e.g. $P0=ACAD.SNAP $P0=*). This seems to me the
most reliable solution. And besides, I don't think these button assignments
have changed for several releases, just the menus they reference.

Yes, I'm seeing the same thing as you. I entirely stripped mouse buttons
from main and enterprise, and acad buttons still did not work. So it looks
like it is best if they are defined at the enterprise level. However I have
also now seen what Robert described and even stranger things. So I'm not
real sure of much right now regarding the mouse buttons.

James


"Sage Cowsert" wrote in message
news:4841461@discussion.autodesk.com...
I'm trying out Roberts Method. I'd like ACAD.CUI to set the button
assignments. As I'm sure the next version of AutoCAD will change the
assignments and am ok with AutoCAD just doing it. I don't have any buttons
assigned under CUSTOM.CUI nor my enterprise CUI. ACAD.CUI is partially
loaded under the enterprise setup.

Configured like I have it my shift + right click doesn't work. I'm thinking
that to make this work I'd need to transfer those assignments to the
Main(custom.cui) or the enterprise CUI.

Are you seeing the same thing?

Sage

[Anonymous]

Jack, if you're still wading through this mess... as Sage pointed out,
button assignments may have to be at the main or enterprise (my preference)
level. But those assignments can hard reference menus (incl POP0) from any
loaded file. If you don't hard reference and there is a menu in another
file with the same alias, then it may win. HTH

James


"Jack G" wrote in message
news:4840850@discussion.autodesk.com...
I'm talking about my own custom Pop0's. They only seem to work if they're in
the "main" menu, and I'd like to be able to control and revise them from an
"enterprise" menu.

[Anonymous]

Hi Robert, How goes?

-Main
-Enterprise
--ACAD

Tricky. I'd say! I've seen the scenarios that both Sage and yourself
describe, plus some. For example, I tried entirely stripping buttons from
all three files (starting from .mns) and guess what? Right-click (context
menus) still worked! Then I tried a setup similar to what you describe, and
had Ctrl+Right-Click and Shift+Right-Click working, but no others... Go
figure.

While I'm growing more confused on mouse button assignments, there are a
couple aspects I'm growing more comfortable with.
Mouse button Assignments do work at the main or enterprise level.
Pop menus from any file can be hard referenced in the assignment.

FWIW, I think I've got mine working how I want it to. But it bugs me not
being able to nail it down and be more helpful.

James


"R. Robert Bell" wrote in message
news:4841468@discussion.autodesk.com...
Sage,

The mouse buttons are a bit tricky, and the rules aren't obvious to any of
us yet.

For instance, the assumption has been made that if mouse buttons are defined
in a "higher priority" cui, that it rules all mouse button definitions.

That cannot be entirely true, as my environment has only two mouse buttons
defined in my enterprise cui, Ctrl+Click (Button 2) and Ctrl+Shift+Click
(Button 2). Both of those work correctly.

The interesting bit is that my Click group is only located in my partially
loaded Acad.cui (by the enterprise cui file) and it works correctly!
However, the Shift+Click that is only defined there does _not_.

I will explore this further in the next day or two.

--
R. Robert Bell

[Anonymous]

This is very good info. My one question would be, when we go to upgrade next time, what should we expect to happen with customizations in the acad.cui file. Right now, I'm letting my users modify the acad.cui.

Under the explained setup, I think that with toolbars anyway, new toolbars would find their way in the custom.cui, new buttons or modified buttons on existing toolbars would remain in the acad.cui. I'm not sure creating a third cui to hold user customizations is neccessary.

My first thoughts on the migration tool was that it would be able to detect these customizations and migrate them as possible. But it looks like I might be wrong here.

Please inform me so I can plan ahead accordingly.

[Anonymous]

Hello,

The reason we went to XML menus was so that we could tell user customization
and migrate it forward in the next release. For example if you customized
the ACAD.CUI and it was your main CUI file we would look at that data and
migrate to the next release CUI file. But if the custom.cui is a partial
menu we would look at copying it and menuloading it as a partial menu rather
then merging it into the new CUI file.

What would you expect to see happen here? Also how would you want to deal
with the Enterprise menu from a migration standpoint?

Hope this helps and I look forward to hearing your thoughts on this.

Bud Schroeder
AutoCAD Test Development
Autodesk Inc.



wrote in message news:4843852@discussion.autodesk.com...
This is very good info. My one question would be, when we go to upgrade
next time, what should we expect to happen with customizations in the
acad.cui file. Right now, I'm letting my users modify the acad.cui.

Under the explained setup, I think that with toolbars anyway, new toolbars
would find their way in the custom.cui, new buttons or modified buttons on
existing toolbars would remain in the acad.cui. I'm not sure creating a
third cui to hold user customizations is neccessary.

My first thoughts on the migration tool was that it would be able to detect
these customizations and migrate them as possible. But it looks like I
might be wrong here.

Please inform me so I can plan ahead accordingly.

[Anonymous]

Partial menus should stay partial. To merge them in might hose some careful
separation of cui files.

For the enterprise file, it would be cool if the commands used in it would
be compared to their original cui file (I'm thinking of my MW.cui using some
Acad.cui commands) and only updates otherwise unmodified commands. Of
course, only the admin should be able to do this. Which could be tricky if
the user simply changes their profile, eh?

--
R. Robert Bell


"Bud Schroeder [Autodesk Inc.]" wrote in
message news:4843948@discussion.autodesk.com...
Hello,

The reason we went to XML menus was so that we could tell user customization
and migrate it forward in the next release. For example if you customized
the ACAD.CUI and it was your main CUI file we would look at that data and
migrate to the next release CUI file. But if the custom.cui is a partial
menu we would look at copying it and menuloading it as a partial menu rather
then merging it into the new CUI file.

What would you expect to see happen here? Also how would you want to deal
with the Enterprise menu from a migration standpoint?

Hope this helps and I look forward to hearing your thoughts on this.

Bud Schroeder
AutoCAD Test Development
Autodesk Inc.

[Steve_Johnson]

Hi Bud! Long time no write! Still grinning? 🙂

I know the migration thing is the touted main reason for the change to CUI, but it's making me very nervous. I think the main thing I would require of 2007's CUI update feature is an off switch. I think it would be almost impossible to write a migration tool that will work completely correctly in all circumstances, as you have discovered with your automatic migration from MNU to CUI. Given the possible range of scenarios, it's hard to see how you could write something foolproof. Here are some of the complications:

Multiple users, some with admin rights, some without. Multiple profiles per user. Multiple workspaces per user. CAD Managers and users that want this handled automatically, others that want intelligent control and way want the option disabled for some users. Multiple menu files, some shared between users, some personal to users, some Main, some Enterprise, some partial under Main, some partial under Enterprise, some stored locally, some stored on the network, some stored where the user has write permission, some where the user does not, some stored in global locations, some stored in user-specific locations, some menus that will still need to be used by 2006 and stored in the same location, some that will be stored in 2007-specific locations to be determined by the CAD manager, some toolbar buttons that use Autodesk dlls for bitmaps, some that use my dlls, some that use my bmps, some that still need to be used by 2006, menu items that answer AutoCAD prompts with pauses or hardwired command input or in-line LISP or calls to external LISP code, menu files that aren't in use right now but which are loaded as required via LISP or other menu items or by profile change, menus that come from third parties, menus that are still in mn* format... Get the idea?

Do I trust Autodesk to make the right decisions about how to handle all of those situations? Especially as what's "right" for me may be "wrong" for Robert? Absolutely not!

I'll do my own migration using human intelligence, thank you, just as I have for the last 20 years. It hasn't been too onerous. In fact, it has always been considerably less onerous than the MNU to CUI migration has been.

What I would like, ideally, is the availability of a simple CUI file selection migration tool. If I decide to use it, it will migrate selected file(s) from 2006 to 2007. Even that simple solution is fraught with problems. It would need the option of either overwriting (with multiple-level backups, of course!) or making renamed or relocated copies of the menus and associated files, to avoid breaking the menus in 2006. For menus with attached partial menus, you need to let the user choose whether to migrate the partials automatically, ignore them or prompt the user. You would, of course, not even think about contemplating the very idea of merging partial menus into the main menu. You will need to provide a command-line interface and/or other API, to allow the migration to be performed under program control.

The other thing that makes me nervous about this whole idea is that it encourages Autodesk to tinker with the behaviour of commands in menus/scripts/LISP. "Oh, it'll be OK to move that prompt around in response to that wishlist item, that'll be taken care of by the migration tools."

That's just the stuff I thought of, right off the top of my head. I'm sure there are many, many other complications I haven't though of. Yet. 😉 I envy you not.

[Anonymous]

Oh, and visual display of proposed migration items, with check-boxes to
"just say no" to an item's migration.

--
R. Robert Bell


"R. Robert Bell" wrote in message
news:4843951@discussion.autodesk.com...
Partial menus should stay partial. To merge them in might hose some careful
separation of cui files.

For the enterprise file, it would be cool if the commands used in it would
be compared to their original cui file (I'm thinking of my MW.cui using some
Acad.cui commands) and only updates otherwise unmodified commands. Of
course, only the admin should be able to do this. Which could be tricky if
the user simply changes their profile, eh?

[Anonymous]

Hi Bob,

Thanks for the feedback. I may ask you more questions on this topic later.
I would like to hear more of your thoughts on Enterprise and may have some
questions for you.

Thanks again for the feedback.

Bud


"R. Robert Bell" wrote in message
news:4843951@discussion.autodesk.com...
Partial menus should stay partial. To merge them in might hose some careful
separation of cui files.

For the enterprise file, it would be cool if the commands used in it would
be compared to their original cui file (I'm thinking of my MW.cui using some
Acad.cui commands) and only updates otherwise unmodified commands. Of
course, only the admin should be able to do this. Which could be tricky if
the user simply changes their profile, eh?

--
R. Robert Bell


"Bud Schroeder [Autodesk Inc.]" wrote in
message news:4843948@discussion.autodesk.com...
Hello,

The reason we went to XML menus was so that we could tell user customization
and migrate it forward in the next release. For example if you customized
the ACAD.CUI and it was your main CUI file we would look at that data and
migrate to the next release CUI file. But if the custom.cui is a partial
menu we would look at copying it and menuloading it as a partial menu rather
then merging it into the new CUI file.

What would you expect to see happen here? Also how would you want to deal
with the Enterprise menu from a migration standpoint?

Hope this helps and I look forward to hearing your thoughts on this.

Bud Schroeder
AutoCAD Test Development
Autodesk Inc.

[Anonymous]

Thanks James I appreciate the help.

So I set the cui that I want to add the button assignments as main. I don't
see the "Click" nor other mouse button combinations. How can I add those to
my main cui? I see the "Click" and other button combo's on the transfer tab
of both new and in the ACAD.CUI just not my existing new mns created cui.
Nor can I transfer them. On the bottom it says "This node cannot be
transferred" Well "g" ain't that helpful. 😉

Thanks again James



"James Allen" wrote in message
news:4843517@discussion.autodesk.com...
Hi Sage,

At this point I'd say yes, transfer the assignments and specify your ACAD
group in the assignment (e.g. $P0=ACAD.SNAP $P0=*). This seems to me the
most reliable solution. And besides, I don't think these button assignments
have changed for several releases, just the menus they reference.

Yes, I'm seeing the same thing as you. I entirely stripped mouse buttons
from main and enterprise, and acad buttons still did not work. So it looks
like it is best if they are defined at the enterprise level. However I have
also now seen what Robert described and even stranger things. So I'm not
real sure of much right now regarding the mouse buttons.

James

[Anonymous]

I disagree with Robert here. IMHO... My custom CUI is mine. AutoCAD should
do nothing with it execpt to transfer it if need be.

"R. Robert Bell" wrote in message
news:4843951@discussion.autodesk.com...
Partial menus should stay partial. To merge them in might hose some careful
separation of cui files.

For the enterprise file, it would be cool if the commands used in it would
be compared to their original cui file (I'm thinking of my MW.cui using some
Acad.cui commands) and only updates otherwise unmodified commands. Of
course, only the admin should be able to do this. Which could be tricky if
the user simply changes their profile, eh?

--
R. Robert Bell


"Bud Schroeder [Autodesk Inc.]" wrote in
message news:4843948@discussion.autodesk.com...
Hello,

The reason we went to XML menus was so that we could tell user customization
and migrate it forward in the next release. For example if you customized
the ACAD.CUI and it was your main CUI file we would look at that data and
migrate to the next release CUI file. But if the custom.cui is a partial
menu we would look at copying it and menuloading it as a partial menu rather
then merging it into the new CUI file.

What would you expect to see happen here? Also how would you want to deal
with the Enterprise menu from a migration standpoint?

Hope this helps and I look forward to hearing your thoughts on this.

Bud Schroeder
AutoCAD Test Development
Autodesk Inc.

[Anonymous]

Ask away!

--
R. Robert Bell


"Bud Schroeder [Autodesk Inc.]" wrote in message
news:4844401@discussion.autodesk.com...
Hi Bob,

Thanks for the feedback. I may ask you more questions on this topic later.
I would like to hear more of your thoughts on Enterprise and may have some
questions for you.

Thanks again for the feedback.

[Anonymous]

I guess I was confused on the matter of polluting the acad.cui.

If need be I suppose that both the office.cui and the acad.cui could be included (one as a partial) in the enterprise category, and then users would have to create new menus/toolbars in order to personalize. But what if, let's say they want to add a custom command to the Draw menu and toolbar or simply rearrange commands based on usage. They would have to recreate or copy it over to their own custom.cui. From there on, while the acad.cui's get migrated with new commands, remove obsolete ones, etc, the user would still be using the personal one that was simply copied over.

I thought the whole idea of improving migration was to better handle the users polluting the acad.cui, your comments seem to support that, but the OP seems to indicate that proper migration is in the hands of the users by tinkering with the acad.cui as little as possible. Maybe I misunderstand the arguments.

What I expected on how migration would work is that new commands could be inserted before/after associated commands that already exist, where ever they might be found in the correct menu name/toolbar. Since a "clean" acad.cui exists in the UserDataCache, I would think there should be little worry of polluting it if a migration problem were to happen.

As far as the enterprise/office menu, I think typically that is a menu specifically maintained by the CAD manager and should be left alone, or at the most provide a comparability checker. Any tools you can give the CAD manager would be helpful, believe or not, I think Acad2006 has made progress in that area with cui's.

[Anonymous]

Hope I don't sound too argumentive, just trying to figure this out.