See the top rated post in this thread. Click here

Results 1 to 10 of 103

Thread: Notes on the philosophy of CUI

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    The Silent Type RobertB's Avatar
    Join Date
    2000-01
    Location
    Seattle WA USA
    Posts
    5,859
    Login to Give a bone
    2

    Lightbulb Notes on the philosophy of CUI

    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.

    Edit: I now recommend creating a new blank CUI via the transfer tab. You can save that to Custom.cui (overwrite) if you don't have any items in there. Later parts of this thread explain why.

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

    Edit: If you want to use Custom.cui, and it is currently empty, use the Transfer tab to SaveAs the blank cui on the right pane to Custom.cui, overwriting it.
    • 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.
    Last edited by RobertB; 2006-08-16 at 11:04 PM. Reason: Added infor regarding Custom.cui

Similar Threads

  1. General Notes/ Plan Notes/ Sheet Notes
    By ubviswa in forum Revit Structure - General
    Replies: 2
    Last Post: 2012-12-04, 05:32 PM
  2. Specific Demo Notes, Plan Notes etc.,
    By tmcguire17 in forum Revit Architecture - General
    Replies: 6
    Last Post: 2009-03-13, 06:17 PM
  3. Keynote philosophy
    By christo4robin in forum Revit - In Practice
    Replies: 5
    Last Post: 2006-05-02, 02:37 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •