Hi Jay,

Thanks for your insight and clever code. My take on your code is that it determines the absolute(?) row and column of the text cursor - a good start. But it doesn't address the relative row (relative to the control's orgin) if the user used a vertical scroll bar to shift their view of an editbox's content up or down. Doh!

I hear what you're saying about considering a web browser control. This would certainly make sense if I was displaying only read-only content. But IMHO a web browser control is inherently a readonly control as opposed to an edit box or RTF control which I tend to think of as data entry controls. Another drawback to the web browser control is the requirement for users' to have a minimal version of IE installed in order for the web browser control to work. Easier said than done!

Thanks again for taking the time to put together your sample code. Much appreciated!

Regards,
Malcolm


>
>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