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]

You should keep them separate to match the .cui file names.

--
R. Robert Bell


"Gary Fowler" wrote in message
news:4839222@discussion.autodesk.com...
So, do I keep my seperate mnl files, one for each of my past menu files?
Or combine them into one mnl file?
, this is a CUI interface issue.)

[Anonymous]

Thanks...I'm starting to see the light thru squinted eyes.

--
Gary Fowler - Architect
gdfowler@hotmail.com


"R. Robert Bell" wrote in message
news:4839330@discussion.autodesk.com...
You should keep them separate to match the .cui file names.

--
R. Robert Bell


"Gary Fowler" wrote in message
news:4839222@discussion.autodesk.com...
So, do I keep my seperate mnl files, one for each of my past menu files?
Or combine them into one mnl file?
, this is a CUI interface issue.)

[Anonymous]

> It is no longer necessary to make Acad.cui the root of structure.

When setting this up the first time using the empty Custom.cui file, it will
be critically important not to set the Acad.cui, or any CUI file with the
only available workspaces as the read-only Enterprise file.

Otherwise when you do a Workspace SAveas you will be missing the ability to
use AutoCAD. Until you restart it.

Well, at least it does here for me.

-> Setup Errror, Failed to load resources from resource file. Please check
your setup.

"

[Anonymous]

as opposed to what?
I am only aware of the cuiload command to load partial menus, and it does not ask for a "parent" to be loaded under.
The CUI interface does not seem to indicate partial menus being under one another.
Am I missing something, (probably)
thanks



R. Robert Bell
|>-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.

[Anonymous]

Good one. A fun way of using LISP. good on you. A programmer with a sense
of humor!

"Marc'Antonio Alessi" wrote in message
news:4838777@discussion.autodesk.com...
(progn(princ(vl-string-translate"7521463""!khTnsa""1234567"))(princ))

[Anonymous]

Mine works but then again I have a POP0 of my own defined in the office.cui
(enterprise)

"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]

When editing the enterprise .cui file, it is the main .cui file, so yes, in
that case, you are correct.

However (you knew that was coming!), once you switch profiles to the user's
normal profile, the enterprise .cui is read-only, and a CUILoad will place
partial menus in the main .cui (Custom).

--
R. Robert Bell


"James Maeding" wrote in message
news:4839366@discussion.autodesk.com...
as opposed to what?
I am only aware of the cuiload command to load partial menus, and it does
not ask for a "parent" to be loaded under.
The CUI interface does not seem to indicate partial menus being under one
another.
Am I missing something, (probably)
thanks



R. Robert Bell
|>-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.

[Anonymous]

Robert,
Thanks. After messing with CUI when 2006 first came out and thereby blowing
my whole interface out of the water, my current philosophy has reduced to
"If it ain't broke don't CUI it."

The first time I gleefully dragged items around CUI, I ended up with no menus and no
way back other than re-installing the whole system. For something that looks like
child's play, I still don't understand why its not more intuitive. But I'm too busy
to spend the hours necessary to learn how to save a few minutes.

CUI still mystifies me, especially the enterprise portion, which I appartently don't
need and can't test as a one man shop.

Perhaps when Adesk comes out with a customization manual or an hour long video
that explains how this easier interface can be used without drastic consequences,
the benefits will be clearer. Thank goodness we've got tool palettes, lisp, aliases,
and the old customize command cause if I needed CUI, I'd be hurting. 😉

Perhaps after more of your installments, I will better appreciate it.

Regards,
Doug




"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]

Yes... go gentle into that long, dark night.

;^)

Actually, you can explore the enterprise feature, if you wish. I'm running
enterprise from a local location as we speak.

--
R. Robert Bell


"Doug Broad" wrote in message
news:4839457@discussion.autodesk.com...
Robert,
Thanks. After messing with CUI when 2006 first came out and thereby blowing
my whole interface out of the water, my current philosophy has reduced to
"If it ain't broke don't CUI it."

The first time I gleefully dragged items around CUI, I ended up with no
menus and no
way back other than re-installing the whole system. For something that
looks like
child's play, I still don't understand why its not more intuitive. But I'm
too busy
to spend the hours necessary to learn how to save a few minutes.

CUI still mystifies me, especially the enterprise portion, which I
appartently don't
need and can't test as a one man shop.

Perhaps when Adesk comes out with a customization manual or an hour long
video
that explains how this easier interface can be used without drastic
consequences,
the benefits will be clearer. Thank goodness we've got tool palettes, lisp,
aliases,
and the old customize command cause if I needed CUI, I'd be hurting. 😉

Perhaps after more of your installments, I will better appreciate it.

Regards,
Doug

[Anonymous]

A thing I noticed is that when the Workspace is in the enterprise CUI it can
not be overwritten using Save Current As since it is Read Only but if
toolbars are moved they are save anyway. At least temporary if you restart
AutoCAD with the same Workspace and profile. If you change Workspace the
changes are not retained when switching back again. This is because these
temporary changes are saved to the profile and if the same profile is used
for 2 or more workspaces the changes will not be retained.

--
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]

"Doug Broad" wrote in message
news:4839457@discussion.autodesk.com...
Robert,

CUI still mystifies me,

Perhaps after more of your installments, I will better appreciate it.

Regards,
Doug

If a Giant such as yourself is struggling with it ... that's really saying
something.

Is this perhaps another great benefit from the "offshoring" of programming
tasks that adesk has been at the forefront of promoting???

I can almost see the cui team leader now, leaning over his dusty 286 in that
grass hut with the goats chewing on his exposed ide cables strewn across the
dirt floor....thinking,....how can I make this harder for those imperialist
yankee cad monkeys???

:-)

[Anonymous]

Or it could just be a sign of early Alzheimers on my part. 😉

But seriously, CUI is nearly all graphical. Yet the help files (at least the
ones I've read) try to explain it verbally, with only a few static pictures.

Graphical commands that require dragging and dropping must be explained
by showing, not by verbalizing. And someone should clearly explain the
do's and don'ts without all the jargon (no jibe at you Robert) and preferrably
by an animated presentation (and not a 1 minute short either). They should
lead us through the steps until at least most newbies can reliably do it without
courting disaster.

Things that look simple should behave simply. At the very least, there should
be a test mode, that we can cancel or an agent like Mr. Clip saying "Nuh uh
uh" and shaking its virtual head and rolling its eyeballs when we do something
unexpected.

Regards from the shrinking giant,
Doug




"MP" wrote in message news:4839770@discussion.autodesk.com...

If a Giant such as yourself is struggling with it ... that's really saying
something.

[Anonymous]

You mean Microsoft's Mr.Clip little guy? Oh, I hope I never have to see that
guy in AutoCAD!

"Doug Broad" wrote in message
news:4839841@discussion.autodesk.com...
(...)
Things that look simple should behave simply. At the very least, there
should
be a test mode, that we can cancel or an agent like Mr. Clip saying "Nuh uh
uh" and shaking its virtual head and rolling its eyeballs when we do
something
unexpected.

Regards from the shrinking giant,
Doug




"MP" wrote in message
news:4839770@discussion.autodesk.com...

If a Giant such as yourself is struggling with it ... that's really saying
something.

[Anonymous]

Thanks!

I thought that the CUILoad was only to load "CUI" files.

I think that I will continue with the my "old" method and
edit my MND/MNU files.



Marco


"Art Cooney" ha scritto nel messaggio
news:4838893@discussion.autodesk.com...
The functionality is not going away, but those specific command names are -
they are replaced by CUILOAD and CUIUNLOAD which do exactly the same thing.

[Anonymous]

Does that mean you're repealing "Maedings Laws" (1: Toolbars and pulldown
menus can be placed anywhere; 2: Everything else only works when in the main
cui)? That's too bad because that was the first clear statement I've seen
about the functioning of cui's!! I'm still desperately hoping that at the
end of this thread you or someone else will rewrite the laws in an equally
clear and precise statement to help me understand this stuff! I've been
unable to get Pop0's to work anywhere but in a "main" cui, so I keep reading
these threads with baited breath.

Interesting that the AutoCad guys don't chime in except when the cui
questions are easy! You might think they could give us the laws!

Jack

"James Maeding" wrote in message
news:4839212@discussion.autodesk.com...
I am finding out that I was wrong about mouse buttons and other things only
working from the main and enterprise cui.

Now my question is how conflics are resolved for things like mouse buttons
and keyboard shortcuts.
Is there a precedence rule? maybe its the order the menus are loaded in?
thx

[Anonymous]

Robert,
I am getting lost. You mentioned that patial menus are somehow designated as being loaded under a particular other
menu. I would not care but you say it affects conflicts of names somehow.

From what I see, its simple:
Main menu
Enterprise menu
Partial loaded menus

Thats it, nothing "nested".

My original question of how duplicate items get resolved still stands.

I will do more testing, but what I am finding now is that there are only a couple things that must be in the main and
enterprise CUI's:
1) workspaces
2) digitizer puck buttons (not mouse buttons)

Figuring out what functions where, and how duplicate items are resolved will tell us everything we need to know to
design a system to our needs. I do not feel we have this nailed down yet. This is fun though, I like new stuff.

I put in a subscription request on this so hopefully will get more Adesk input on this.
thanks

R. Robert Bell
|>When editing the enterprise .cui file, it is the main .cui file, so yes, in
|>that case, you are correct.
|>
|>However (you knew that was coming!), once you switch profiles to the user's
|>normal profile, the enterprise .cui is read-only, and a CUILoad will place
|>partial menus in the main .cui (Custom).

[Anonymous]

Jack,

Are you talking about a custom POP0 or simply the default Acad one?

--
R. Robert Bell


"Jack G" wrote in message
news:4840188@discussion.autodesk.com...
Does that mean you're repealing "Maedings Laws" (1: Toolbars and pulldown
menus can be placed anywhere; 2: Everything else only works when in the main
cui)? That's too bad because that was the first clear statement I've seen
about the functioning of cui's!! I'm still desperately hoping that at the
end of this thread you or someone else will rewrite the laws in an equally
clear and precise statement to help me understand this stuff! I've been
unable to get Pop0's to work anywhere but in a "main" cui, so I keep reading
these threads with baited breath.

[Anonymous]

absolutely, I was dead wrong on that after doing more testing.

I totally agree that we need a revised set of laws. I will push to get that revised and completed because I will have
to sell it to my companies other Cad managers and good users.

Autodesk told me they will be doing a white paper soon on this. Funny that they would not participate here to test out
their ideas that will be in the paper. I think they underestimated the CUI transition.
They manage to do this with every release to give us something to do 🙂

I am just so stoked on dynamic blocks, I can't get too shaken by this CUI stuff. The new blocks are such a useful
thing, I think they are the biggest thing to happen since xrefs in R11.

Jack G
|>Does that mean you're repealing "Maedings Laws" (1: Toolbars and pulldown
|>menus can be placed anywhere; 2: Everything else only works when in the main
|>cui)? That's too bad because that was the first clear statement I've seen
|>about the functioning of cui's!! I'm still desperately hoping that at the
|>end of this thread you or someone else will rewrite the laws in an equally
|>clear and precise statement to help me understand this stuff! I've been
|>unable to get Pop0's to work anywhere but in a "main" cui, so I keep reading
|>these threads with baited breath.
|>
|>Interesting that the AutoCad guys don't chime in except when the cui
|>questions are easy! You might think they could give us the laws!
|>
|>Jack
|>
|>"James Maeding" wrote in message
|>news:4839212@discussion.autodesk.com...
|>I am finding out that I was wrong about mouse buttons and other things only
|>working from the main and enterprise cui.
|>
|>Now my question is how conflics are resolved for things like mouse buttons
|>and keyboard shortcuts.
|>Is there a precedence rule? maybe its the order the menus are loaded in?
|>thx

[Anonymous]

A picture is worth...

[Anonymous]

oh, I see said the blind man.
Duh, I did not have an enterprise CUI loaded...got it now

How does that help resolve conflicts though?
Is this documented anywhere about the difference between loading partials under the main or enterprise CUI?

thx


R. Robert Bell
|>A picture is worth...