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]

On 5/7/2005 1:07 PM R. Robert Bell spoke thusly:

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

Immensely. Thanks for sharing!

[Anonymous]

Thanks Robert for directing me from the general ng to here about this. All
sounds good to me but I am not sure that the following is true.

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

Did you give this a go and do the workspaces in fact become available in the
main cui (custom.cui in this instance)?

Regards

Andreas


"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. Workspaces defined in the Enterprise .cui file *are* available.

--
R. Robert Bell


"Andreas" wrote in message
news:4838120@discussion.autodesk.com...
Thanks Robert for directing me from the general ng to here about this. All
sounds good to me but I am not sure that the following is true.

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

Did you give this a go and do the workspaces in fact become available in the
main cui (custom.cui in this instance)?

Regards

Andreas


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

Hi Robert,

What about third-party apps? For instance my KCS Productivity Pack for ADT
has a partial menu and .MNL file that you would most likely not want to have
loaded in a "vanilla" AutoCAD profile. So far, all I can see for a solution
is to designate the KCS menu as the Enterprise menu - not a good solution
since only one file can be an Enterprise file. I admit my understand of this
is probably not complete. And Autodesk (ADN) did not have a solution. Have
you come up with a better way to deal with this situation?

Ken Krupa
Krupa CADD Solutions
www.krupacadd.com
Home of KCS Productivity Pack for ADT

[Anonymous]

No. You would menuload it underneath the main Custom.cui file as a partial
menu. The office's .cui would, and should, still be the Enterprise .cui.

That way a true vanilla profile that used Acad.cui as the main .cui would
still be unaffected.

--
R. Robert Bell


"Ken Krupa" wrote in message
news:4838166@discussion.autodesk.com...
Hi Robert,

What about third-party apps? For instance my KCS Productivity Pack for ADT
has a partial menu and .MNL file that you would most likely not want to have
loaded in a "vanilla" AutoCAD profile. So far, all I can see for a solution
is to designate the KCS menu as the Enterprise menu - not a good solution
since only one file can be an Enterprise file. I admit my understand of this
is probably not complete. And Autodesk (ADN) did not have a solution. Have
you come up with a better way to deal with this situation?

Ken Krupa
Krupa CADD Solutions
www.krupacadd.com
Home of KCS Productivity Pack for ADT

[Anonymous]

Robert,

What was wrong with the old set of .mn* files that moved Autodesk to switch
to this new set of "CUI's" ?

"R. Robert Bell" wrote in message
news:4838243@discussion.autodesk.com...
No. You would menuload it underneath the main Custom.cui file as a partial
menu. The office's .cui would, and should, still be the Enterprise .cui.

That way a true vanilla profile that used Acad.cui as the main .cui would
still be unaffected.

--
R. Robert Bell


"Ken Krupa" wrote in message
news:4838166@discussion.autodesk.com...
Hi Robert,

What about third-party apps? For instance my KCS Productivity Pack for ADT
has a partial menu and .MNL file that you would most likely not want to have
loaded in a "vanilla" AutoCAD profile. So far, all I can see for a solution
is to designate the KCS menu as the Enterprise menu - not a good solution
since only one file can be an Enterprise file. I admit my understand of this
is probably not complete. And Autodesk (ADN) did not have a solution. Have
you come up with a better way to deal with this situation?

Ken Krupa
Krupa CADD Solutions
www.krupacadd.com
Home of KCS Productivity Pack for ADT

[Anonymous]

Autodesk itself would be in a better position to discuss the reasons...
however, some reasons I've heard are that Autodesk wants to make it easier
to migrate custom settings in future releases. The CUI provides versioning
to aid this process.

We are experiencing a bit of growing pains here, but bear with it.

--
R. Robert Bell


"Alfredo Medina" wrote in message
news:4838259@discussion.autodesk.com...
Robert,

What was wrong with the old set of .mn* files that moved Autodesk to switch
to this new set of "CUI's" ?

[Anonymous]

I hope that the commands MENUUNLOAD MENULOAD will be supported in the future
releases for many reasons:

In the previous releases I used to

- create a new acad.mnu derived from the original but without the
***SCREEN section and the ***TABLET section to have a lighter menu
to load

- in my personal menu I have a Pop menu, custom toolbars, tablet areas
and accelerators

- all icons BMP are in a DLL

Now in R16.2 I do not modify the original ACAD.cui and use the same
personal menu.

---

I prefear to have my menu in old style because I still use the OLD
MC.EXE to compute my MND file (with some macros expecially for tablet
areas) and I think (IMHO) it more simple to edit my menu file in a good
editor.

An example of macro:
if you want to have two language menu in a unique file to update
in the MND file you must modify only one line and recompile it
to have the new MNU in the language you want:

>>> mnd
{ITA}=
{ENG}=//

{ITA}[_Button("Nuovo", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new
{ENG}[_Button("New", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new

>>> mnu
[_Button("Nuovo", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new
//[_Button("New", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new

---

I also noted that in R16.2 I can not have alternative tablet areas
to swap, maybe many users do not have digitizer anymore but I still
like it.

---

This is the function I use to load or update my menu
but I do not know how to continue to edit my menu when MENUUNLOAD MENULOAD
will be dropped as stated in the AutoCAD Guide.

---

(defun C:ALE_MENU_RESET ( / Mc_Exe MnuPat)
(if (and (setq Mc_Exe (findfile "MC.EXE")) (setq MnuPat (findfile
"MyMenu.MND")))
(dos_exewait (strcat Mc_Exe " " (substr MnuPat 1 (- (strlen MnuPat) 4)))
3)
)
(if (findfile "MyMenu.mnu")
(progn
(setcfg "AppData/MyMenu/MenuLoad" "1")
(cond
( (> (atof (getvar "ACADVER")) 16.1)
(if (setq MnuPat (findfile "MyMenu.mnr")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "MyMenu.cui")) (vl-file-delete MnuPat))
(command "_.MENUUNLOAD" "MyMenu" "_.MENULOAD"
"MyMenu.MNU")(menucmd "p1=+MyMenu.pop1")
)
(T
(if (setq MnuPat (findfile "MyMenu.mnc")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "MyMenu.mnr")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "MyMenu.mns")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "acad.mnc")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "acad.mnr")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "acad.mns")) (vl-file-delete MnuPat))
(command "_.MENUUNLOAD" "MyMenu" "_.MENULOAD" "MyMenu")(menucmd
"p1=+MyMenu.pop1")
)
)
(menucmd "T1=MyMenu.TABLET11") (menucmd "T2=MyMenu.TABLET21")
(menucmd "T3=MyMenu.TABLET31") (menucmd "T4=MyMenu.TABLET41")
(alert "\nMyMenu Menù updated, please close and reopen AutoCAD. ")
)
(alert "\nMyMenu Menù not found. ")
)
(princ)
)

--

Marc'Antonio Alessi
http://xoomer.virgilio.it/alessi
(strcat "NOT a " (substr (ver) 8 4) " guru.")

--

[Anonymous]

I like your signiture!!
(strcat "NOT a " (substr (ver) 8 4) " guru.")


--



--

Marc'Antonio Alessi
http://xoomer.virgilio.it/alessi
(strcat "NOT a " (substr (ver) 8 4) " guru.")

--

[Anonymous]

Thanks Robert. I don't think it had even occurred to me to partial load
"acad". I think this may be a step in the right direction. Will have to
see how it goes...
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO


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

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]

Update.
I found that in the main cui there where no Mouse Buttons definition. I
could not add any using CUI but had to create a new main cui by transfering
those from acad.cui to a new cui in this case custom.cui.

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


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

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]

"R. Robert Bell" wrote in message
news:4838548@discussion.autodesk.com...
I don't have any items placed in my office's .cui file (yet).

(That should read "...any items placed in the shortcut menus area of my
office's...")

[Anonymous]

I thought about doing this as well. I take it that
paths to partial menus are not saved within the
main cui file, only the menu names?


--
Autodesk Discussion Group Facilitator



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

> Acad.cui and Express.cui menuloaded into the office's .cui file.

[Anonymous]

That's very similar to an approach I was considering, where the custom menu file is set as the "main" one. (You actually replied to another post of mine) So it's good to hear someone else come to the same basic conclusion. But, you brought up something that now raises a question for me. Under your proposed "main" and "enterprise" configuration, Express is not a partial menu of Acad - they are both partials of your Office menu. So, if you were to now want to launch a vanilla profile, Express would not load. Am I missing something?

Shawn

[Anonymous]

(progn(princ(vl-string-translate"7521463""!khTnsa""1234567"))(princ))

[Anonymous]

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.

"Marc'Antonio Alessi" wrote in message
news:4838329@discussion.autodesk.com...
I hope that the commands MENUUNLOAD MENULOAD will be supported in the future
releases for many reasons:

In the previous releases I used to

- create a new acad.mnu derived from the original but without the
***SCREEN section and the ***TABLET section to have a lighter menu
to load

- in my personal menu I have a Pop menu, custom toolbars, tablet areas
and accelerators

- all icons BMP are in a DLL

Now in R16.2 I do not modify the original ACAD.cui and use the same
personal menu.

---

I prefear to have my menu in old style because I still use the OLD
MC.EXE to compute my MND file (with some macros expecially for tablet
areas) and I think (IMHO) it more simple to edit my menu file in a good
editor.

An example of macro:
if you want to have two language menu in a unique file to update
in the MND file you must modify only one line and recompile it
to have the new MNU in the language you want:

>>> mnd
{ITA}=
{ENG}=//

{ITA}[_Button("Nuovo", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new
{ENG}[_Button("New", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new

>>> mnu
[_Button("Nuovo", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new
//[_Button("New", RCDATA_16_NEW, RCDATA_16_NEW)]{CC}_new

---

I also noted that in R16.2 I can not have alternative tablet areas
to swap, maybe many users do not have digitizer anymore but I still
like it.

---

This is the function I use to load or update my menu
but I do not know how to continue to edit my menu when MENUUNLOAD MENULOAD
will be dropped as stated in the AutoCAD Guide.

---

(defun C:ALE_MENU_RESET ( / Mc_Exe MnuPat)
(if (and (setq Mc_Exe (findfile "MC.EXE")) (setq MnuPat (findfile
"MyMenu.MND")))
(dos_exewait (strcat Mc_Exe " " (substr MnuPat 1 (- (strlen MnuPat) 4)))
3)
)
(if (findfile "MyMenu.mnu")
(progn
(setcfg "AppData/MyMenu/MenuLoad" "1")
(cond
( (> (atof (getvar "ACADVER")) 16.1)
(if (setq MnuPat (findfile "MyMenu.mnr")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "MyMenu.cui")) (vl-file-delete MnuPat))
(command "_.MENUUNLOAD" "MyMenu" "_.MENULOAD"
"MyMenu.MNU")(menucmd "p1=+MyMenu.pop1")
)
(T
(if (setq MnuPat (findfile "MyMenu.mnc")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "MyMenu.mnr")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "MyMenu.mns")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "acad.mnc")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "acad.mnr")) (vl-file-delete MnuPat))
(if (setq MnuPat (findfile "acad.mns")) (vl-file-delete MnuPat))
(command "_.MENUUNLOAD" "MyMenu" "_.MENULOAD" "MyMenu")(menucmd
"p1=+MyMenu.pop1")
)
)
(menucmd "T1=MyMenu.TABLET11") (menucmd "T2=MyMenu.TABLET21")
(menucmd "T3=MyMenu.TABLET31") (menucmd "T4=MyMenu.TABLET41")
(alert "\nMyMenu Menù updated, please close and reopen AutoCAD. ")
)
(alert "\nMyMenu Menù not found. ")
)
(princ)
)

--

Marc'Antonio Alessi
http://xoomer.virgilio.it/alessi
(strcat "NOT a " (substr (ver) 8 4) " guru.")

--

[Anonymous]

???

The main .cui file can also have partial menus menuloaded. And those would
not be read-only.

--
R. Robert Bell


"Jason Piercey" wrote in message
news:4838571@discussion.autodesk.com...
I thought about doing this as well. I take it that
paths to partial menus are not saved within the
main cui file, only the menu names?