mnc file doesn't include all info from mns file

I have created a custom .mns file with six commands that load different layers.
After a while, upon autocad startup, two of the six buttons are gone. The .mns file is ok, but the mnc file is missing the info for the two buttons. Does this have to do with the length of the macros created?
I have tried eracing the mnc file and reloading the mns file. when i do, the mnc file is missing the same info as before.
What am I missing?

 

Lots of user will disagree with me on this, but here is what I do:
Make my *.mnu file
Whatever name I gave it (*) I then copy acad.mnc, acad.mns and rename them with the name you gave the mnu file.
That way, when you load the new mnu file, it will automatically redefine the newly name mns and mnc files.

 

Try making it an .MNU file, and loading that, which in the process will
compile both .MNS and .MNC (and maybe some other?) files that will all
"match."

Kent Cooper, AIA

..mns file is ok, but the mnc file is missing the info for the two buttons.
Does this have to do with the length of the macros created?

the mnc file is missing the same info as before.

 

The mnu fle extension makes no difference whatsoever. The mnu file is not used by Acad in any way, unless you force it to be used by explicitly loading an mnu file and ignoring the safety warning you get when you do so. The default is to load an mns file, where no warning is needed.

The mnc and mnr are compiled from the mns (Menu Source) file. That and the associated image bmp files are the only ones referenced by Acad in compilation. The mnu is an obsolete file extension, left over from olden times for no reason but backward compatibility and, as Mark Middlebrook says, to cause people unnecessary confusion.

The mns file is the source from which the menu is compiled. If you force Acad to use an mnu instead, here is what it does. It strips all comments out of the mnu, copies it as mns, and then uses the mns as the source for compilation. An mnu serves no purpose whatsoever except to be converted to an mns. If you completely eliminate all mnu files from your system, it will make no difference at all except for three things. One, you eliminate the possibility of destroying your onscreen toolbar customizations, which happen in the mns (because, again, Acad does not use the mnu file in any way). Two, you are free to make informative comments in the mns file and they won't be lost. Three, anytime you make a change in the mns, the menu will automatically recompile next time you start Acad, without any need to unload or reload anything.

The toolbar images are kept in the mnr, not the mns. What is happening is that you're modifying the toolbars, and they look good at the time, but the bmp files associated with the buttons are not on your search path. The mnc and mnr files are recreated when you make the toolbar change, and if the bmp's aren't on the path then the mnr lacks the images. But the mnr doesn't get reloaded until you restart Acad the next time, then you see that the buttons are missing.

First, close AutoCAD. Then look in the mns file with a text editor and write down the names of the bmp image files. Then search your computer for those files, and move them into a folder on your search path. Then delete both the mnc and mnr files, to force a recompilation from the mns. Then start Acad. The menu will recompile automatically, you don't need to reload anything.

If the bmp files are on your Acad search path, and they match the filenames in the mns, and if you mns doesn't contain other errors that prevent normal compilation, then your buttons will be back.

 

Hi Tom,

In defence of the MNU file:

I'm not disagreeing with your analysis, just defending use of an MNU file:

1 It keeps your comments: As a developer of menu files that is a serious
advantage
2 It keeps the Tool tip keys sorted that way you put them. (I put them in
Alphabetical order to help find them.) When the MNS file is created from the
MNU, or from a variation of one you made, the tool tip keys get sorted by a
ramdomisation function, so that you can never be sure whether they are
included, nor can you find the one you want.

3 It also provides a way to make sure a user can revert to the default, if
they have done a half baked customisation of the MNS file and destroyed it.
Many users resolve problems with their Mouse operation by reloading the MNU
file after the MNS has been corrupted.

Two other menu items you didn't mention are:

1 the MenuName.DLL which if in the same directory as the MenuName.MNS
(or MNU) file allows all your bitmaps to be found from the DLL. Check out
Kenny Ramage's AfraLisp site for lots of discussion on this file and how to
create them.

2 the MenuName.MNL file which can contain lisp code defining functions
which can be called from the menu files. It can also run lisp functions and
load other software when the menu is loaded. This file, to me, seems to be
the forgotton power of AutoCAD menus and I'm suprised we see so many
references in these newsgroup to Acad.lsp, AcadDoc.lsp etc. etc, when
relevant lisp code can be readily loaded via the MNL file.


--


Laurie Comerford
CADApps
www.cadapps.com.au

used by Acad in any way, unless you force it to be used by explicitly
loading an mnu file and ignoring the safety warning you get when you do so.
The default is to load an mns file, where no warning is needed.

associated image bmp files are the only ones referenced by Acad in
compilation. The mnu is an obsolete file extension, left over from olden
times for no reason but backward compatibility and, as Mark Middlebrook
says, to cause people unnecessary confusion.

Acad to use an mnu instead, here is what it does. It strips all comments out
of the mnu, copies it as mns, and then uses the mns as the source for
compilation. An mnu serves no purpose whatsoever except to be converted to
an mns. If you completely eliminate all mnu files from your system, it will
make no difference at all except for three things. One, you eliminate the
possibility of destroying your onscreen toolbar customizations, which happen
in the mns (because, again, Acad does not use the mnu file in any way). Two,
you are free to make informative comments in the mns file and they won't be
lost. Three, anytime you make a change in the mns, the menu will
automatically recompile next time you start Acad, without any need to unload
or reload anything.

that you're modifying the toolbars, and they look good at the time, but the
bmp files associated with the buttons are not on your search path. The mnc
and mnr files are recreated when you make the toolbar change, and if the
bmp's aren't on the path then the mnr lacks the images. But the mnr doesn't
get reloaded until you restart Acad the next time, then you see that the
buttons are missing.

write down the names of the bmp image files. Then search your computer for
those files, and move them into a folder on your search path. Then delete
both the mnc and mnr files, to force a recompilation from the mns. Then
start Acad. The menu will recompile automatically, you don't need to reload
anything.

filenames in the mns, and if you mns doesn't contain other errors that
prevent normal compilation, then your buttons will be back.

 

but why did they disappear in the first place?

 

Are the buttons missing entirely from the toolbar, or is it just the button icon?

 

Thanks, Laurie. We're somewhat on the same wavelength, I think. The mnu file
isn't necessarily a bad thing, if the customizer uderstands it.

On your first two points, yes, comments remain in the mnu after they have
been stripped out to form the mns file, and tip keys remain there as they
were entered. However, if the mns rather than the mnu is customized, both
things are left alone also. Comments you place in the mns remain there, and
tip keys are left alone. The code mangling only occurs when you edit the mnu
and let Acad spit out the mns. In other words, editing the mnu is what
causes these issues. If you customize/maintain the mns directly, these
problems disappear. Also, by editing the mns directly, the whole problem of
losing mousey onscreen customizations goes away -- all edits occur in the
same file and all comments stay there.

The third point, use of the mnu as a backup, is a valid one, assuming the
user is knowledageable about these things. Nearly all user personalizations
are done mouse-wise -- few of them ever care to edit the menu code. The
procedure I recommend is to do whatever you want in your personal partial
menu (thereby changing the mns), and when it works properly, you can copy
the file to an mnu extension. Then it can be used as a fallback if the next
mousey customization fails. But if the user isn't doing this after each
customization, the reversion will probably carry them back way further than
they want, and they'll lose most of their customizations. As a backup, it's
quicker and easier in Explorer to just right-drag the mns file into the same
folder and pick "copy here." There's no particular need to rename it to mnu
at that point -- a "copy of my.mns" is just as effective a backup as a
"my.mnu." I'd rather they had 7 different recent "copy of" mns files than
one old mnu. More chances of getting back their customizations without their
starting all over again. I provide users with a miniature "starter" toolbar
for their own personalizations, in the form of an mns file. I don't give
them an mnu at all, because if they ever needed to revert all the way back
to this, they can copy down the starter mini-mns from the server again. They
can back up their menu customizations by either method above.

I agree that a DLL would be a slicker way to keep images together. I've
glanced at these discussions and thought it might be an asset for our
company-standard menus, but not something I need to impose on users for
their personal partial menus. I'll revisit this (if I can find it on Kenny's
site again) and possibly reconsider.

Finally, I couldn't agree more about mnl files. Our entire suite of
customizations is initialized by an mnl associated with the company-standard
partial menu. This leaves the acad(doc).lsp files open for other uses. To
me, the insistence on using these files is backward looking, much like the
insistence on customizing an mnu even though the file type was effectively
dropped by Acad quite a few versions ago. Even worse, whenever the subject
comes up, a suprisingly large faction will insist on setting acadlspasdoc=1
to defeat the very useful distinction between the two files.

 

See your _other_ thread on this same topic (man, I hate that.)

 

See, here is the problem. Ive checked all the things written above.

**the menu works for a while, through several autocad and computer reboots. Then, randomly, the toolbar is missing two buttons. I haven't changed anything. Whatever changed, Autocad caused it (or the CAD gremlins)
all the bmps are in the right place and referenced correctly in the mns file. Ive tried deleting all but the mns file and starting autocad to recompile the menu (after completely unloading the custom menu through the menuload command), but the new mnc files have the same problem.
The only thing i did to fix the problem was to delete the toolbar through the cad gui and manually redo everything. I just copy clipped all of the macros from a saved copy of the mns file to the new one after manually recreating the buttons.
Now it works again, but I fear that in a few days, Ill turn on my computer and POOF!!! something will be missing.

 

You might post the mns code and indicate which buttons are troublesome. You
still haven't clarified the problem -- are the buttons gone entirely,
leaving only a 4-button toolbar, or are the two bad buttons still visible,
but with a question mark or smiley instead of your bmp image? If the buttons
are still visible, do they function properly when selected? If this happens
again, post all the details, including the location of your menu-related
files.

If you're on 2004, and if you have put your menu in one of the several
places where Acad installs menus, it's possible that somehow a bad version
of the menu, in a different location than the one you fixed, is being used
by Acad, for whatever reason. Try searching your system for all occurences
of the mnc and mnr files and see if there are multiple copies.

 

used by Acad in any way, unless you force it to be used ....
(and in a later message

versions ago

I think AutoDesk would be surprised. You certainly would not get the
impression that they've dropped the .mnu by reading up on menus in the
Customization Guide. Several times it talks about the .mnu being the base
file of them all.

Kent Cooper, AIA

 

the buttons are completely gone. just four left. no empty icons or smily faces or anything like that.
this problem occurs on my work computer which has 2005. another computer with acad 2004 doesnt seem to have this problem.

 

.... and the toolbar shrinks in length to hold only four buttons? Or is
the length still set for 6?

Thinking about possibilities, is this toolbar the last one in the menu
file? If you manually edit the menu file and change the order of the
toolbar definitions does the problem stay with this toolbar or change to
a different toolbar? How many other toolbars are defined in all the
menu files you load? How many toolbars are visible? How many icons
total? I'm thinking you may be reaching a maximum count somewhere...

 

As I mentioned, I'd suspect that the you are seeeing a different menu
altogether. Try searching your computer for mnc files with that name --
there may be several of them, and your computer is somehow defaulting to the
wrong one.

I believe if you type (findfile "<yourmenu>.mnc") at the command prompt, it
will return the one that Acad is finding.