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