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]

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

ML0940,

I already did read the whole posting.

>>After you have read through, please write back, I will be >>glad to answer any other questions you may have.

I already asked a question.
What will I have to do to make a switch from the system I have described to the new CUI idea AND get the same results.
Can each user have their owm menus, toolbars etc. depending on who logs in?

>>After you get started with 2006, I think our whole >>discussion of profiles will have a whole new meaning as >>well.

I'm sure you are correct, but I would like to know what I'm getting into before I switch.

Thanks anyway.

Bill

[Anonymous]

Okay,

Thanks RR,

We are on subscription now so we can go over anytime.

I still have a concern about the SigmaNest bugs. Will 2006 format be any change for these 3rd party apps from '05?

Bill

[Anonymous]

I dunno. You'll have to ask them.

--
R. Robert Bell


wrote in message news:4861912@discussion.autodesk.com...
Okay,

Thanks RR,

We are on subscription now so we can go over anytime.

I still have a concern about the SigmaNest bugs. Will 2006 format be any
change for these 3rd party apps from '05?

Bill

[Anonymous]

My understanding of profiles is fine.
Profiles hold Drafting setting, system settings etc.
Workspaces (In 2006) hold all of the toolbar and pulldown locations and visibility.

The only reason I have 2 different profiles is so that I don't have to switch the customization paths each time I need to customize the office cui file.

One profile has the office cui as main with acad.cui as enterprise, the other has acad as main with the office cui as enterprise.

After I switch profiles, I still need to make the workspace I want current. That is why I did the VBA module (in my aforementioned post) as I did

Multiple profiles are not a must but a convenience in 2006

Mark

[Anonymous]

>>>I dunno. You'll have to ask them.

Bingo! 🙂

Thanks

Bill

[Anonymous]

I like your idea but I would also make sure that the user's cui files are backed up regularly.

I chose to keep The acad.cui file as (base) the main cui for users and the company.cui as enterprise.
Before I went into it, I copied the original acad.cui out so that it can be easily replaced if anyone (or any machine) needs to start from ground 0 again.

I didn't want to get into managing a ton of user;s cui files, so that was my approach, it is working real well.

Mark

[Steve_Johnson]

One-month anniversary bump! Any Adesker want to try to sell the move to CUI based on specific information about exactly how migration is going to be wonderful for us in a year's time? Last chance!

[Anonymous]

Robert, et al,

I've read through this most-excellent thread and mostly understand what everyone's getting at for the most part.

When I set ours up per your philosophy, I get no right-click mouse buttons when I load the office profile (which has custom.cui (unmodified) and the office.cui (enterprise) which is a copy of the empty custom.cui with the added-in acad.cui partial as well as some other partials). I then realized you don't really say what your office.cui is made from and that I just assumed an empty cui but perhaps it was a copy of acad.cui instead? I actually used a copy of custom.cui to create our office.cui thinking it should be, like I said, "empty".

If I try to transfer the mouse buttons from the original acad.cui to our office.cui, it won't let me and gives me "This node cannot be transferred" on the status line of the Transfer window.

If you intended office.cui to be made from acad.cui, then isn't adding acad.cui in as a partial somewhat redundant?

Additionally, unless I've screwed it up with all my mucking about, I notice that the Custom.cui is a partial menu in the original acad.cui which also seems like it's going around in circles if custom.cui is designated as the main cui but then acad.cui is a partial to the enterprise cui.

Merle

[Anonymous]

Hi Merle,

I think the button groups and assignments should be at the main or
enterprise level, but the assignments can reference any loaded menu (e.g.
$P0=ACAD.SNAP $P0=*).

Maybe these will help?
http://discussion.autodesk.com/thread.jspa?messageID=4862677
news:4844822@discussion.autodesk.com...
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO


wrote in message news:4878776@discussion.autodesk.com...
Robert, et al,

I've read through this most-excellent thread and mostly understand what
everyone's getting at for the most part.

When I set ours up per your philosophy, I get no right-click mouse buttons
when I load the office profile (which has custom.cui (unmodified) and the
office.cui (enterprise) which is a copy of the empty custom.cui with the
added-in acad.cui partial as well as some other partials). I then realized
you don't really say what your office.cui is made from and that I just
assumed an empty cui but perhaps it was a copy of acad.cui instead? I
actually used a copy of custom.cui to create our office.cui thinking it
should be, like I said, "empty".

If I try to transfer the mouse buttons from the original acad.cui to our
office.cui, it won't let me and gives me "This node cannot be transferred"
on the status line of the Transfer window.

If you intended office.cui to be made from acad.cui, then isn't adding
acad.cui in as a partial somewhat redundant?

Additionally, unless I've screwed it up with all my mucking about, I notice
that the Custom.cui is a partial menu in the original acad.cui which also
seems like it's going around in circles if custom.cui is designated as the
main cui but then acad.cui is a partial to the enterprise cui.

Merle

[Anonymous]

In addition to what James stated, there is a known issue with the mouse
buttons when the mouse buttons are not defined in either the main or the
enterprise cui file.

This issue was identified weeks after this thread started. Autodesk is
working on a fix, so hopefully we will see one soon.

For background, I started the office.cui from an import of our office.mns,
so the mouse section is _not_ in office.cui (curses!). My custom.cui is
still empty, so I could copy the acad.cui to custom.cui to get the mouse
section (and everything else, shudder). I'm taking a wait-n-see attitude
towards the bug, not attempting to put too much time into a bandage that I
might not need for long.

--
R. Robert Bell


"James Allen" wrote in message
news:4878785@discussion.autodesk.com...
Hi Merle,

I think the button groups and assignments should be at the main or
enterprise level, but the assignments can reference any loaded menu (e.g.
$P0=ACAD.SNAP $P0=*).

Maybe these will help?
http://discussion.autodesk.com/thread.jspa?messageID=4862677
news:4844822@discussion.autodesk.com...
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO


wrote in message news:4878776@discussion.autodesk.com...
Robert, et al,

I've read through this most-excellent thread and mostly understand what
everyone's getting at for the most part.

When I set ours up per your philosophy, I get no right-click mouse buttons
when I load the office profile (which has custom.cui (unmodified) and the
office.cui (enterprise) which is a copy of the empty custom.cui with the
added-in acad.cui partial as well as some other partials). I then realized
you don't really say what your office.cui is made from and that I just
assumed an empty cui but perhaps it was a copy of acad.cui instead? I
actually used a copy of custom.cui to create our office.cui thinking it
should be, like I said, "empty".

If I try to transfer the mouse buttons from the original acad.cui to our
office.cui, it won't let me and gives me "This node cannot be transferred"
on the status line of the Transfer window.

If you intended office.cui to be made from acad.cui, then isn't adding
acad.cui in as a partial somewhat redundant?

Additionally, unless I've screwed it up with all my mucking about, I notice
that the Custom.cui is a partial menu in the original acad.cui which also
seems like it's going around in circles if custom.cui is designated as the
main cui but then acad.cui is a partial to the enterprise cui.

Merle

[Anonymous]

[nobr]

src="cid:02b801c5776f$82580950$3919920a@corp.talbots.com" align=baseline
border=0>

As was stated earlier, a picture is worth...

I basically adopted Robert's method except for a
small change. I started with a blank CUI and partially loaded the Acad.CUI, the
Acetmain.CUI and our own custom menus (Talbots.CUI). See the image above. I also
deleted all the mouse button clicks, which were basically blank anyway. This
solved the Right-Mouse click issue by accessing the Right-Mouse clicks from the
first Partial CUI file (ACAD).

Hope this helps someone. Just my 2
cents.

"R. Robert Bell" <
href="mailto:NOT.RobertB@MWEngineers.com">
size=2>NOT.RobertB@MWEngineers.com> wrote
in message
face=Arial size=2>news:4879520@discussion.autodesk.com
face=Arial size=2>...

In addition to what
James stated, there is a known issue with the mouse
buttons when the mouse
buttons are not defined in either the main or the
enterprise cui
file.

This issue was identified weeks after this thread started. Autodesk
is
working on a fix, so hopefully we will see one soon.

For
background, I started the office.cui from an import of our office.mns,
so
the mouse section is _not_ in office.cui (curses!). My custom.cui is
still
empty, so I could copy the acad.cui to custom.cui to get the mouse
section
(and everything else, shudder). I'm taking a wait-n-see attitude
towards the
bug, not attempting to put too much time into a bandage that I
might not
need for long.

--
R. Robert Bell


"James Allen"
<JamesA~AA~mwengrs~DD~com> wrote in message

href="news:4878785@discussion.autodesk.com">
size=2>news:4878785@discussion.autodesk.com
size=2>...
Hi Merle,

I think the button groups and assignments should
be at the main or
enterprise level, but the assignments can reference any
loaded menu (e.g.
$P0=ACAD.SNAP $P0=*).

Maybe these will
help?

href="http://discussion.autodesk.com/thread.jspa?messageID=4862677">
face=Arial
size=2>http://discussion.autodesk.com/thread.jspa?messageID=4862677

href="news:4844822@discussion.autodesk.com">
size=2>news:4844822@discussion.autodesk.com
size=2>...
--
James Allen, EIT
Malicoat-Winslow Engineers,
P.C.
Columbia, MO


<hallmerle> wrote in message
href="news:4878776@discussion.autodesk.com">
size=2>news:4878776@discussion.autodesk.com
size=2>...
Robert, et al,

I've read through this most-excellent thread
and mostly understand what
everyone's getting at for the most
part.

When I set ours up per your philosophy, I get no right-click mouse
buttons
when I load the office profile (which has custom.cui (unmodified) and
the
office.cui (enterprise) which is a copy of the empty custom.cui with
the
added-in acad.cui partial as well as some other partials).  I then
realized
you don't really say what your office.cui is made from and that I
just
assumed an empty cui but perhaps it was a copy of acad.cui
instead?  I
actually used a copy of custom.cui to create our office.cui
thinking it
should be, like I said, "empty".

If I try to transfer the
mouse buttons from the original acad.cui to our
office.cui, it won't let me
and gives me "This node cannot be transferred"
on the status line of the
Transfer window.

If you intended office.cui to be made from acad.cui,
then isn't adding
acad.cui in as a partial somewhat
redundant?

Additionally, unless I've screwed it up with all my mucking
about, I notice
that the Custom.cui is a partial menu in the original
acad.cui which also
seems like it's going around in circles if custom.cui is
designated as the
main cui but then acad.cui is a partial to the enterprise
cui.

Merle

[/nobr]

[Anonymous]

David,

I'm glad you found something that worked for you! Thanks for posting your
solution.

--
R. Robert Bell

[Anonymous]

This thread initially failed to take into account multiple verticals. In the
posted scheme, Acad.cui resides off of the enterprise cui. Obviously you
cannot attach multiple vertical's .cui files to the same enterprise cui or
you will run into unresolved elements.

I have given this some thought over the last month and cannot come up with a
scheme that I would be happy with. I guess I'm glad I don't need to support
multiple verticals!

One of the issues that perplex me is that if you want to permit users to
create and modify their own workspaces and add commands of their own, you
really need to have custom.cui or the vertical's .cui as the main cui file.
However, the user's will hate losing their work in one version of the main
cui file when they switch to another vertical.

One approach at this point is to have unique custom for each vertical, and
to partially load the vertical's cui into that custom.cui. In fact, Autodesk
itself leans towards this (unintentionally?) by placing a Custom.cui in
separate support folders for each vertical (e.g. I have both AutoCAD and ABS
here, with two separate support folders). This means the user will need to
transfer common commands between the multiple custom.cui files. Too bad, I
guess.

I'm unhappy with that approach because the vertical's .cui is exposed to
user abuse.

So another approach would be to have a "framework" enterprise cui that is
unique to each vertical, and located on the server, that partially loads the
true Office.cui and the vertical's .cui files. This "framework" cui file
would hold the workspaces for that vertical. And the user could store their
common cui commands in a .cui file that is partially loaded into the unique
Custom.cui in each vertical's Support folder. Yeah, baby! (Too bad that's a
lot of partial loads.)

In creating the "framework" cui, you could use the Transfer tab to save the
blank cui on the right pane, which includes the Mouse section (see David
Richardson's post in this thread, 22 June 2005 2:15 PM), and avoid the mouse
bug until it is fixed.

[Anonymous]

Theses CUI issues (and my lack of a good understanding)
are the main reason I will not be rolling out 2006 any time
soon for production work here at this office. Just sounds
like I'd be giving myself a daily tech-support headache.
Really is too bad as I think there are some features that are
improvements and will aid in production but not enough to
outweigh the CUI frustration/learning curve.



"R. Robert Bell" wrote in message
news:4890565@discussion.autodesk.com...
This thread

[Anonymous]

Getting the verticals has been interesting to say the least. We've
essentially adopted the technique you've describe Robert.

We have Acad, LDT, and C3D. The JBI.CUI is contains our menu, plus partials
of the stock stuff.
JBILDT.CUI loads that menu plus the LDT stuff
JBIC3D.CUI does the same.

It's a hassle, but we're making it work, and I only have to really modify
one custom menu area to have that change reflected across the board.

--
James Wedding, P.E.
Technology Manager &
Associate
Jones & Boyd, Inc.
Dallas, TX
XP/2 on P4-3.4/1G
LDT 2006 & C3D2006/SP1

[Anonymous]

I'm happy to hear that things are settling down on that front. Got that bar
tab ready to go?!

--
R. Robert Bell


"James Wedding" wrote in message
news:4891549@discussion.autodesk.com...
Getting the verticals has been interesting to say the least. We've
essentially adopted the technique you've describe Robert.

We have Acad, LDT, and C3D. The JBI.CUI is contains our menu, plus partials
of the stock stuff.
JBILDT.CUI loads that menu plus the LDT stuff
JBIC3D.CUI does the same.

It's a hassle, but we're making it work, and I only have to really modify
one custom menu area to have that change reflected across the board.

[Anonymous]

Just wanted to make the point that this CUI is not going away. And we
haven't been given a choice between MNU or CUI...it's take it or leave
it...upgrade and use it or don't...and that goes for future versions. If you
skip 2006, then you'll just have to deal with it in 2007 or 8. I don't think
they are going to go backwards and give us back MNU's. It's a safe guess,
they will be debugging it, tweaking it and making it more user friendly. My
suggestion is to wait for SP-1 and see what they do to address all the
concerns. That's probably why you said "anytime soon," just don't give up.
;-)
J

"Jason Piercey" wrote in message
news:4890915@discussion.autodesk.com...
Theses CUI issues (and my lack of a good understanding)
are the main reason I will not be rolling out 2006 any time
soon for production work here at this office. Just sounds
like I'd be giving myself a daily tech-support headache.
Really is too bad as I think there are some features that are
improvements and will aid in production but not enough to
outweigh the CUI frustration/learning curve.



"R. Robert Bell" wrote in message
news:4890565@discussion.autodesk.com...
This thread

[Anonymous]

Has anyone heard of an answer for this button problem yet? I have approx 16 people waiting to get at ACAD 2006, but I am reluctant to install on everyones machine until I have it sorted out. I have set everything up as per Roberts initial thread and tried what everyone has suggested, but I cant seem to get the ctrl right click working to be osnap or anything.
I am about to throw something because I keep going around in circles. Perhaps Bud from Autodesk can help me out here as we havent heard any input from Autodesk regarding this problem.

[Anonymous]

Yeppers. Between the lot of us, it will be an open barter system on who buys
who drinks. 😐

--
James Wedding, P.E.
Technology Manager &
Associate
Jones & Boyd, Inc.
Dallas, TX
XP/2 on P4-3.4/1G
LDT 2006 & C3D2006/SP1

[Anonymous]

A true mouse button fix from Autodesk is still in the future.

However, I was able to get mouse buttons working again without resorting to
manual XML editing.

I used my "Vanilla" profile and the CUI command to transfer all my items
from my original enterprise cui file (starting from the bottom Legacy node)
into a new cui file. (A new blank cui file in the editor has the mouse
node!) I then saved that new file back over the top of my old enterprise
file.

I had to reattach the partial cui files that I had in the original
enterprise cui, and modify the defined workspaces to turn off the Express
toolbars. I transferred the Snap Menu from Acad.cui to my enterprise cui
file under Button 2 in the Shift+Click node, and modified the command to:
$P0=ACAD.SNAP $p0=*

The total process was relatively painless (about 10 minutes edit time).

Limited testing has shown the Shift+RClick to work, even after running the
Temporary Overrides.

--
R. Robert Bell


wrote in message news:4892397@discussion.autodesk.com...
Has anyone heard of an answer for this button problem yet? I have approx 16
people waiting to get at ACAD 2006, but I am reluctant to install on
everyones machine until I have it sorted out. I have set everything up as
per Roberts initial thread and tried what everyone has suggested, but I cant
seem to get the ctrl right click working to be osnap or anything.
I am about to throw something because I keep going around in circles.
Perhaps Bud from Autodesk can help me out here as we havent heard any input
from Autodesk regarding this problem.