Re: ListView: How to show a ToolTipText at the column header?
Originally Posted by Krool
The tooltip class will be considered in the VisualStyles property in VBCCR16..
That would avoid to loop through all controls on a form everytime you open the form and save a lot of time opening a form with hundreds of controls on it
Re: CommonControls (Replacement of the MS common controls)
Hi Krool
I downloaded the MDI_ToolBar Demo but I can't figure outhow to make the ToolBar control accessible per shortcut key on a MDIForm
For example what code I need to show Form2 and where shall I place this code as it is not possible to place it in KeyDown event of the MDIForm
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by samer22
I downloaded the MDI_ToolBar Demo but I can't figure outhow to make the ToolBar control accessible per shortcut key on a MDIForm
For example what code I need to show Form2 and where shall I place this code as it is not possible to place it in KeyDown event of the MDIForm
If you download the demo then run and test it out.
If it does what you expect then study the demo project how it's done. (E.g. what's for code in the Form, how are the properties set etc.)
It should be all self-explaining. I would just repeat here what's shown in the demo project..
Originally Posted by Mith
That would avoid to loop through all controls on a form everytime you open the form and save a lot of time opening a form with hundreds of controls on it
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
If you download the demo then run and test it out.
If it does what you expect then study the demo project how it's done. (E.g. what's for code in the Form, how are the properties set etc.)
It should be all self-explaining. I would just repeat here what's shown in the demo project..
Sorry sir I'm a beginner
I downloaded the demo and tested it
I was expecting I could do something like that
Code:
If KeyCode = vbKeyF1 Then FormChild.Show
The same thing I do in a form Form_KeyDown event.
But since a MdiForm doesn't have a KeyDown event, I couldn't figure out how to make use of shortcut keys.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by samer22
Sorry sir I'm a beginner
I downloaded the demo and tested it
I was expecting I could do something like that
Code:
If KeyCode = vbKeyF1 Then FormChild.Show
The same thing I do in a form Form_KeyDown event.
But since a MdiForm doesn't have a KeyDown event, I couldn't figure out how to make use of shortcut keys.
Yes, an MDIFrom doesn't have a KeyDown event.
The MDI_ToolBar demo is therefore using a WH_KEYBOARD_LL hook to detect WM_SYSKEYDOWN and with flag LLKHF_ALTDOWN and pass to ToolBar1.ContainerKeyDown. ToolBar1.ContainerKeyDown is a convinient method that will trigger a button click, when there is a button caption with an Ampersand (e.g. "&New Doc", which displays "New Doc") an key code matching it. (of course the button also must be enabled, not disabled)
However, what you want is then independent from ToolBar1.ContainerKeyDown.
To reach your behavior I just changed the hook, see below:
Code:
Private Type KBDLLHOOKSTRUCT
VKCode As Long
ScanCode As Long
Flags As Long
Time As Long
dwExtraInfo As Long
End Type
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Private Declare Function GetActiveWindow Lib "user32" () As Long
Private Const WM_KEYDOWN As Long = &H100
Implements IHook
Private Sub IHook_Before(ByRef Handled As Boolean, ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
If HookType = WH_KEYBOARD_LL Then
If HookCode = HC_ACTION Then
If wParam = WM_KEYDOWN Then
If GetActiveWindow() = Me.hWnd Then
Dim KBDLLHS As KBDLLHOOKSTRUCT
CopyMemory KBDLLHS, ByVal lParam, LenB(KBDLLHS)
Dim KeyCode As Integer
KeyCode = KBDLLHS.VKCode And &HFF&
If KeyCode = vbKeyF1 Then
With New FormChild
.Show vbModeless
End With
Handled = True
RetVal = 1
End If
End If
End If
End If
End If
End Sub
Private Sub IHook_After(ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
End Sub
Private Sub MDIForm_Load()
Call SetHook(Me, WH_KEYBOARD_LL)
End Sub
Private Sub MDIForm_Unload(Cancel As Integer)
Call RemoveHook(Me, WH_KEYBOARD_LL)
End Sub
To make this user-friendly you could include in the button caption in the ToolBar an "(F1)". Even when in real it's totally disconnected.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Quote Originally Posted by Mith View Post
That would avoid to loop through all controls on a form everytime you open the form and save a lot of time opening a form with hundreds of controls on it
Not "would". It is.
It is? Do you mean the VisualStyles property has already included a newer modern version of the tooltip class?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
no, i wrote this at one of my posts:
I guess there is no "modern look" tooltiptext with all the vbccr16 controls possible without using an extra tooltip class...
For the Control.ToolTipText your right. This was already discussed before and an idea was to include an .ToolTipTextW property that supports Unicode and theming. It's not possible to overwrite .ToolTipText because it's handled by VBControlExtender.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
This was already discussed before and an idea was to include an .ToolTipTextW property that supports Unicode and theming. It's not possible to overwrite .ToolTipText because it's handled by VBControlExtender.
if the current .ToolTipText property can save unicode text it would be better to add a new option to select the using of the .ToolTipText property:
1. standard VB ToolTipText
2. new ToolTipText class with modern look
but i guess if the .ToolTipText is handled by VBControlExtender you cant save unicode text, or?
Re: CommonControls (Replacement of the MS common controls)
Changing backcolor on tab-strip's tabs can be implemented on *parent* WM_PRINTCLIENT msg like this
Code:
Case WM_PRINTCLIENT
'--- for tab-strip integration
If (lParam And PRF_CLIENT) <> 0 Then
Call GetClientRect(m_hWnd, rc)
Call FillRect(wParam, rc, m_hBackBrush)
Exit Function
End If
This is just an idea for Krool so he can can look to it if possible to impl here.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by wqweto
Changing backcolor on tab-strip's tabs can be implemented on *parent* WM_PRINTCLIENT msg like this
Code:
Case WM_PRINTCLIENT
'--- for tab-strip integration
If (lParam And PRF_CLIENT) <> 0 Then
Call GetClientRect(m_hWnd, rc)
Call FillRect(wParam, rc, m_hBackBrush)
Exit Function
End If
This is just an idea for Krool so he can can look to it if possible to impl here.
cheers,
</wqw>
Wow, I didn't know that. This works and is straight-forward. Is this an implementation on later OS ?
Though, it only works with VisualStyles set to True and with style 'Tabs' (all other styles are anyway not themed)
I thought it needs to be "hacked" via WM_PAINT with calculation of all the item rects and glitching around…
That the parent needs to handle WM_PRINTCLIENT reminds me of the ListView control. There was something similar added since Vista.
Re: CommonControls (Replacement of the MS common controls)
So, the WM_PRINTCLIENT trick works for themed TabStrip back to Windows XP. So that is great. Thanks again wqweto. How did you come to this?
For the other styles, unthemed or when owner drawn the workaround to catch WM_PAINT and draw in memory dc would work sufficient as the item rect's are meaningful to get by API's, no rounded corners and assumptions(!) like in the themed tab.
Originally Posted by Karl77
Do you have a small working example?
When somebody can't wait for the official BackColor property, then you may apply the following in the function "WindowProcUserControl":
Code:
Case WM_PRINTCLIENT
' hard-coded as no BackColor property there yet. :) Just a demo.
If TabStripHandle <> 0 Then
If WindowFromDC(wParam) = TabStripHandle Then
Dim RC As RECT, Brush As Long
GetClientRect TabStripHandle, RC
Brush = CreateSolidBrush(vbRed)
FillRect wParam, RC, Brush
DeleteObject Brush
Exit Function
End If
End If
Two minor modification compared to wqweto.
1. no PRF_CLIENT flag check needed because WM_PRINTCLIENT is per definition always PRF_CLIENT.
2. added a check that the associated wParam (DC) is really linked to the TabStrip and not any other window..
I loaded a file with a BOM header FFFE using the flag RtfLoadSaveFormatUnicodeText into a RichTextBox.
The BOM header was removed and not shown up at the text window.
Everything was fine until here.
Later i saved the file with the flag RtfLoadSaveFormatUnicodeText but the BOM header FFFE not have been added to file again!
I thought using the flag RtfLoadSaveFormatUnicodeText when saving a file would always add the BOM header to the file...
Is this a bug or how can i save the file including the BOM header again?
I loaded a file with a BOM header FFFE using the flag RtfLoadSaveFormatUnicodeText into a RichTextBox.
The BOM header was removed and not shown up at the text window.
Everything was fine until here.
Later i saved the file with the flag RtfLoadSaveFormatUnicodeText but the BOM header FFFE not have been added to file again!
I thought using the flag RtfLoadSaveFormatUnicodeText when saving a file would always add the BOM header to the file...
Is this a bug or how can i save the file including the BOM header again?
Thanks. Fixed.
That was a "bug". Not really a bug because the rich edit control just handle streams. It does not care about BOM header.
So it was an oversight by me to not write the BOM header when saving a Unicode file.
Re: CommonControls (Replacement of the MS common controls)
I also slightly modified LoadFile for RichTextBox.
It will load unicode file even when there is no BOM.
Prior to this change (when there is no BOM) it fall backs to ANSI text. But that does not make sense at all when specifying RtfLoadSaveFormatUnicodeText. It should read Unicode for BOM and no BOM cases without unlogic fall back to ANSI when there is no BOM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Yes, an MDIFrom doesn't have a KeyDown event.
The MDI_ToolBar demo is therefore using a WH_KEYBOARD_LL hook to detect WM_SYSKEYDOWN and with flag LLKHF_ALTDOWN and pass to ToolBar1.ContainerKeyDown. ToolBar1.ContainerKeyDown is a convinient method that will trigger a button click, when there is a button caption with an Ampersand (e.g. "&New Doc", which displays "New Doc") an key code matching it. (of course the button also must be enabled, not disabled)
However, what you want is then independent from ToolBar1.ContainerKeyDown.
To reach your behavior I just changed the hook, see below:
Code:
Private Type KBDLLHOOKSTRUCT
VKCode As Long
ScanCode As Long
Flags As Long
Time As Long
dwExtraInfo As Long
End Type
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Private Declare Function GetActiveWindow Lib "user32" () As Long
Private Const WM_KEYDOWN As Long = &H100
Implements IHook
Private Sub IHook_Before(ByRef Handled As Boolean, ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
If HookType = WH_KEYBOARD_LL Then
If HookCode = HC_ACTION Then
If wParam = WM_KEYDOWN Then
If GetActiveWindow() = Me.hWnd Then
Dim KBDLLHS As KBDLLHOOKSTRUCT
CopyMemory KBDLLHS, ByVal lParam, LenB(KBDLLHS)
Dim KeyCode As Integer
KeyCode = KBDLLHS.VKCode And &HFF&
If KeyCode = vbKeyF1 Then
With New FormChild
.Show vbModeless
End With
Handled = True
RetVal = 1
End If
End If
End If
End If
End If
End Sub
Private Sub IHook_After(ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
End Sub
Private Sub MDIForm_Load()
Call SetHook(Me, WH_KEYBOARD_LL)
End Sub
Private Sub MDIForm_Unload(Cancel As Integer)
Call RemoveHook(Me, WH_KEYBOARD_LL)
End Sub
To make this user-friendly you could include in the button caption in the ToolBar an "(F1)". Even when in real it's totally disconnected.
Hello sir
I noticed that when I call the function SetHook I will be unable to use keyboard keys.
Hence, Impossible to write in textboxes
thanks
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Yes, an MDIFrom doesn't have a KeyDown event.
The MDI_ToolBar demo is therefore using a WH_KEYBOARD_LL hook to detect WM_SYSKEYDOWN and with flag LLKHF_ALTDOWN and pass to ToolBar1.ContainerKeyDown. ToolBar1.ContainerKeyDown is a convinient method that will trigger a button click, when there is a button caption with an Ampersand (e.g. "&New Doc", which displays "New Doc") an key code matching it. (of course the button also must be enabled, not disabled)
However, what you want is then independent from ToolBar1.ContainerKeyDown.
To reach your behavior I just changed the hook, see below:
Code:
Private Type KBDLLHOOKSTRUCT
VKCode As Long
ScanCode As Long
Flags As Long
Time As Long
dwExtraInfo As Long
End Type
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Private Declare Function GetActiveWindow Lib "user32" () As Long
Private Const WM_KEYDOWN As Long = &H100
Implements IHook
Private Sub IHook_Before(ByRef Handled As Boolean, ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
If HookType = WH_KEYBOARD_LL Then
If HookCode = HC_ACTION Then
If wParam = WM_KEYDOWN Then
If GetActiveWindow() = Me.hWnd Then
Dim KBDLLHS As KBDLLHOOKSTRUCT
CopyMemory KBDLLHS, ByVal lParam, LenB(KBDLLHS)
Dim KeyCode As Integer
KeyCode = KBDLLHS.VKCode And &HFF&
If KeyCode = vbKeyF1 Then
With New FormChild
.Show vbModeless
End With
Handled = True
RetVal = 1
End If
End If
End If
End If
End If
End Sub
Private Sub IHook_After(ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
End Sub
Private Sub MDIForm_Load()
Call SetHook(Me, WH_KEYBOARD_LL)
End Sub
Private Sub MDIForm_Unload(Cancel As Integer)
Call RemoveHook(Me, WH_KEYBOARD_LL)
End Sub
To make this user-friendly you could include in the button caption in the ToolBar an "(F1)". Even when in real it's totally disconnected.
Hello sir
I noticed that when I call the function SetHook I will be unable to use keyboard keys.
Hence, Impossible to write in textboxes
thanks
Re: RichTextBox: missing flag at the Find function
Originally Posted by Mith
Im missing the reverse flag at the the Find function of the RichTextBox to search a document backwards.
There is no reverse flag, right. However, you can search backwards by flipping the parameters. It's demonstrated in the Demo:
Code:
If (CommonDialogFind.Flags And CdlFRDown) = CdlFRDown Then
RetVal = RichTextBox1.Find(CommonDialogFind.FindWhat, RichTextBox1.SelStart + RichTextBox1.SelLength, , Options)
Else
RetVal = RichTextBox1.Find(CommonDialogFind.FindWhat, , RichTextBox1.SelStart, Options)
End If
So if Down is selected in the Find common dialog the search in RichTextBox is forward.
If Up is selected then the search appears backward.
But if two hit results are found it's the first from start and not the first from SelStart.
So it's not real backward but for most cases appear ok.
Whatsoever I will look to include Reverse flag soon.
Re: RichTextBox: missing flag at the Find function
Originally Posted by Krool
So it's not real backward but for most cases appear ok.
Currently i use the following function for a real backward search:
Code:
Public Function RTB_FindReverse(ByRef cRTB As VBCCR16.RichTextBox, ByVal sFindText As String, Optional ByVal lStartPos As Long = -1, Optional ByVal lSearchFlags As Long) As Long
Dim I As Long
Dim lPos As Long
Dim TextLen As Long
20 TextLen = Len(sFindText)
30 Call LockWindowUpdate(cRTB.hwnd)
40 If lStartPos = -1 Then
50 lStartPos = Len(cRTB.Text) 'end of file
60 End If
70 For I = lStartPos To 0 Step -1
80 lPos = cRTB.Find(sFindText, I, I + TextLen, lSearchFlags)
90 If lPos <> -1 Then Exit For
100 Next I
110 Call LockWindowUpdate(0)
120 RTB_FindReverse = lPos
End Function
I hope the new reverse flag will help to speed up backward searching through large files...
Or does the RichTextBox of the CommonControls not support this flag?
Thanks Mith. You become a good tester.
The flag 'RtfFindOptionReverse' is now included for the Find method.
It has the same value 16 (&H10) as in the .net RichTextBoxFinds Enum.
Your RTB_FindReverse helper function is slow because you call the .Find method in a loop.
Also in each loop the control blinks as the text is selected unless the NoHighlight enum option was specified.
So please try 'RtfFindOptionReverse'. It should work fast without any need to turn off redrawing.
Originally Posted by samer22
I noticed that when I call the function SetHook I will be unable to use keyboard keys.
Hence, Impossible to write in textboxes
thanks
I tested the code snipped I provided to you again in my MDI_ToolBar demo and it was no problem to write in the textbox of the child form.
Please provide a demo project showing your issue.
Re: CommonControls (Replacement of the MS common controls)
BackColor property in the TabStrip now included.
Also the OCX got updated. I don't like it as it is a functional jump, even it's still binary compatibility.
However, I also found the alternative to wait for 1.7 too stupid. As this feature was so often asked and wqweto now provided a solution...
So still until today OCX is still in sync with Std-EXE version.
The BackColor property in TabStrip will be enriched in future so it also works when VisualStyles is False or DrawMode is OwnerDrawn. This was just the first step.
Also bugfix for "TabStrip1.DrawBackground(hWnd, hDC)" method in this update. The bug was was that an offset could happen due to difference between window rect and client rect.
The new routine is also simplified. It's now directly mapped between client hWnd and TabStrip.
Also instead of SendMessage WM_PAINT it now uses WM_PRINT with PRF_CLIENT + PRF_ERASEBKGND. (for correct result even when theming is off)
Code:
Public Sub DrawBackground(ByVal hWnd As Long, ByVal hDC As Long)
If TabStripHandle <> 0 And hWnd <> 0 And hDC <> 0 Then
Dim RC As RECT, P As POINTAPI
GetClientRect hWnd, RC
MapWindowPoints hWnd, TabStripHandle, RC, 2
P.X = RC.Left
P.Y = RC.Top
SetViewportOrgEx hDC, -P.X, -P.Y, P
SendMessage TabStripHandle, WM_PRINT, hDC, ByVal PRF_CLIENT Or PRF_ERASEBKGND
SetViewportOrgEx hDC, P.X, P.Y, P
End If
End Sub
i created a listview with report mode and defined that the first and fifth column is right-aligned.
i also used FullRowSelect=False and AutoSelectFirstItem=False
after i created the report i get this:
the first item is auto selected but i used AutoSelectFirstItem=False and the alignment is switched from right to left because the item was autoselect...
normally it should look like this:
after i click on another item it looks like this:
1. i can avoid this alignment-swapping when i set FullRowSelect=True.
2. if AutoSelectFirstItem is set to False the control should not autoselect the first item ,or?
3. is it somehow possible to lock the listview without using enable=false to prevent user mouse clicks or keyboard inputs? i guess a .locked property would help here...