Code Misbehaving on Particular Machine

[Bill Tillman]

This may be a first...I'm hoping someone can offer comments on this issue:

Been working on a particular computer at a client's office. It uses ACAD2K9 and works pretty good. The machine is on a Novell network and there's obviously some TSR's which allow the machine to be maintained and monitored. Some unexpected delays happen now and then but outside of that it's been ok. This morning I was debugging the code which this machine was used to develop for the past 4 weeks. I made a few changes and all seemed well, and then poof. Suddenly the code began to misbehave very badly. I narrowed it down to the mleader commands. That is when I commented out the mleader commands the code settled down. But this simple problem with mleader caused lines to be omitted, leaders were pointing off in strange directions to points that had nothing to do with the code and it just created a real mess. Can't send any screen shots because of confidentiality agreement with client.

We have narrowed it down to this one machine as three other workstations including my laptop were tested with the same dwg file and VLISP code and everything was fine at those stations.

The IT guys are going to reinstall AutoCAD...maybe that will work, but I begged them to blast away the drive and reinstall everything, even offered to do it myself but they insist they can fix it with a reinstall.

Has anyone ever heard of something like this? What are some remedies one would try for such an event.

In my experience, and if it were my call, I'd completely wipe clean the hard drive, reinstall the OS and the software and be done with it.

[Lee Mac]

Are you using Command calls? Because the command prompts will vary across versions and some prompts will also depend on the last used settings and current style - main reason I avoid command calls at all costs with mainstream applications.

[Bill Tillman]

Here is an example of one of the mleader commands:

(command "._MLEADER" (polar (polar pt2 (dtr 180.0) 2.5) (dtr 270.0) 1.625)
                     (polar (polar pt2 (dtr 270.0) 11.875) (dtr 0.0) 2.5) "SOME TEXT FOR\\PTHE MLEADER")

The troublesome part of this is that this machine has been working fine with it since the beginning. And even this morning it was ok. Right around 9:45 AM it all went south. And so far it's only this workstation which is having the troubles. The AutoCAD text window shows a bunch of Invalid Input messages, but again only when run on this machine.

I should include this caveat. A couple of mleaders in this code are created using entmake. I did it that way just to get some experience with the entmake process. But if you've ever copied the properties of an mleader and then pasted those into an entmake command which takes about 20 lines, you can see why one would chose the command version over entmake. The mleaders created with entmake are working fine and present no problem.

[Lee Mac]

The error messages should give some indication of the problems that the routine is encountering - what messages are you receiving?

I assume you have accounted for OSMODE when supplying points to the command function?

As an alternative, I wouldn't use entmake (far too many DXF Groups for that!), but rather the 'AddMLeader' method.

[Bill Tillman]

The only thing which happens in the text window is I see 4 lines which contain "Invalid Input". There is something I just noticed. I erased and retyped in the mleader command above, willing to try anything... What appears to be happening is that instead of the first coordinates becoming the point of the arrow, that is where the text is located, but the point of the arrow is off out in BF and I cannot account for how ACAD chose that location. It has nothing to do with the polar coordinates in the code. I'm wondering if somehow the propertied for the default mleader have been changed, but looking at them I see nothing out of the ordinary and the settings on this machine match those on another machine which the code is running. The mleader settings would be inherent in the dwg file anyway and both machines are working with the same files.

Here are the properties for the mleader when it's gets drawn on the bad machine:

((-1 . <Entity name: 7ef52158>) (0 . "MULTILEADER") (330 . 
<Entity name: 7ef01cf8>) (5 . "9CBA3") (100 . "AcDbEntity") (67 . 0) (410 . 
"Model") (8 . "Text1") (100 . "AcDbMLeader") (300 . "CONTEXT_DATA{") (40 . 1.0) 
(10 44.5 -2.525 0.0) (41 . 1.5) (140 . 1.5) (145 . 1.0) (174 . 1) (175 . 1) 
(176 . 0) (177 . 0) (290 . 1) (304 . "TEXT FOR THE\\PMLEADER ENTITY") 
(11 0.0 0.0 1.0) (340 . <Entity name: 7ef02420>) (12 45.5 -1.625 0.0) (13 1.0 
0.0 0.0) (42 . 0.0) (43 . 5.0) (44 . 10.25) (45 . 1.0) (170 . 1) (90 . 
-1073741824) (171 . 1) (172 . 5) (91 . -1073741824) (141 . 0.0) (92 . 15737888) 
(291 . 0) (292 . 0) (173 . 0) (293 . 0) (142 . 0.0) (143 . 0.0) (294 . 0) (295 
. 0) (296 . 0) (110 45.5 -1.625 0.0) (111 1.0 0.0 0.0) (112 0.0 1.0 0.0) (297 . 
0) (302 . "LEADER{") (290 . 1) (291 . 1) (10 42.8125 -2.525 0.0) (11 1.0 0.0 
0.0) (90 . 0) (40 . 1.6875) (304 . "LEADER_LINE{") (10 1.5 -4.4375 0.0) (91 . 
0) (305 . "}") (303 . "}") (301 . "}") (340 . <Entity name: 7ef02080>) (90 . 
279552) (170 . 1) (91 . -1056964608) (341 . <Entity name: 7ef01ca0>) (171 . -2) 
(290 . 1) (291 . 1) (41 . 1.6875) (42 . 1.5) (172 . 2) (343 . <Entity name: 
7ef02420>) (173 . 1) (95 . 1) (174 . 1) (175 . 0) (92 . -1056964608) (292 . 0) 
(93 . -1056964608) (10 1.0 1.0 1.0) (43 . 0.0) (176 . 0) (293 . 0) (294 . 0) 
(178 . 0) (179 . 1) (45 . 1.0))

Here are the properties for the good one. Both of these are drawn with the same code, just on different machines.

((-1 . <Entity name: 7ef2f4f8>) (0 . "MULTILEADER") (330 . 
<Entity name: 7ef01cf8>) (5 . "9C66F") (100 . "AcDbEntity") (67 . 0) (410 . 
"Model") (8 . "Text1") (100 . "AcDbMLeader") (270 . 2) (300 . "CONTEXT_DATA{") 
(40 . 1.0) (10 52.1875 -11.875 0.0) (41 . 1.5) (140 . 1.5) (145 . 1.0) (174 . 
1) (175 . 1) (176 . 0) (177 . 0) (290 . 1) (304 . "TEXT FOR THE\\PMLEADER ENTITY") 
(11 0.0 0.0 1.0) (340 . <Entity name: 7ef02420>) (12 53.1875 
-10.975 0.0) (13 1.0 0.0 0.0) (42 . 0.0) (43 . 0.0) (44 . 0.0) (45 . 1.0) (170 
. 1) (90 . -1073741824) (171 . 1) (172 . 5) (91 . -1073741824) (141 . 0.0) (92 
. 0) (291 . 0) (292 . 0) (173 . 0) (293 . 0) (142 . 0.0) (143 . 0.0) (294 . 0) 
(295 . 0) (296 . 0) (110 45.5 -1.625 0.0) (111 1.0 0.0 0.0) (112 0.0 1.0 0.0) 
(297 . 0) (302 . "LEADER{") (290 . 1) (291 . 1) (10 50.5 -11.875 0.0) (11 1.0 
0.0 0.0) (90 . 0) (40 . 1.6875) (304 . "LEADER_LINE{") (10 45.5 -1.625 0.0) (91 
. 0) (170 . 1) (92 . -1056964608) (340 . <Entity name: 0>) (171 . -2) (40 . 
0.0) (341 . <Entity name: 0>) (93 . 0) (305 . "}") (271 . 0) (303 . "}") (272 . 
9) (273 . 9) (301 . "}") (340 . <Entity name: 7ef02080>) (90 . 279552) (170 . 
1) (91 . -1056964608) (341 . <Entity name: 7ef01ca0>) (171 . -2) (290 . 1) (291 
. 1) (41 . 1.6875) (42 . 1.5) (172 . 2) (343 . <Entity name: 7ef02420>) (173 . 
1) (95 . 1) (174 . 1) (175 . 0) (92 . -1056964608) (292 . 0) (93 . -1056964608) 
(10 1.0 1.0 1.0) (43 . 0.0) (176 . 0) (293 . 0) (294 . 0) (178 . 0) (179 . 1) 
(45 . 1.0) (271 . 0) (272 . 9) (273 . 9))

I'm still studying this myself. By the way....pt2 = (48.0 0.0).

[Lee Mac]

Consider this, Bill, as noted in my previous post about prompt order with command calls:

Because the command prompts will vary across versions and some prompts will also depend on the last used settings and current style...

Command: MLEADER

Specify leader arrowhead location or [leader Landing first/Content first/Options] <Options>: C

Specify first corner of text or [leader arrowHead first/leader Landing first/Options] <Options>:
Specify opposite corner:
Specify leader arrowhead location:

Command: MLEADER
Specify first corner of text or [leader arrowHead first/leader Landing first/Options] <Options>: *Cancel*

[Bill Tillman]

Ok, I follow what your saying, unfortunately I'm not at the suspect machine right now. But if this is what happened then it should be easy to fix. And what may have happened is that while fooling around with some commands today, the mleader command to be exact, it's possible that I shifted the way this copy of AutoCAD deals with the mleader command.

So even though I shutdown AutoCAD and cold booted the computer, when I come back to the next session of AutoCAD it's recalling that some idiot, (that would be me) inadvertently set the default action of mleader to take in the text as the first input. That would certainly explain things. I just would not have thought that a restart of AutoCAD would not put things back in their factory default mode. I sure hope that's the case, but I won't find out until tomorrow morning.

UPDATE: I tested this on my 2K12 machine at home and sure enough, that was the source of all the trouble. Apparently I just don't know enough about AutoCAD's behavior to have figured this one out. So everyone, in unison please....

open mouth for input as #1
   insert = foot
   chew  = vigorously!
close

Thanks for the advice.

[Dadgad]

A good rule of thumb. When all else fails, look for something simple, it's usually there.

[Lee Mac]

Ok, I follow what your saying, unfortunately I'm not at the suspect machine right now. But if this is what happened then it should be easy to fix. And what may have happened is that while fooling around with some commands today, the mleader command to be exact, it's possible that I shifted the way this copy of AutoCAD deals with the mleader command.

But what if another user decides to construct an MLeader in a different order, now your program will crash again...

[Bill Tillman]

Yes, that is correct. But now I will change the command for mleader to start with the "H" option. This will force the behavior I need long enough for me to research the AddMLeader method. I agree with your suggestion to stay away from direct commands as much as possible. And as I move forward in these projects I will bear that in mind.

And I asked around this morning with the users and none of them were aware that mleader had this history tracking. They also agreed that all of them were fine if I forced the "H" switch and that would become the default setting for mleader on their workstation as well. All the more reason to learn what AddMLeader can do to avoid this in the first place.

BTW - I'm sure you're probably aware of it, but the Error Handling routine I found at AfraLISP is working very well for me. Even is the user presses Esc during the program run, it resets all the variables I've tweaked like pickbox, osmode and cmdecho. The users are very grateful for this. Still some of them are complaining that since running my program, their machine has slowed down. I cannot explain this one.