Screen Menu doesn't work in 2004

The mystery deepens....

Yes, it ran all the way through without error. I had never tried opening a
..mns file before, assuming it would be in gobbledegook language, but it
looks like it just collapses multiple-line routines into single lines. It
cuts every line off at a maximum of 1024 characters.

The -->Draw LINE example you sent ends something like 80% of the way through
in the .mns file. But it actually performs the whole operation anyway,
somehow. If you want to try it, you'll need to:

find in a Site Plan, like 240 (for 1"=20').

segments than any AutoCAD linetype, with two dots separating them, but for
this purpose it doesn't matter what it looks like, just that it be there).
Or, you could change the PROPERTY linetype assignment item in the .mnu file
to something you have available (change the word PROPERTY near the end of
the first line of the [*Set-Up*] item to HIDDEN, or something), and
reload/recompile the menu.

Pick the *Set-Up* item, which defines a METES text style (using ROMANS
font), a METES layer for it, and the PROPERTY layer for the property lines,
and asks whether distances in your deed description are in
feet-inches-fractions or decimal feet. (A little quirk I haven't figured
out is that if you accept the "D" default, it ends up using
feet-inches-fractions, but if you TYPE IN a "D", it does it right. But that
won't affect the overall issue.)

Then pick -->Draw LINE. It will ask for a starting point (for the first one
you can't use the default of continuing the previous, so pick a point
somewhere in the middle of the screen). Then it asks for a bearing (type
something in surveyor's unit language, like N12d34'56"E), then a distance
(type something like 34.56'). It will then draw the line on the Property
layer, and ask which side of the line you want the text on -- pick anywhere.
It then establishes locations for text insertion points, sets up the text
content (because it should write it, at least the bearing, in a little
different format than you entered it), and writes in the bearing at one end
of the line and the distance at the other, on the METES layer and in the
METES text style.

The .mns file's line for this item ends somewhere in the middle of its
establishing the text content for the bearing. It doesn't get through that
part, or as far as putting that text in, or establishing the text content
for the distance, or putting that in. But it still does those things (at
least for me) anyway! I'd love to know how that works.

Those three items near the top of the .mnu file are, sure enough, just not
there in the .mns file. They are longer than the Property-line items, but
if length is the issue, you'd think the latter wouldn't be there, either.
Wouldn't you think it would compile those other three as far as 1024
characters, as with the others, and cut them off there too, but still at
least show the headers for them on the screen menu?

Kent Cooper, AIA

 

Well, I wasn't 100% correct with my previous response.
Actually AutoCAD creates an .mns from the .mnu file, then compiles the .mns
file to an .mnc file
The .mnc file is the actual one it uses.
Every time a menu file is loaded AutoCAD checks the date stamp. If a .mns
file stamp is later than the .mnc file, it recompiles the newer .mns file
into a new .mnc file.

So it sounds as though the .mnc was compiled correctly from the original
...mnu file but when AutoCAD writes the .mns file, it truncates the lines.
No problem, as long as you don't change the date stamp on the .mns file.
But if you did edit the .mns file, then you would have problems, due to the
truncated lines.

There may be other problems with syntax in the lines do not load properly.
I don't really want to investigate why

I'll stick by my suggestion to rewrite the code as a lisp function, then
call the lisp function from the menu only.
In the long run, it will make life much easier for you. See Doug Broad's
post.

Good luck!

 

You're right -- the .mnc file does have the entire routine in there, where
the .mns version is truncated. (There is also gobbledegook stuff in the
..mnc file, but you can tell at least that much.) And it doesn't have those
"missing" items, either, just a couple of little rectangle
Notepad-and-MSWord-can't-interpret-them characters for each, between what's
obviously the stuff that shows up above and below them. No clue in there,
at least looking at it in Notepad/MSWord, as to why that should be.

Kent Cooper, AIA

...

 

AMEN!
They have not made ANYTHING that can take the place of the screen menu and
make it as easy as it used to be. Now, for some reason, it doesn't want to
work, and for the life of me, I can't figure out why. I love having OOPS
come up when I erase. I love having options at my disposal when I invoke a
command. Toolbars have their purpose, and palettes can take a dive as far
as I'm concerned, but nothing is as intuitive as the screen menu for as
simple as it is. Why on earth do they keep scr???ng with it?!?

FIX IT BACK THE WAY IT WAS AND LEAVE IT THE HEQQ ALONE!

 

When you edit an mnu file, and let Acad create the mns source and then compile that to an mnc, several things happen. It strips all comments out of the mnu, and it scrambles the order of any help strings.

However, if you work with the mns directly, comments aren't stripped out. Maybe big chunks of the the screen menu are also being stripped out in creating the mns?

I'd suggest deleting the Acad-created mns, and copying your mnu to an mns extension. Then load the mns (not the mnu) to force a recompilation. Just to verify whether it is the mnu-to-mns conversion that's messing it up. If so, you could eliminate the mnu altogether and use the mns as your menu source.

I don't do screen menus, but I only work with the mns file for all customizations, and don't use an mnu at all.