The purpose of this thread will be to describe the process of moving existing RTB code to use the InkEdit control.
MSDN states this about the InkEdit control here, so the chances of a successful migration seem good:
The InkEdit control is a super class of the RichEdit control. Every RichEdit message is passed on, directly in most cases, and has exactly the same effect as in RichEdit. This also applies to event notification messages.
Let's hope that's the case!
If you are unfamiliar with the InkEdit control, Dilettante has done a lot of work demonstrate its various improvements over the VB6 RTB control in threads such as these:
http://www.vbforums.com/showthread.p...ows-SpellCheck
Event Gotchas
Mouse Events
The Mouse* events in the InkEdit have different signatures than the RTB. Namely, all parameters are passed ByVal instead of ByRef, and last 2 parameters (x and y) are Long instead of Single. You will need to change the RTB events to match the InkEdit event signatures in your source code.
For example:
Becomes:
I have to do some testing to see if the InkEdit always passes Pixels or Twips, or if there is a loss of precision when using ScaleModes like Inches.
OLE* Events
The OLECompleteDrag, OLEDragDrop, OLEDragOver, OLEGiveFeedback, OLESetData, and OLEStartDrag events all appear to be missing from the InkEdit control, so you'll have to use another method to use OLE features with the control (maybe Faflone's or Edanmo's OLE TLB(s) or similar?)
Property Gotchas
SelStrikeThru
The SelStrikeThru property appears to be missing from the InkEdit control, so another approach will have to be found to replicate the functionality of this property (perhaps TOM?).
RightMargin
The RightMargin property appears to be missing from the InkEdit control, so another approach is necessary. The EM_SETMARGINS and EM_GETMARGINS messages can be used instead (thank LaVolpe!)
Message Gotchas
EM_FORMATRANGE
In my initial tests EM_FORMATRANGE always appears to return -1 instead of the last character index +1 that fit in the bounding box if the FORMATRANGE.hDC parameter is 0. The RTB works OK when FORMATRANGE.hDC = 0. The solution is to pass a valid DC handle to FORMATRANGE.hDC before sending the EM_FORMATRANGE message.
MSDN states this about the InkEdit control here, so the chances of a successful migration seem good:
Quote:
The InkEdit control is a super class of the RichEdit control. Every RichEdit message is passed on, directly in most cases, and has exactly the same effect as in RichEdit. This also applies to event notification messages.
If you are unfamiliar with the InkEdit control, Dilettante has done a lot of work demonstrate its various improvements over the VB6 RTB control in threads such as these:
http://www.vbforums.com/showthread.p...ows-SpellCheck
Event Gotchas
Mouse Events
The Mouse* events in the InkEdit have different signatures than the RTB. Namely, all parameters are passed ByVal instead of ByRef, and last 2 parameters (x and y) are Long instead of Single. You will need to change the RTB events to match the InkEdit event signatures in your source code.
For example:
Code:
Private Sub RichTextBox1_MouseMove(Button As Integer, Shift As Integer, x As Single, y As Single)Code:
Private Sub InkEdit1_MouseMove(ByVal Button As Integer, ByVal ShiftKey As Integer, ByVal xMouse As Long, ByVal yMouse As Long)OLE* Events
The OLECompleteDrag, OLEDragDrop, OLEDragOver, OLEGiveFeedback, OLESetData, and OLEStartDrag events all appear to be missing from the InkEdit control, so you'll have to use another method to use OLE features with the control (maybe Faflone's or Edanmo's OLE TLB(s) or similar?)
Property Gotchas
SelStrikeThru
The SelStrikeThru property appears to be missing from the InkEdit control, so another approach will have to be found to replicate the functionality of this property (perhaps TOM?).
RightMargin
The RightMargin property appears to be missing from the InkEdit control, so another approach is necessary. The EM_SETMARGINS and EM_GETMARGINS messages can be used instead (thank LaVolpe!)
Code:
' Note that this is quick "air code" - it should work, but I haven't tested it specifically
' Since I use various other HiWord/LoWord/Dword/ScaleMode conversion methods, helper libraries, etc...
Private Declare Function SendMessage Lib "user32" Alias "SendMessageW" _
(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal _
lParam As Long) As Long
Private Const EM_GETMARGINS As Long = &HD4
Private Const EM_SETMARGINS As Long = &HD3
Private Const EC_RIGHTMARGIN As Long = &H2
Public Property Get RightMargin() As Long
RightMargin = SendMessage InkEdit1.Hwnd, EM_GETMARGINS, 0, 0
RightMargin = (RightMargin / &H10000) And &HFFFF& ' Get HiWord of Return Value
RightMargin = RightMargin * Screen.TwipsPerPixelX ' Convert Pixels to Twips - may need other approach for HighDPI in UserControl
End Property
Public Property Let RightMargin(ByVal p_Twips As Long)
p_Twips = p_Twips / Screen.TwipsPerPixelX ' Convert Twips to Pixels
p_Twips = p_Twips * &H10000 ' Move Pixels to HiWord
SendMessage InkEdit1.Hwnd, EM_SETMARGINS, EC_RIGHTMARGIN, p_Twips
End PropertyMessage Gotchas
EM_FORMATRANGE
In my initial tests EM_FORMATRANGE always appears to return -1 instead of the last character index +1 that fit in the bounding box if the FORMATRANGE.hDC parameter is 0. The RTB works OK when FORMATRANGE.hDC = 0. The solution is to pass a valid DC handle to FORMATRANGE.hDC before sending the EM_FORMATRANGE message.