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]

I have a question concerning mouse button customization. I have done the menu loading as you have suggested and have realized that my Osnaps that used to pop up when the mouse wheel button was clicked, no longer does now that I have only partially loaded acad.mnu. When I had acad.mnu as the main menu, it worked fine. Is there a way around this so that I can 'get back' the Osnaps menu on the wheel button click?

[Anonymous]

(WOW - I finally made it to the bottom of this... What a great discussion. Tons of great info - thanks to everyone.)

So after reading all this, I think I have a general idea of how the basic set up should go.

But I am still not sure how this is all supposed to play out in my situation:

TOPIC ONE:
We are a consulting civil engineer firm. Many of our clients currently supply us with their own block libraries and menu files which obviously have been built in accordance with their standards.

Our current methodology is such that each client gets their own profile, with their corresponding menus and blocks in a Read Only folder on the server, then the profiles handle the pathing to the correct menu files, in conjunction with the Projectname variable to handle multiple specific projects under each Client's profile (each project has its own individual set of xrefs, deliverable sheets, etc).

So to "rebuild" everything to work with R2006, using Robert's philosophy, then basically (if I am actually getting this right):

1) each user gets their own Custom/Main.cui
2) a Client's standards would become the Enterprise.cui
- so far, so good -

but here is where I stumble:
3)Acad and Express now have to be partially loaded into every single client's enterprise.cui? To me, this seems somewhat unwieldy. But if it works, I guess I will take the time to set them all up that way.

TOPIC TWO:
If the correct Workspace is not auto-loaded based on the Profile at the launch of AutoCAD, then without some custom startup scripts or reactors, how do I set up R2006 so that, to get to a specific client's toolset, all a user would have to do is open the correctly profiled AutoCAD icon on their desktop?

Did I miss something? Or is there another philosophy for dealing with this sort of methodology?

TOPIC THREE:
Most of our client provided menus are simple block insertion routines (set layer, insert block, reset layer), or basic .lsp routines called from the corresponding .mnl file. As such, they are not "Commands", per se. So will these "menu items" be available to import simply because they are currently in an existing .mns file? And how does the conversion handle the .mnl file?

[Anonymous]

I'm glad you found the thread useful.

#1 Where you place Acad/Express is up to you. If you only have 5-6 profiles
to deal with and want to maintain RO for Acad/Express, then partial-load
under enterprise. However, if that irks you (or too many profiles) then I
would advise leaving Acad as main, then Express & Custom partial to that.
(That ought to make Bud happy!)

#2 I'm using a VBA event handler to watch over Workspaces. Unhappily, there
is no command switch for workspaces at the .exe/shortcut level, so this
makes things tricky for you. I assume that you have multiple shortcuts for
each specific profile? If so, look at making a script file to set WSCurrent
and use the /b command switch for the .exe.

#3 The .mnl is still useful for the CUI approach. If the .cui and the .mnl
are the same name, the .mnl will load along with the cui. Or you could use
the LISP node under the specific cui to load non-mnl based lisp files.

--
R. Robert Bell


wrote in message news:4916598@discussion.autodesk.com...
(WOW - I finally made it to the bottom of this... What a great discussion.
Tons of great info - thanks to everyone.)

So after reading all this, I think I have a general idea of how the basic
set up should go.

But I am still not sure how this is all supposed to play out in my
situation:

TOPIC ONE:
We are a consulting civil engineer firm. Many of our clients currently
supply us with their own block libraries and menu files which obviously have
been built in accordance with their standards.

Our current methodology is such that each client gets their own profile,
with their corresponding menus and blocks in a Read Only folder on the
server, then the profiles handle the pathing to the correct menu files, in
conjunction with the Projectname variable to handle multiple specific
projects under each Client's profile (each project has its own individual
set of xrefs, deliverable sheets, etc).

So to "rebuild" everything to work with R2006, using Robert's philosophy,
then basically (if I am actually getting this right):

1) each user gets their own Custom/Main.cui
2) a Client's standards would become the Enterprise.cui
- so far, so good -

but here is where I stumble:
3)Acad and Express now have to be partially loaded into every single
client's enterprise.cui? To me, this seems somewhat unwieldy. But if it
works, I guess I will take the time to set them all up that way.

TOPIC TWO:
If the correct Workspace is not auto-loaded based on the Profile at the
launch of AutoCAD, then without some custom startup scripts or reactors, how
do I set up R2006 so that, to get to a specific client's toolset, all a user
would have to do is open the correctly profiled AutoCAD icon on their
desktop?

Did I miss something? Or is there another philosophy for dealing with this
sort of methodology?

TOPIC THREE:
Most of our client provided menus are simple block insertion routines (set
layer, insert block, reset layer), or basic .lsp routines called from the
corresponding .mnl file. As such, they are not "Commands", per se. So will
these "menu items" be available to import simply because they are currently
in an existing .mns file? And how does the conversion handle the .mnl file?

[Anonymous]

Excellent, and thank you again.

[Anonymous]

I wanted to throw in another twist. Hopefully I'm not treading on old ground here. If so, just direct me to the discussion and I'll shut up.

Anyway, in preparation for an Autocad 2006 rollout, I have been structuring my CUI files like R. Bell had originally outlined and it has been working very well:

MAIN CUI = custom.cui
ENTERPRISE CUI = "group specific" cui, with acad.cui and acet.cui as partials under this.
Only allows users to edit custom, which is good.

I overlooked one important thing, though (which is better now than later since I'm still in testing!) Our "group specific" cui's are on the network, and the acad and acet are local to each workstation. Still works fine ... except for the fact that users with laptops are occasionally disconnected from the network. It is acceptable that in this case they will not have access to their group specific customization, but with acad and acet cui's as partials of it, they don't load either! And, you need those.

So, my modified approach is to make acad and acet partials of custom.cui instead. In this case, if the user really wanted to, they could get at the acad and acet cui's and edit them, but since they are partials of custom they are probably more likely to modify custom first. The main cui is more prominently displayed to the user in the CUI editor. I can live with that. And, the group specific cui has no partials under it, so if it can't load, everything else will (cause they are local).

This modified approach works fine now, except for another small issue. I am setting up workspaces in my group specific cui's, so that users can revert back to a "group specific environment" at any point. This involves turning on buttons and menus from acad and acet cui, which themselves are partials of custom.cui. They list as "unresolved" in the workspace. This has been posted a few months ago, but no solution was ever given. CUI hotfix for Autocad didn't solve it. It still seems to work, but I am uneasy that it lists it as "unresolved". Am I going to get bitten by this later? I still think this is the best approach now for my situation. The alternative would be to make acad.cui the MAIN and acet and custom partials of this. I could direct users to only edit custom, but you and I both know that someone will edit acad.cui. It is pretty easy to pull customization out of any cui now, but it would still be nice if I could segregate their customization to one file.

Any thoughts on this? Mr. Bell? Bud? Thanks for any feedback.

[Anonymous]

For the laptop issue... I highly recommend using XP's Offline Files feature.
The network files will automatically sync, and the network will "appear" to
be connected even when they are not connected.

I too, am unhappy with the "unresolved" issue. However, the data is there,
so I think it is just a bug in the editor.

I think making Acad.cui the main is going to lead to the issues you
mention... e.g. the users will *not* go thru the effort to make Custom.cui
the main just to add to their interface. It will all wind up in Acad.cui.
Bud would be happy with that, but as a CAD Manager, I don't want to deal
with the users complaints when their customizations disappear because I
upgraded their computer or software.

--
R. Robert Bell


wrote in message news:4929597@discussion.autodesk.com...
I wanted to throw in another twist. Hopefully I'm not treading on old
ground here. If so, just direct me to the discussion and I'll shut up.

Anyway, in preparation for an Autocad 2006 rollout, I have been structuring
my CUI files like R. Bell had originally outlined and it has been working
very well:

MAIN CUI = custom.cui
ENTERPRISE CUI = "group specific" cui, with acad.cui and acet.cui as
partials under this.
Only allows users to edit custom, which is good.

I overlooked one important thing, though (which is better now than later
since I'm still in testing!) Our "group specific" cui's are on the network,
and the acad and acet are local to each workstation. Still works fine ...
except for the fact that users with laptops are occasionally disconnected
from the network. It is acceptable that in this case they will not have
access to their group specific customization, but with acad and acet cui's
as partials of it, they don't load either! And, you need those.

So, my modified approach is to make acad and acet partials of custom.cui
instead. In this case, if the user really wanted to, they could get at the
acad and acet cui's and edit them, but since they are partials of custom
they are probably more likely to modify custom first. The main cui is more
prominently displayed to the user in the CUI editor. I can live with that.
And, the group specific cui has no partials under it, so if it can't load,
everything else will (cause they are local).

This modified approach works fine now, except for another small issue. I am
setting up workspaces in my group specific cui's, so that users can revert
back to a "group specific environment" at any point. This involves turning
on buttons and menus from acad and acet cui, which themselves are partials
of custom.cui. They list as "unresolved" in the workspace. This has been
posted a few months ago, but no solution was ever given. CUI hotfix for
Autocad didn't solve it. It still seems to work, but I am uneasy that it
lists it as "unresolved". Am I going to get bitten by this later? I still
think this is the best approach now for my situation. The alternative would
be to make acad.cui the MAIN and acet and custom partials of this. I could
direct users to only edit custom, but you and I both know that someone will
edit acad.cui. It is pretty easy to pull customization out of any cui now,
but it would still be nice if I could segregate their customization to one
file.

Any thoughts on this? Mr. Bell? Bud? Thanks for any feedback.

[Anonymous]

The Offline Files feature is a good (and obvious) idea, and hadn't thought of it as a way to solve this problem. I am hesitant to use it, because if the user forgets to do this they can't use Autocad (without some reconfiguration). I realize that once it's set it works every time, but I don't want the entire Autocad menu configuration dependent on it. And, I don't want to set up all users computers to do this. I will likely use my modified method, but then suggest they use Offline Files so that they can get their group specific customization when disconnected and let them set it on their own. If they don't, then they can still use vanilla Autocad and the Express Tools. Because we are now going to be using network licensing, there are going to be enough growing pains getting the users to borrow licenses when they disconnect.

I guess as long as the menus appear to work, I'll look past the "unresolved" listing in the workspaces. I think I'd rather do tthat then have acad.cui as the main menu file, for the reasons we both agree on.

Thanks for the input.

[Anonymous]

Have you looked at the CUI update posted by adesk 8/9/05?

http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=5571150&linkID=2475161

wrote in message news:4929597@discussion.autodesk.com...
I wanted to throw in another twist. Hopefully I'm not treading on old
ground here. If so, just direct me to the discussion and I'll shut up.

Anyway, in preparation for an Autocad 2006 rollout, I have been structuring
my CUI files like R. Bell had originally outlined and it has been working
very well:

MAIN CUI = custom.cui
ENTERPRISE CUI = "group specific" cui, with acad.cui and acet.cui as
partials under this.
Only allows users to edit custom, which is good.

I overlooked one important thing, though (which is better now than later
since I'm still in testing!) Our "group specific" cui's are on the network,
and the acad and acet are local to each workstation. Still works fine ...
except for the fact that users with laptops are occasionally disconnected
from the network. It is acceptable that in this case they will not have
access to their group specific customization, but with acad and acet cui's
as partials of it, they don't load either! And, you need those.

So, my modified approach is to make acad and acet partials of custom.cui
instead. In this case, if the user really wanted to, they could get at the
acad and acet cui's and edit them, but since they are partials of custom
they are probably more likely to modify custom first. The main cui is more
prominently displayed to the user in the CUI editor. I can live with that.
And, the group specific cui has no partials under it, so if it can't load,
everything else will (cause they are local).

This modified approach works fine now, except for another small issue. I am
setting up workspaces in my group specific cui's, so that users can revert
back to a "group specific environment" at any point. This involves turning
on buttons and menus from acad and acet cui, which themselves are partials
of custom.cui. They list as "unresolved" in the workspace. This has been
posted a few months ago, but no solution was ever given. CUI hotfix for
Autocad didn't solve it. It still seems to work, but I am uneasy that it
lists it as "unresolved". Am I going to get bitten by this later? I still
think this is the best approach now for my situation. The alternative would
be to make acad.cui the MAIN and acet and custom partials of this. I could
direct users to only edit custom, but you and I both know that someone will
edit acad.cui. It is pretty easy to pull customization out of any cui now,
but it would still be nice if I could segregate their customization to one
file.

Any thoughts on this? Mr. Bell? Bud? Thanks for any feedback.

[Anonymous]

Yeah, I tried that. Didn't solve the problem.

[pcchenard]

I have most everything working they way I would like but I still have custom toolbar button image problems when making toolbars for the vertical products. But here is my take on CUI's....because I have been fighting with CUI's since May myself.

Main and Enterprise CUI's are a great concept. BUT until Autodesk truely starts designing their programs to be run on a network with shared resources rather than as stand alone workstations this stuff will never work they way we all would like it to. For the life of me I don't understand why they don't design their products to install with certain things on a server as shared resources as the default and give an option if you need things installed as stand alone. They should be designing the product to run on a network and share certain things (CUI's being one of them), not making us cobble things together to get a network environment to work properly.

My 2 cents.

[Anonymous]

i am not sure if there has been a continuation of this discussion which would include issues fixed by 2006 service pack and which is more geared toward upgrading to 2007. i am not really interested in the 3d part of this release but instead am taking this year to try to straighten out our customizations. one thing i don't fully understand is the constant remphasis of maintaining a clean copy of the acad.cui. i thought they include a clean copy which is stored in program files. i know if i was a user i would surely like to be able to customize my acad toolbars. can't i copy all of the toolbars from acad.cui to the custom.cui and let the user customize away? i want to straighten this out on my new copy of 2007 before i distribute it to my users. one thing i saw in 2007 is that search path can be defined through the icon now. please tell me the purpose of this as autocad still like to keep it's menu in "the long path" and it recommends that i keep my custom menus seperate? i also noticed that in options now there is also a custom icon location in customization files. i see when i migrated it put all of my bitmaps in this folder. most of the time i am creating new icons for the enterprise file which will be stored on the server to share with others. wouldn't it make more sense to store them in the same folder where the enterprise is stored or have i missed the point? has anyone successfully upgraded and how would i setup my configuration to operate to work how i described above?

[Anonymous]

If you want to modify the Acad.cui stuff, go ahead. Simply leave it as the
main cui file.

--
R. Robert Bell


wrote in message news:5138381@discussion.autodesk.com...
i am not sure if there has been a continuation of this discussion which
would include issues fixed by 2006 service pack and which is more geared
toward upgrading to 2007. i am not really interested in the 3d part of this
release but instead am taking this year to try to straighten out our
customizations. one thing i don't fully understand is the constant remphasis
of maintaining a clean copy of the acad.cui. i thought they include a clean
copy which is stored in program files. i know if i was a user i would surely
like to be able to customize my acad toolbars. can't i copy all of the
toolbars from acad.cui to the custom.cui and let the user customize away? i
want to straighten this out on my new copy of 2007 before i distribute it to
my users. one thing i saw in 2007 is that search path can be defined through
the icon now. please tell me the purpose of this as autocad still like to
keep it's menu in "the long path" and it recommends that i keep my custom
menus seperate? i also noticed that in options now there is also a custom
icon location in customization files. i see when i migrated it put all of my
bitmaps in this folder. most of the time i am creating new icons for the
enterprise file which will be stored on the server to share with others.
wouldn't it make more sense to store them in the same folder where the
enterprise is stored or have i missed the point? has anyone successfully
upgraded and how would i setup my configuration to operate to work how i
described above?

[Anonymous]

robert i was having problems with setting this up at work so i went home and it setup prefectly there under this config

acad.cui (main)
express (partial in main)
custom (enterprise)

everything was working fine there so i copied my cuis and profiles for switching back and forth. i came here and did a reinstall and wiped out all the folders. I set it up the same way as home but when i go in to edit my enterprise i get this error. why do you think i am getting this error, any thoughts?

Application does not support just-in-time (JIT)
debugging. See the end of this message for details.

************** Exception Text **************
System.ArgumentOutOfRangeException: InvalidArgument=Value of '8' is not valid for 'index'.
Parameter name: index
at System.Windows.Forms.ImageList.ImageCollection.get_Item(Int32 index)
at Autodesk.AutoCAD.Customization.BitmapCache.GetImage(String resourceId, Boolean small, Boolean return_null)
at Autodesk.AutoCAD.Customization.BitmapCache.GetImage(String resourceIdSmall, String resourceIdLarge, Boolean small)
at Autodesk.AutoCAD.Customization.MainForm.getStandaloneOrCustomResourceDllBitmap(CUITreeNode node, String smallImageName, String largeImageName)
at Autodesk.AutoCAD.Customization.MainForm.populateToolbarPreview(Toolbar toolbar, CUITreeNode node)
at Autodesk.AutoCAD.Customization.MainForm.CustPage_TreeViewControl_ItemSelected(Object sender, TVCItemSelectedArgs e)
at Autodesk.AutoCAD.Customization.TreeViewControl.FireSelectedItemEvent(TVCItemSelectedArgs arg)
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.FireSelectedItemEvent()
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.SelectNode(TreeNode node, Boolean fireEvent)
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.OnStartSelect(TreeNode node)
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.OnBeforeSelect(TreeViewCancelEventArgs e)
at System.Windows.Forms.TreeView.TvnSelecting(NMTREEVIEW* nmtv)
at System.Windows.Forms.TreeView.WmNotify(Message& m)
at System.Windows.Forms.TreeView.WndProc(Message& m)
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.WndProc(Message& message)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
acdbmgd
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcdbMgd.DLL
----------------------------------------
msvcm80
Assembly Version: 8.0.50608.0
Win32 Version: 8.00.50727.42
CodeBase: file:///C:/WINDOWS/WinSxS/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd/msvcm80.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
acmgd
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/acmgd.DLL
----------------------------------------
AcDxUi
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcDxUi.DLL
----------------------------------------
AcDx
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcDx.DLL
----------------------------------------
AcDxUi.resources
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/en-US/AcDxUi.resources.DLL
----------------------------------------
AcMgdShared
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcMgdShared.DLL
----------------------------------------
AcLayer
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcLayer.DLL
----------------------------------------
AcLayer.resources
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/en-US/AcLayer.resources.DLL
----------------------------------------
AcCustomize
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcCustomize.DLL
----------------------------------------
AcCui
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcCui.DLL
----------------------------------------
System.Design
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Design/2.0.0.0__b03f5f7f11d50a3a/System.Design.dll
----------------------------------------
acmgdinternal
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/acmgdinternal.DLL
----------------------------------------
AcMNUParser
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcMNUParser.DLL
----------------------------------------
AcCustomize.resources
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/en-US/AcCustomize.resources.DLL
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Data
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------

************** JIT Debugging **************
Application does not support Windows Forms just-in-time (JIT)
debugging. Contact the application author for more
information.

[Anonymous]

You can't edit the enterprise cui file directly, so I assume you are
switching a profile, or moving custom.cui to main to do the edit?

--
R. Robert Bell


wrote in message news:5140260@discussion.autodesk.com...
robert i was having problems with setting this up at work so i went home and
it setup prefectly there under this config

acad.cui (main)
express (partial in main)
custom (enterprise)

everything was working fine there so i copied my cuis and profiles for
switching back and forth. i came here and did a reinstall and wiped out all
the folders. I set it up the same way as home but when i go in to edit my
enterprise i get this error. why do you think i am getting this error, any
thoughts?

Application does not support just-in-time (JIT)
debugging. See the end of this message for details.

************** Exception Text **************
System.ArgumentOutOfRangeException: InvalidArgument=Value of '8' is not
valid for 'index'.
Parameter name: index
at System.Windows.Forms.ImageList.ImageCollection.get_Item(Int32 index)
at Autodesk.AutoCAD.Customization.BitmapCache.GetImage(String resourceId,
Boolean small, Boolean return_null)
at Autodesk.AutoCAD.Customization.BitmapCache.GetImage(String
resourceIdSmall, String resourceIdLarge, Boolean small)
at
Autodesk.AutoCAD.Customization.MainForm.getStandaloneOrCustomResourceDllBitmap(CUITreeNode
node, String smallImageName, String largeImageName)
at Autodesk.AutoCAD.Customization.MainForm.populateToolbarPreview(Toolbar
toolbar, CUITreeNode node)
at
Autodesk.AutoCAD.Customization.MainForm.CustPage_TreeViewControl_ItemSelected(Object
sender, TVCItemSelectedArgs e)
at
Autodesk.AutoCAD.Customization.TreeViewControl.FireSelectedItemEvent(TVCItemSelectedArgs
arg)
at
Autodesk.AutoCAD.Customization.MultiSelectTreeview.FireSelectedItemEvent()
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.SelectNode(TreeNode
node, Boolean fireEvent)
at
Autodesk.AutoCAD.Customization.MultiSelectTreeview.OnStartSelect(TreeNode
node)
at
Autodesk.AutoCAD.Customization.MultiSelectTreeview.OnBeforeSelect(TreeViewCancelEventArgs
e)
at System.Windows.Forms.TreeView.TvnSelecting(NMTREEVIEW* nmtv)
at System.Windows.Forms.TreeView.WmNotify(Message& m)
at System.Windows.Forms.TreeView.WndProc(Message& m)
at Autodesk.AutoCAD.Customization.MultiSelectTreeview.WndProc(Message&
message)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
acdbmgd
Assembly Version: 17.0.54.0
Win32 Version: 17.0.54.0
CodeBase: file:///C:/Program%20Files/AutoCAD%202007/AcdbMgd.DLL

[Anonymous]

yes robert i'm aware of that and i setup a profile which makes the custom the main with no enterprise. i mentioned the profiles in my previous post. so why am i getting this error?

[Anonymous]

Is the folder where the icons are stored on the search path for AutoCAD?

--
R. Robert Bell


wrote in message news:5140958@discussion.autodesk.com...
yes robert i'm aware of that and i setup a profile which makes the custom
the main with no enterprise. i mentioned the profiles in my previous post.
so why am i getting this error?

[Anonymous]

yes i put all of my icons into the icons folders inside of "the long path" in application data. we normally keep our icons outside which is how i originally had them and pathed it that way. i encountered this problem and tried to move them into the long path but it's still not working. when i installed autocad i did not use the migration tool as i wanted to start with clean cuis. i installed it exactly as i did at home last night where it worked fine but now i get this. this was happening in my previous installation of 2007 at work by the way but it did intially work when i first installed. i must've corrupted something along the way but now sure how and how to get it back to how it was. thanks for helping me troubleshoot.

[Anonymous]

Did the computer at work have the .NET v2.0 beta installed? (Starting to
reach here...)

--
R. Robert Bell


wrote in message news:5141107@discussion.autodesk.com...
yes i put all of my icons into the icons folders inside of "the long path"
in application data. we normally keep our icons outside which is how i
originally had them and pathed it that way. i encountered this problem and
tried to move them into the long path but it's still not working. when i
installed autocad i did not use the migration tool as i wanted to start with
clean cuis. i installed it exactly as i did at home last night where it
worked fine but now i get this. this was happening in my previous
installation of 2007 at work by the way but it did intially work when i
first installed. i must've corrupted something along the way but now sure
how and how to get it back to how it was. thanks for helping me
troubleshoot.

[Anonymous]

ummm not sure about the.net v2.0 how would i find out? the message i posted here was the details of the message but the header of it reads as follows:

Unhandled exception has occured in a component in your application. If you click continue the application will ignore the error and attempt to continue.

Invalid Argument=Value of '75' is not valid for 'Index'.
Parameter name:Index.

The number is the different for each button I click on. Does this give you anymore clues?

[Anonymous]

Robert I do see that Microsoft .NET framework 2.0 is installed on my computer. Is this what you mean and if so should I uninstall this. If so this is a known conflict with 2007? I also have .NET 1.1 installed should I remove that too?