Using the one Custom.cui file across different products?

[jguest82179]

I am sure that I can't be the only person who has this problem, so hopefully someone can help me out here.

I have the responsibility of administering four different AutoDesk products, i.e. Inventor 10, ACAD Mechanical 2006, ACAD Electrical 2006, and Building Systems 2006. (Five instances of each)

What I would like to do is to create a single "Custom.cui" and apply it to all three AutoCAD based products. Can anyone tell me what things I need to take into consideration to achieve this? Or if it is even possible in the first place?

I have managed to bring one Custom.cui that was created in ACAD Mech and use it in Building Systems, at least for a little while anyway, but the way I did it wreaked havoc with things like workspaces etc. Which, when I thought about it for a bit, made sense. I just forgot that that info was included in the cui in the first place. Unfortunately it has now refused to let me modify it any further, though it has retained the changes on the screen - unlike ACAD Mech where the changes still appear in the cui but refuse to display in ACAD! :banghead:

[rkmcswain]

I can't speak on the ability for those different products to share a common menu, although I don't see why it would not work.

I use a lisp function to check to see if our partial menu is loaded, and load it if not. This function is called from the s::startup. It's the same function that we used in 2005 and earlier.

Per some suggestions, I have found that you need to create a dummy profile and set the custom menu as the "Main Customization File" in this profile. Switch to this profile when you need to edit your custom menu.

The menu loading lisp function runs at the first launch of AutoCAD, each user spends a little time getting his/her toolbar preferences setup, then saves the appropriate workspaces which of course include our partial menu.

[jguest82179]

I use a lisp function to check to see if our partial menu is loaded, and load it if not. This function is called from the s::startup. It's the same function that we used in 2005 and earlier.

Per some suggestions, I have found that you need to create a dummy profile and set the custom menu as the "Main Customization File" in this profile. Switch to this profile when you need to edit your custom menu.

Unfortunately we do not have any partial menus pre-existing from previous releases, otherwisde I would likely use the approach that you have described here. This site has recently gone from one seat of uncustomized 2000i to the mix described above, all running on floating network licences.

I have already set up the custom.cui and enterprise.cui files as described in another thread in this forum.

[rkmcswain]

Unfortunately we do not have any partial menus pre-existing from previous releases, otherwisde I would likely use the approach that you have described here. This site has recently gone from one seat of uncustomized 2000i to the mix described above, all running on floating network licences.

I have already set up the custom.cui and enterprise.cui files as described in another thread in this forum.

Ok, I guess my point was to forget the "main & enterprise" menu schemes, and just load your partial menu (custom.cui) on top of whatever is set up as the main menu.

[Gary.Orr]

The short answer is: No you cannot safely use one CUI file across multiple AutoCAD applications. Keep reading for the long answer.

Your issue derives from the fact that not all of the different programs have the same menus (or even use the same available CUI files). One of the things that are stored within the main CUI file (be it Custom, Acad, or etc.) is a list of all of the partial CUI files that are loaded.
The workspace then indicates which menus are visible from which CUI files and in what order (see other posts for the discrepency in this statement).

I manage Architectural Desktop (ADT), AutoDesk Building Systems (ABS), Land Desktop (LDT), Civil, Survey, and Civil 3d (C3d). I cannot use the same Main CUI file (be it custom or ...) for all of the above because I do not want to install LDT onto the ADT machines (etc, etc) to make the LDT CUI available for the main CUI in ADT (etc., etc.) . And even if I did, they wouldn't work for a host of other reasons.

Your CUI file kicks into Read-Only mode when it discovers an error such as that described above.

The best solution (in my opinion) is to have a seperate Custom CUI file for each application.

Gary

[rkmcswain]

The short answer is: No you cannot safely use one CUI file across multiple AutoCAD applications.
Gary

I still don't see anything to prevent you from loading ONE partial menu into several different BASE menus.

Example:

MAP uses acmap.cui as the Main Customization File
LDT used land.cui as the Main Customiztion File

I have a single copy of our custom.cui loaded as a partial menu in both applications with no problem. This partial menu does not know or care to which base menu it is attached.

Thanks for your input.

[Gary.Orr]

We're working under two different assumptions.

I have been setting my CUI files up under the prevailing (or at least seemingly so) method of using my Custom.cui as my main CUI file, then adding all of the AutoCAD CUI's and our company CUI's as partials.

My answer was tainted with this approach.

My configuration is:
The main cui file is Custom.CUI and resides in a network location private to the user.
Partial CUI's are
Acad.cui
ADT.cui (or other program based)
Common.cui aka "EnterpriseCUI" (tools for all disciplines)
Architecture.cui (or other discipline based)
Express.cui
etc., etc.

A default workspace is then set up in the custom.cui file for the prevailing menu and toolbar preferences for that discipline. Since the main cui (Custom.cui) holds reference to which partial cui's are loaded this approach prevents one "custom.cui" from being used.

Based upon the second post from jguest:

I have already set up the custom.cui and enterprise.cui files as described in another thread in this forum.

I made the assumption that jguest was working under this same scenario. If not then I may have taken you (jguest) down a "wrong" path for your specific usage.


The clarification would be as follows:
If you are trying to create one Custom.CUI file for all users to use as the main CUI file (providing them with a common starting point), then the answer is NO.
If you are trying to create a partial company cui that users can access, then the answer is YES.


Does this help?
Gary

[RobertB]

I'm going to chime in here, in addition to the excellent comments already posted.

My "Notes" thread fails to take into account multiple verticals. In that 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. <blech>

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

My sketchy framework 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 am replicating the substance of this post in the "Notes" thread.)

[Gary.Orr]

Robert,
Isn't your "Notes" thead at the "Other" forum?
http://discussion.autodesk.com/thread.jspa?messageID=4859344

[RobertB]

Yes. I actually started it here, and duplicated it there.

[Gary.Orr]

The mess that you indicate in the last paragraph is about my only hope at this point. I've been beating the concept around for a while and it's starting to become somewhat stable in my poor 'ole 'ead.

I'm even beginning to wonder at the need of a Enterprise.cui.

I'll try repost after I've actually applied the concept across all of the configurations. It might be awhile...

[RobertB]

The mess that you indicate in the last paragraph is about my only hope at this point. I've been beating the concept around for a while and it's starting to become somewhat stable in my poor 'ole 'ead.

I'm even beginning to wonder at the need of a Enterprise.cui.

I'll try repost after I've actually applied the concept across all of the configurations. It might be awhile...Well, I like the idea of an enterprise cui scheme, although network security was fine enough for me for the last 15 years.

Yes ,please report back when you have more info! I've been in a bit of a holding pattern too.

[jguest82179]

One of the things that are stored within the main CUI file (be it Custom, Acad, or etc.) is a list of all of the partial CUI files that are loaded.
The workspace then indicates which menus are visible from which CUI files and in what order (see other posts for the discrepency in this statement).

This makes a lot of sense now that you've pointed it out. I hadn't thought about that angle.


Your CUI file kicks into Read-Only mode when it discovers an error such as that described above.

And this might explain why I can no longer make any changes to my ABS menus.

Thanks for your help, it has cleared a few things up for me. Still working on it of course, but at least I know I'm not the only one battling this issue.

[Gary.Orr]

On a sidebar,
How do I set up a watch in this AUGI forum? I'm so used to using Outlook Express for my newsgroups that I feel completely lost...

Nevermind, Found it I subscribe to this thread...

[Mike.Perry]

On a sidebar,
How do I set up a watch in this AUGI forum? I'm so used to using Outlook Express for my newsgroups that I feel completely lost...Hi

Please refer to the following...

How do I subscribe to a forum? (http://forums.augi.com/faq.php?faq=vb_board_usage#faq_new_faq_item5)

Have a good one, Mike

[Mike.Perry]

Hi

Plus you can subscribe to individual threads... within the thread you want to subscribe to, look under "Thread Tools" drop down menu, located at the top of the thread (refer to screen capture)

Have a good one, Mike

[jguest82179]

OK, I think it might help (me, at least) if I explain what I'm trying to achieve and why I think I have a need for a single Custom.cui across multiple verticals.

As I said earlier I support 2x ACAD Elec, 2x ACAD Mech, and 1x ABS. These are all network licenced, and all apps are install across all five machines. This is to give the maximum flexibility in our office scenario.

The problem is that different users need different apps at different times. Therefor the license that is available to me to do development work is not always for the same app - hence my wanting to use a single 'Custom.cui' file across various vertical apps.

What my goal, and my approach to acheiving that goal are, is as follows:

My goal is to have each app on each machine with a basic functionality set (i.e. the minimum functionality of that particular vertical app) plus an additional set of tools that help enforce our standards. A fairly common approach, I would think.

My approach to this has been (on my machine only so far, as none of it is ready to roll out to the users):

Starting with ACAD Mech, I made the "AcadM.cui" file my enterprise cui file (basically so as I couldn't stuff it up whilst learning the new system), and I made a "Custom.cui" to be my main customisation file.

I did this with the intention of developing the necessary menus, toolbars, etc. in this small custom.cui and then transferring these customizations into the "Acadm.cui" file when I had them ready to roll out.

I was then going to load this modified "Acadm.cui" file as the users Enterprise cui and give them a blank "Custom.cui" as their main customization file.

My understanding is that this approach would give them the original Acad Mech tools, plus my cutsom menus etc, whilst still allowing them to make any of their own personal customizations without the risk of losing the 'Standard' tool set. Is that correct so far?

The real problem arose for me when the Acad Mech licence was not available and I needed to continue working on the customizations. I tried to bring the "Custom.cui" file across to ABS and, after a little reconfiguring of workspaces (which I hadn't realised were included in the cui file), I got it to appear properly in ABS and was able to continue my customizing,.....for a while at least. It now refuses to let me make any further changes.

OK, so, now that I realise that I can't point all three apps at the one "Custom.cui" file to perform my customisations, I guess that my revised approach would have to be to try to keep hold of one licence for as long as it takes to make the necessary customizations, and then use the "Transfer" tab in the CUI to bring the menus etc. into each of the other apps. Is that correct?

Also, If I am heading in the wrong direction with any of this could somebody please point it out soon so as I can change direction before I go too far? Thanks.

[RobertB]

I think you thought things out ok, you just didn't follow through on your own setup. If you were modifying the custom cui that you intended for AcadM, why in the world did you try to edit it further in ABS?! :screwy:

A downside that I see is what you want to do with common items, that are not vertical-specific. Those items I would place in a common cui that would partial-load into each vertical's cui.

[jguest82179]

I think you thought things out ok, you just didn't follow through on your own setup. If you were modifying the custom cui that you intended for AcadM, why in the world did you try to edit it further in ABS?! :screwy:

Why? Simple, to get the job done! The AcadM licence was not available, the ABS licence was, so I used that instead.

The menus etc. that were in the custom.cui that I was editing with AcadM are actually intended for all verticals, not just specific to AcadM. It hadn't occured to me that the workspace was also included in the custom.cui and so might cause problems


A downside that I see is what you want to do with common items, that are not vertical-specific. Those items I would place in a common cui that would partial-load into each vertical's cui.

I understand what you are saying here, but I can't see how to implement it. I get the 'Partial Load' bit no worries, the bit that I don't get is this:

"How do I create this 'Common.cui' if whatever app I create it in will add its own information to the cui file and therefore create issues when it is opened in a different vertical?"

[RobertB]

There is no reason why the common.cui needs to refer to any specific vertical. The issue is that everyone dealing with cui files and workspaces needs to think in a global fashion, considering multiple verticals if they must support them. So if you want common items between all verticals, obviously that common cui cannot contain workspaces and must be partially loaded into another cui, be it a vertical or other cui. (Since it must be partially loaded, workspaces in that file are wasted anyway.) Since I am undecided on if a framework or vertical cui should be used, I cannot offer much help there. That would be a case of "what fits you best".

Because the workspaces need to reside in either the main or enterprise cui and workspaces are the only way to control display of the vertical's menus/toolbars the requirement for common items being in a separate partially loaded cui once again becomes evident.

I'm sorry if this makes it sound like you've got more work, but that's exactly what you've got!

Further questions to ask yourself:

Do I want to use the vertical cui as the enterprise, partially loading the common.cui?
If so, how will I deploy each vertical's modified cui?
If not, you will need a "framework" cui to hold the workspaces, and partially loaded vertical & common.cui files.

This is a complex issue, with no easy answer, I'm afraid.

[Gary.Orr]

aaaahhhhh, progress.

The answer to the question:

"How do I create this 'Common.cui' if whatever app I create it in will add its own information to the cui file and therefore create issues when it is opened in a different vertical?"

Use Robert's approach (it's somewhere in his dissertation)
Create a profile in each of the applications on your desktop;
Name that profile Vanilla Acad;
Load the Custom.cui as the Main; (from the same location for all verticals)
Load the Common.cui as the Enterprise;
Load the Acad.cui as a partial cui file; (all of the apps have the Acad.cui included even if they do not utilize it).

*DO NOT LOAD* the Vertical cui at all;

Do all of the desired "Common Setup";

(From this point on you will lose all commonality so wait until you're pretty comfortable with the Common.cui)

Upon completion create copies of the Custom.cui for each vertical as Custom-V.cui;
In the default profile of each vertical change the main CUI to the appropriate Custom-V.cui;
In each vertical load the <vertical>.cui;
Finalize the workspaces in each Custom-v.cui;

The above would allow you to launch any vertical application as Vanilla AutoCAD for NON vertical specific work.

The worst that will happen is that you will loose a couple of days potential production time and we all know that our Bosses are fine with that ;-)

Gary