Topic: Fun with MText

[LE]

Some data is not right, have a look into the following:

((-1 . <Entity name: 7efa1120>)
  (0 . "MTEXT")
  (330 . <Entity name: 7efb6cf8>)
  (5 . "DC")
  (100 . "AcDbEntity")
  (67 . 0)
  (410 . "Model")
  (8 . "ACG_ZGRADA_OZNAKA")
  (6 . "Continuous")
  (100 . "AcDbMText")
  (10 6.32855 5.85846 -1.#IND)
  (40 . 1.0)
  (41 . 0.0)
  (46 . 0.0)
  (71 . 5)
  (72 . 5)
  (1 . "P=6m\U+00B2")
  (7 . "Standard")
  (210 0.0 0.0 1.0)
  (11 1.0 0.0 0.0)
  (42 . 4.5)
  (43 . 1.0)
  (50 . 0.0)
  (73 . 1)
  (44 . 1.0))

then if it is exploded:

((-1 . <Entity name: 7efa0168>)
  (0 . "TEXT")
  (330 . <Entity name: 7efb6cf8>)
  (5 . "E5")
  (100 . "AcDbEntity")
  (67 . 0)
  (410 . "Model")
  (8 . "ACG_ZGRADA_OZNAKA")
  (100 . "AcDbText")
  (10 -1.#IND -1.#IND -1.#IND)
  (40 . 1.0)
  (1 . "²")
  (50 . 0.0)
  (41 . 1.0)
  (51 . 0.0)
  (7 . "Standard")
  (71 . 0)
  (72 . 0)
  (11 0.0 0.0 -1.#IND)
  (210 0.0 0.0 1.0)
  (100 . "AcDbText")
  (73 . 0))

[LE]

If I replace the -1.#IND with 0.0, then the mtext behaves normally.

[Kerry]

MaksimS,

conventionally the m_ prefix is used for the names of private fields to a class .. you seem to be using them for local variable names for your functions .. is this correct ?

not that it makes any difference to the compiled code ; just the non-VB side of my brain asking .. trying to make sure I'm not missing something.

[MaksimS]

We have local agreement to use m_ prefix for any local variable and private field (private to the class anyways) Not the best solution, I know, but we're practicing it for years. It seems to me that the Point3d returned by Centroid property needs some fixing. It has to do with certain PrecisionModel class governing overall geometry precision, since some geometric calculations do not perform mathematically correct within default precision model.

I'd say that Z coordinate is erroneous, this might be the source of this weird MText's behaviour.

Regards,
Maksim Sestic

MaksimS,

conventionally the m_ prefix is used for the names of private fields to a class .. you seem to be using them for local variable names for your functions .. is this correct ?

not that it makes any difference to the compiled code ; just the non-VB side of my brain asking .. trying to make sure I'm not missing something.

[Glenn R]

If you Audit that drawing, it reports the MText as being in error and fixes it. Prior to the audit, I could select the object to get the grip, but I could not move my cursor to the grip to grip it. Whenever the cursor got near the grip, the cursor would just...disappear...

[MaksimS]

Not only you can't select it via it's grip - ACAD somehow enters the entity selection state when you try to pick the grip and waits for user to select entities (at the time crosshair disappears try to move the mouse and see what happens). What puzzles me the most is Editor's behaviour.

If you Audit that drawing, it reports the MText as being in error and fixes it. Prior to the audit, I could select the object to get the grip, but I could not move my cursor to the grip to grip it. Whenever the cursor got near the grip, the cursor would just...disappear...

[Kerry]

Well at least you know which part of your program to fix to have it come good

[LE]

grip, the cursor would just...disappear...

Verify how are you doing your calculations... here are some url links about #IND

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1407086&SiteID=1

http://www.vbforums.com/archive/index.php/t-348658.html

http://www.gamedev.net/community/forums/topic.asp?topic_id=434717&whichpage=1&#2886472

[Kerry]

How'd you go Maksim ??

[MaksimS]

Bah, the tricky part (Z axis returning #IND) was hidden in set of classes performing coordinate conversion. I received fixed code from my coworkers but I didnt' receive requested debug log to find out what actually caused the coordinate misinterpretation This one will remain mistery for the time being, I need some extra couple of hours to check this out myself (somehow I'm always missing couple of hours daily...)