Topic: Sharing partial MNS in 2007

[dan19936]

I'm setting up basic customization for an office on 2007 (and I'm not). I've got access to an installation on a laptop for testing, but won't be using it regularly at all. The customization is a MNS file with a drop down & one toolbar. I've got the MNS to load fine in 2007 on the laptop, however I'm concerned about having the MNS shared across the network for all stations because of the CUI file that is created. Is there a problem having those files shared (with the assumption that users will not be modifying the toolbar or menu).

Thanks,

Dan

[Joe Burke]

Dan,

I don't know if this will help and I'm no CUI expert.

When you load filename.mns the first time, filename.mnr and filename.cui are created. After that, there is no link between filename.mns and the other two files. An edit to filename.mns will not update the interface.

Assuming you want to continue to edit/modify using the filename.mns file, rather than edit the .cui file itself in the CUI editor, do this. Modify the .mns as needed. Unload and reload the .mns file. That will update the related .mnr and .cui files.

HTH

[dan19936]

Joe,

Thanks - I'm familiar with MNS vs. MNRs and have successfully figured out how to modify & reload as required. I'm concerned that autocad won't like multiple computers pulling the same MNR (or will it be the CUI?) from the network. For instance if someone makes a change to their local CUI, will it affect the network shared MNR/CUI? I'm trying to avoid learning about full CUI implementation and enterprise CUIs since I have limited time and limited access to their network. Also since I have limited access I'm trying to find out if I need to make the plunge before I deploy the customization. (Which at this point is one drop-down menu w/two items, a toolbar, an s::startup, and a lisp/DCL for dimension standards setup.)

Dan

[Joe Burke]

Dan,

The .mnr file is updated when the .cui file is modified using the CUI editor.

I'm not sure what you mean by, "if someone makes a change to their local CUI". I was under the impression you wanted to put your custom CUI file on a server, so all machines would access it from there. Maybe you mean if someone makes a change to their local ACAD.CUI file? If so, I don't think that would affect your custom CUI on the server.

Obviously what would be a concern is someone modifying your custom CUI on the server with the CUI editor. That would affect all users, not good.

I'm sure others here can offer better advice than myself. My experience with the questions you are asking is limited.

[dan19936]

Maybe you mean if someone makes a change to their local ACAD.CUI file?

Yup.

If so, I don't think that would affect your custom CUI on the server.

OK good, thanks for the response. I'll postpone diving into CUIs unless I have problems.

Dan

[sinc]

Maybe you mean if someone makes a change to their local ACAD.CUI file?

Yup.

As a general rule, you should try to avoid editing the ACAD.CUI file.

Part of the whole goal of the CUI was to keep everyone from having to do so much updating of customization between versions.  That's why they implemented the Partial CUI strategy.  Autodesk itself will update things like ACAD.CUI between versions, which means that you will lose your customizations if you change that file.

In general, the ACAD.CUI file is intended to be a Partial CUI that you never edit.  Then you edit a custom CUI that links in the ACAD.CUI as a partial.

Autodesk also intended company-wide information to be placed into an Enterprise CUI, and then each user could have their own custom Main CUI that they could edit as they wished.  However, Autodesk's implementation has been TERRIBLE, and this doesn't really work.  You can sort-of get it to sort-of work in some ways, but it is a huge headache.  I've given up trying to use Enterprise CUIs until 2008, because the software has so many problems that I've found them to be too big a time-waster, and regardless of what you try, you probably won't be able to get them working right...

[CADaver]

Part of the whole goal of the CUI was to keep everyone from having to do so much updating of customization between versions.  That's why they implemented the Partial CUI strategy. 

Menuloading additional custom menus worked just fine for that, so far, much better than the CUI debacle.  I'm not sure what precipitated the switch, but that wasn't it.

Autodesk also intended company-wide information to be placed into an Enterprise CUI, and then each user could have their own custom Main CUI that they could edit as they wished. 

Again menuloading worked quite well for that, so far, much better than the CUI debacle.

[Joe Burke]

Maybe you mean if someone makes a change to their local ACAD.CUI file?

Yup.

As a general rule, you should try to avoid editing the ACAD.CUI file.

Part of the whole goal of the CUI was to keep everyone from having to do so much updating of customization between versions.  That's why they implemented the Partial CUI strategy.  Autodesk itself will update things like ACAD.CUI between versions, which means that you will lose your customizations if you change that file.

In general, the ACAD.CUI file is intended to be a Partial CUI that you never edit.  Then you edit a custom CUI that links in the ACAD.CUI as a partial.

Autodesk also intended company-wide information to be placed into an Enterprise CUI, and then each user could have their own custom Main CUI that they could edit as they wished.  However, Autodesk's implementation has been TERRIBLE, and this doesn't really work.  You can sort-of get it to sort-of work in some ways, but it is a huge headache.  I've given up trying to use Enterprise CUIs until 2008, because the software has so many problems that I've found them to be too big a time-waster, and regardless of what you try, you probably won't be able to get them working right...

Personally I figured I would not fully understand the why of CUI until I upgrade from 2006 to 2007. Which I nave not done yet.

I *thought* the reason for it was pretty much the opposite of what you said above. That a newer version would look at the previous version CUI and intelligently incorporate what applies. Otherwise, what's the point?

Of course, I may be dead wrong...

[sinc]

I *thought* the reason for it was pretty much the opposite of what you said above. That a newer version would look at the previous version CUI and intelligently incorporate what applies. Otherwise, what's the point?

Of course, I may be dead wrong...

The main idea behind the CUI is that it incorporates ALL customizations into a single place, with a coherent GUI to modify the whole shebang.  Not just menus, but EVERYTHING.  In theory, it's a great idea.  The old way had customizations sprinkled through lots of files that had to be manually-edited with text editor, and it was something of a pain to edit files and keep everything synchronized, since pieces were sprinkled through so many files in so many different directories.

A couple years back, someone at AUGI wrote a huge 3-part article explaining how to "easily" move all customizations from one installation from another.  It involved scripts and lots of headache, but it was the easiest way, prior to the CUI.

Unfortunately, Autodesk's implementation of the CUI has been atrocious.  So people who had a handle on how to use MNL files before are now angry, because the CUI doesn't work very well.  In theory, if they ever get the code written right, it will be very easy to customize ALL aspects of Autocad from a single GUI, and everyone will be very happy.  But in the meantime, we are all stuck suffering immensely...

[Joe Burke]

I would suggest, speak for yourself, rather than assume everyone agrees with you.

I'm not "suffering immensely" over this stuff. Maybe "drama queen" rings a bell? 

[sinc]

I would suggest, speak for yourself, rather than assume everyone agrees with you.

I'm not "suffering immensely" over this stuff. Maybe "drama queen" rings a bell? 

No, I greatly doubt "drama queen" is correct.

But you're probably right.  It causes the most problems for people who a) try to use partial CUIs, b) try to use Enterprise CUIs, and c) use Vertical Apps (such as Land Desktop, etc.).  If you don't fall into any of those categories, you don't see the worst of the problems, and you avoid most of the headache.  Unfortunately, ALL of them apply to us.

And if you regularly need to use more than one vertical app, it gets much worse...

[CADaver]

The main idea behind the CUI is that it incorporates ALL customizations into a single place, with a coherent GUI to modify the whole shebang.  Not just menus, but EVERYTHING.  In theory, it's a great idea. 

yep... in theory

The old way had customizations sprinkled through lots of files that had to be manually-edited with text editor, and it was something of a pain to edit files and keep everything synchronized, since pieces were sprinkled through so many files in so many different directories.

So far it was MUCH easier than attempting multiple client customized CUI's running.

A couple years back, someone at AUGI wrote a huge 3-part article explaining how to "easily" move all customizations from one installation from another.  It involved scripts and lots of headache, but it was the easiest way, prior to the CUI.

Network installs solved that

Unfortunately, Autodesk's implementation of the CUI has been atrocious.  So people who had a handle on how to use MNL files before are now angry, because the CUI doesn't work very well. 

"very well"?? try "at all"

In theory, if they ever get the code written right, it will be very easy to customize ALL aspects of Autocad from a single GUI, and everyone will be very happy. 

Why should I be happy about being forced to use a bloated GUI to change a button prompt?  

But in the meantime, we are all stuck suffering immensely...

or banging away at it until it works or R2010 comes out.

[sinc]

Why should I be happy about being forced to use a bloated GUI to change a button prompt? 

I agree that Autodesk's implementation has been terrible.  But if the CUI weren't so buggy, and so ssssslllloooowwww, then you may get a different impression.  A well-designed GUI is ALWAYS easier to use than digging through a bunch of configuration files, all located in different directories.

If you disagree, then I would hazard that is only because you are very familiar with the "old" way.  Try to imagine it from the perspective of someone who doesn't have years of experience customizing Autocad.  If the GUI worked well, then someone with very little experience in Autocad could do customizations that it used to take years of experience in order to achieve.  I would say that is a very good change.  Any change that makes a task much easier to learn and much easier to perform is worth it.  Unfortunately, the current implementation of the CUI is so bad that, at this point, it is arguable that it is any improvement, but I still hold out hope that Autodesk will eventually work it out...  Hopefully before 2010, but judging from what they've done so far, you might even be optimistic in your time estimate...   

[CADaver]

A well-designed GUI is ALWAYS easier to use than digging through a bunch of configuration files, all located in different directories.

I wouldn't know, so far I have never seen a "well designed GUI".  So far all I've seen is a bloated buggy interface that eats a usable seat just for customization.

If you disagree, then I would hazard that is only because you are very familiar with the "old" way.  Try to imagine it from the perspective of someone who doesn't have years of experience customizing Autocad.  If the GUI worked well, then someone with very little experience in Autocad could do customizations that it used to take years of experience in order to achieve.  I would say that is a very good change. 

I'd say you're living in a dreamworld.  Look at the real world and imagine someone with little experience in AutoCAD attempting personal customizations on a networked system using the current GUI.  HINT: Experience is a GOOD thing.

Any change that makes a task much easier to learn and much easier to perform is worth it. 

When that happens, let me know.

Unfortunately, the current implementation of the CUI is so bad that, at this point, it is arguable that it is any improvement, but I still hold out hope that Autodesk will eventually work it out...  Hopefully before 2010, but judging from what they've done so far, you might even be optimistic in your time estimate...   

Unfortunately for Autodesk it may be too little too late.  Those of us forced to live in a production world have already began to seek out (and find) alternatives for AutoCAD.  If I have to live with a bloated heavy-handed interface, why not get some bang for the buck.  Our structural guys are already moving away in favor of big guns like Tekla, that provide fabrication details dang near free.

[sinc]

If you disagree, then I would hazard that is only because you are very familiar with the "old" way.  Try to imagine it from the perspective of someone who doesn't have years of experience customizing Autocad.  If the GUI worked well, then someone with very little experience in Autocad could do customizations that it used to take years of experience in order to achieve.  I would say that is a very good change.

I'd say you're living in a dreamworld.  Look at the real world and imagine someone with little experience in AutoCAD attempting personal customizations on a networked system using the current GUI.  HINT: Experience is a GOOD thing.

I think I very clearly said that the current GUI is a terrible mess.  It's difficult for ANYONE to use this thing, except in a basic fashion.

But I really don't think I'm living in a dream world.  Since I have a lot of exprience with Unix systems (Sun systems, NeXT, MacOSX), I actually have a lot of exprience with well-designed software.  That's one of the reasons I find Windows so frustrating.  If it weren't for Autocad, I probably wouldn't be using Windows at all.

I also have a lot of exprience as a software designer, designing easy-to-use GUIs.  In my opinion, every time a user has to refer to the help, it illustrates another aspect of the program that might potentially benefit from redesign.  There is really no good reason that someone with a lot of experience in construction should need to spend years learning to use the program that's supposed to make life easier.  Sure, they need to spend years learning the biz, but they shouldn't need to spend years learning the software.

Well-designed software is very easy to use, assuming the user fully understands the problem space.  The user should merely have to think "I want to accomplish this task...", and it should be very easy to just perform the task.  It's impossible to completely eliminate the need for Help, but it SHOULD be possible to eliminate lengthy training.  There is actually an awful lot of software that is intuitive and easy-to-use, just not a whole lot of it on the Windows platform.  People who have spent their whole life using Windows don't know what they're missing.

OK, so maybe you're right, and I am living in a dream world.  If Windows has been around for over 20 years and it's STILL like this, then there's no reason to hold out hope that it will change.  Maybe Apple will eventually come to their senses, and make their OS so that it can run on ANY machine that currently runs Windows, rather than just on the limited hardware they currently support.  Then it's possible that more and more people will start to see the REAL differences between the two, rather than simply saying that OSX is basically Windows with eye candy (a VERY wrong analysis).