Haven't worked with any which would offer more access -- I was hoping that you might find something and let us know!

Your problem has been running on the back burner.

Let's assume, for the time being, that embedded CRs are the only special chars which are causing the problem. And, that all text is visible.

The key then is determining the end of a line, by either wordwrap or CR. Once you'd found the number of lines to the insertion point, all you have to do is find out the horizontal position in the string.

Here's pseudo code:

FUNCTION  LinesInSubstring
LPARAMETER      tnStartPos, tnLength, tnCRs
     Start with 1 line. Use the same calculation for lines as described in previous message, but add 1 line for each CR, and don't count partial lines as a complete line. 
   
PROCECURE     GetPositionofText
Store the locations of CRs to an array. Add an initial position = 1. Add a final position for the insertion point. -- laEndPoints
lnLines = 0
lcLastSubstring = ""
FOR X = 1 TO lnCRs - 1
    DO CASE
        CASE    X = 1 AND lnCRs - 1 = 2  && straight text without CRs
              lnCRs = 0
              lnStart = laEndPoints [X]
              lnLen = laEndPoints [X + 1] - laEndPoints [X] + 1
              lcLastSubString = SUBSTRING (lcText, lnStart, lnEnd)

        CASE    X = 1    &&   first substring -- no CR at beginning
              lnCRs = 1   
              lnStart = laEndPoints [X]
              lnLen = laEndPoints [X + 1] - laEndPoints [X]  && Omit CR at end

        CASE    X = lnCRs - 1  &&  last substring -- no CR at end of second
              lnCRs = 1
              lnStart = laEndPoints [X] + 1    && Omit CR at beg
              lnLen = laEndPoints [X + 1] - laEndPoints [X]  && Omit CR at beg
              lcLastSubString = SUBSTRING (lcText, lnStart, lnEnd) 

        OTHERWISE
              lnCRs = 2
              lnStart = laEndPoints [X] + 1    && Omit CR at beg
              lnLen = laEndPoints [X + 1] - laEndPoints [X] - 1 && Omit CR at beg and end.
   ENDCASE

    lnLines = lnLines + LinesInSubstring (lnStart, lnLen, lnCRs)
ENDFOR

lnHorizontalPosition = GetHorizontalPos (lcLastSubString)  && Same algorithm as for text boxes.

I'm sure that will need some fine-tuning if you implement it, but perhaps that gives a start.

Another alternative, which might be attractive particularly if text extends beyond a page, would be an HTML control. You could then format the text as HTML and utilize mouse over capabilities (as embedded VBScript/JScript or other approaches).

Enjoy!

Jay

>Jay,
>
>Any suggestions for an appropriate ActiveX? Per Ed Rauh's suggestion, I checked out the MS RTF control. I did not see any properties of this control that would return the information that I'm looking for.
>
>Thanks!
>Malcolm
>
>>>Jay,
>>>
>>>Thanks for your reply. I follow your technique and it works great for single line text. For multi-line (word wrapped) text, its an approximation with varying accuracy - dependent on the text. It also does not take into account the impact of control chars like carriage returns.
>>>
>>>I'm going to repost this question in the Windows API forum. Even though VFP does not expose such properties, it seems logical to me that a control must have some way of knowing the physical and relative row and column positions of the text cursor.
>>>
>>>Thanks again for your help!
>>>
>>>Malcolm
>>
>>I also wonder if an ActiveX control might offer more access.
>>
>> Jay
>>
>>>
>>>>>Is there a way to determine the row and column pixel position of the text cursor in an input control such as a text box, edit box, or combo box?
>>>>>
>>>>>We would like to be able to popup a small 'smart tag' like form in our edit boxes when we detect certain text patterns. Ideally we would like to popup this 'smart tag' like form relative to the position of the text cursor.
>>>>>
>>>>>Any help or insights appreciated!
>>>>>Malcolm
>>>>
>>>>For controls which display one row of data, such as a text or combo, you have the control's location. You can use the control's .SelStart property to find out the character position of the cursor, extract the characters up to that point. A combination of TXTWIDTH() (returning the length in characters) and FONTMETRIC(6) (returning the length in pixels) to get a very close approximation.
>>>>
>>>>I don't know of a way of determining exactly what row and column position a cursor resides on in an edit box. You can calculate pretty close by using the control's size, and FontMetric. The length in pixels you can approximate with TXTWIDTH and FONTMETRIC (6). For the height you need to factor in the character size as well as regular and special leading (FONTMETRIC (1) + FONTMETRIC (4) + FONTMETRIC (5)).
>>>>
>>>>Divide the text width in pixels by the control's width to get the integer line number. Line numbers times height gives the distance from the top of the control. The Mod of the text width dividec by the control's width can be used to provide a percentage of the width to locate your popup.
>>>>
>>>>HTH,
>>>>
>>>>Jay