Visual LISP, AutoLISP and General Customization

Visual LISP, AutoLISP and General Customization

Reply
*James Allen
Post 11 of 232

Re: Notes on the philosophy of CUI

05-09-2005 05:51 AM in reply to: *R. Robert Bell
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
*Jimmy Bergmark
Post 12 of 232

Re: Notes on the philosophy of CUI

05-09-2005 06:11 AM in reply to: *R. Robert Bell
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
*Jimmy Bergmark
Post 13 of 232

Re: Notes on the philosophy of CUI

05-09-2005 07:06 AM in reply to: *R. Robert Bell
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
*R. Robert Bell
Post 14 of 232

Re: Notes on the philosophy of CUI

05-09-2005 07:24 AM in reply to: *R. Robert Bell
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
*R. Robert Bell
Post 15 of 232

Re: Notes on the philosophy of CUI

05-09-2005 07:32 AM in reply to: *R. Robert Bell
"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...")
*Jason Piercey
Post 16 of 232

Re: Notes on the philosophy of CUI

05-09-2005 07:44 AM in reply to: *R. Robert Bell
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.
Valued Contributor
76 Posts
0 Kudos
Registered: ‎03-03-2004
Post 17 of 232

Re: Notes on the philosophy of CUI

05-09-2005 08:02 AM in reply to: *R. Robert Bell
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
*Marc'Antonio Alessi
Post 18 of 232

Re: Notes on the philosophy of CUI

05-09-2005 09:42 AM in reply to: *R. Robert Bell
(progn(princ(vl-string-translate"7521463""!khTnsa""1234567"))(princ))
*Art Cooney
Post 19 of 232

Re: Notes on the philosophy of CUI

05-09-2005 10:36 AM in reply to: *R. Robert Bell
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.")

--
*R. Robert Bell
Post 20 of 232

Re: Notes on the philosophy of CUI

05-09-2005 11:02 AM in reply to: *R. Robert Bell
???

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?
Post to the Community

Have questions about Autodesk products? Ask the community.

New Post
Announcements
Are you interested in helping shape the future of the Autodesk Community? To participate in this brief usability study, please click here. Your time and input is greatly appreciated!