TBC Macros and Extensions

 View Only
Back to discussions
Expand all | Collapse all

MText.TextString method doesnot returns correct text values

  • 1.  MText.TextString method doesnot returns correct text values

    Posted 2 days ago
    Edited by Vitalii Vovk 2 days ago

    I am developing a macro to help with overbuilding pads on subdivision grading. The macro needs to extract elevation values from TextItem Objects and use them later in the line offset logic.

    I've encountered an issue with MText items imported from .dwg files. When I use the MText.TextString Method: some labels return the correct value, but others return the correct value with extra characters. For example, if the label is "13.8", TextString might return {\C256;13.8} Instead. I've noticed that if I edit the problematic labels (by double-clicking on them) and then use the TextString Method, it returns the text correctly.

    For now, I've decided to brute-force handle these cases, but I'm not satisfied with this approach as it might fail eventually.

    My questions are:

    1. Can anyone point me to a native method in TBC that can extract elevation from text reliably, similar to how TBC handles labels  for the elevation tab ?
    2. Why does TextString sometimes return text as {\C256;13.8} and how can I handle this or work around it?

    Any help is much appreciated!

    Vitalii Vovk

    Also, I am attaching a screenshot with a method that handles elevation extraction for me.

    Here is the link to the .dwg (Look at Blue labels for pad elevations)

    https://drive.google.com/drive/folders/1FDHz9y2rzeYoCuLf9_a6Vx-k9ZlOMYGl?usp=sharing



    ------------------------------
    Vitalii Vovk
    ------------------------------



  • 2.  RE: MText.TextString method doesnot returns correct text values

    Posted yesterday
    Edited by Ronny Schneider yesterday

    Hello Vitalii,

    I haven't seen this kind of MText before. But according to this very old forum post it may have something to do with text coloring.

    https://forums.autodesk.com/t5/vba/mtext-format-codes/td-p/356713

    The method "GetTextSegments" seems to get rid of those codes.

    textlines = textobject.GetTextSegments

# if your'e sure that's only a one line text your result will be in index 0
elevation = textlines[0].TextString

# if it's a potential multiline text you'd need to loop trough it
for line in textlines:

    With your sample data the GetTextSegments creates a second empty entry in textlines[1]. So, checking the result might need extra code which in fact makes your solution with the Regex stripping maybe the neater one.

    There are built-in parse methods like currentProject.Units.Linear.Parse(s) but they require the string to be a proper number from the start, so rather useless for your purpose.

    I'll keep digging myself. That's something I was wondering about myself at some point but never had the time to look into it.



    ------------------------------
    Ronny Schneider
    ------------------------------

    Original Message


  • 3.  RE: MText.TextString method doesnot returns correct text values

    Posted yesterday
    Edited by Vitalii Vovk yesterday

    Ronny, thank you for reviewing it.

    I believe the best option would be to use the native TBC method "Elevation from text," similar to the one used in WPF's ElevationEdit When clicking on the text. Unfortunately, I couldn't locate it.

    You're correct _it looks like_ that .GetSegmentedText Removes the formatting.

    It appears that Mtext Can be extensively formatted, and without fully understanding all the formatting rules, regex will likely fail eventually.

    Therefore, I've decided to adopt an approach using. .GetTextSegments with a double loop in the function. This seems to be a more reliable method, at least for now. Also, as an option, I probably could explode it or convert it to CADText somehow

     @staticmethod 
        def __LabelElevationExtractorDouble(lb):
            # GetTextSegment instead of.TextString because some of the imported Mtext Returns formatted value for the text like  {\C260;14.8} instead of 14.8
            try:
                numbers = []
                labelLines = lb.GetTextSegments
                for line in labelLines:
                    if line.TextString != "":
                        labelText = line.TextString.Trim()  
                        pattern = r'\d+(?:\.\d+)?'
                        regex = Regex(pattern, RegexOptions.IgnoreCase)
                        matches = regex.Matches(labelText)      
                        for match in matches:
                            numbers.append(float(match.Value))

                if len(numbers) != 1:
                    return None
                return numbers[0]
            except Exception as err:
                raise Exception("An error occurred in __LabelElevationExtractorDoubleV2: {}".format(err))



    ------------------------------
    Vitalii Vovk
    ------------------------------

    Original Message


  • 4.  RE: MText.TextString method doesnot returns correct text values

    Posted 16 hours ago

    Hi Vitalii,

    I've found a class TextUtilities in Trimble.Vce.ForeignCad.

    That one has some methods to check if the string contains XText formatting or smartcodes, strip those codes and parse the string into a number.

    from Trimble.Vce.ForeignCad import TextUtilities

if not TextUtilities.XTextContainsFormatting(texto.TextString):
    el1 = TextUtilities.ParseElevationText(texto.TextString, self.currentProject)
else:
    # standard multi-line text is also considered a XText
    # first strip the codes
    tt = TextUtilities.GetPlainStringFromXText(texto.TextString, None) # it does accept None; according to the Object Browser it asks for a Trimble.Vce.Graphics.IQueryTextMetrics queryTextMetrics, no idea what that is
    # parse the remaining string into a number
    el2 = TextUtilities.ParseElevationText(tt, self.currentProject)

    A few years back I've seen texts like 2.335  and the elevation picker failing to recognize the last digit 5. Not sure if that's been fixed meanwhile and how the above-mentioned parser would cope.



    ------------------------------
    Ronny Schneider
    ------------------------------

    Original Message