CommonControls (Replacement of the MS common controls)

Quote:

---

Originally Posted by Dragokas

Your program crashes on Win2k currently (checked on Win 2k Server SP4 Rollup 2). I added aliases #410/412/413, and it works fine now. I didn't dig deeply to know how and where your subclassing is initiated.
But I know that aliases solved problem for me.

---

In my VM for W2K it does not crash.
Can you remove the aliases again and and comment following out: (green marked)

Code:

---

Public Sub SetupVisualStyles(ByVal Form As VB.Form)
If GetComCtlVersion() >= 6 Then SendMessage Form.hWnd, WM_CHANGEUISTATE, MakeDWord(UIS_CLEAR, UISF_HIDEFOCUS Or UISF_HIDEACCEL), ByVal 0&
If EnabledVisualStyles() = False Then Exit Sub
Dim CurrControl As Control
For Each CurrControl In Form.Controls
    Select Case TypeName(CurrControl)
        Case "Frame"
            SetWindowSubclass CurrControl.hWnd, AddressOf RedirectFrame, ObjPtr(CurrControl), 0
        Case "CommandButton", "CommandButtonW", "CheckBox", "CheckBoxW", "OptionButton", "OptionButtonW"
            If CurrControl.Style = vbButtonGraphical Then
                If CurrControl.Enabled = True Then SetProp CurrControl.hWnd, StrPtr("Enabled"), 1
                SetWindowSubclass CurrControl.hWnd, AddressOf RedirectButton, ObjPtr(CurrControl), ObjPtr(CurrControl)
            End If
    End Select
Next CurrControl
End Sub

---

Does it still crash? And what does GetComCtlVersion() returns in your W2K?

Sorry, Krool, I don't feel well and my answers took a long time.

I think problem is more complicated. Here what I have:

I have 2 states now of VMWare:

1) Fresh install Rollup 2:
Compiled exe crashes.

2) Fresh install Rollup 2 + VB6 IDE installed:
Compiled exe is NOT crashes.
In IDE - crashes.

There was also error on line:

Code:

---

Err.Raise Number:=91, Description:="To use this functionality, you must provide a manifest specifying comctl32.dll version 6.0 or higher."

---

but I commented it. And I sure you specificially created it.

Anyway, do you think problem with compiled EXE arises due to some missing dll in OS?
I'll try to get crash dump.

---
BTW, about subclassing, please forget what I wrote, I confused the source of the problem.

Quote:

---

Originally Posted by Dragokas

Sorry, Krool, I don't feel well and my answers took a long time.

I think problem is more complicated. Here what I have:

I have 2 states now of VMWare:

1) Fresh install Rollup 2:
Compiled exe crashes.

2) Fresh install Rollup 2 + VB6 IDE installed:
Compiled exe is NOT crashes.
In IDE - crashes.

There was also error on line:

Code:

---

Err.Raise Number:=91, Description:="To use this functionality, you must provide a manifest specifying comctl32.dll version 6.0 or higher."

---

but I commented it. And I sure you specificially created it.

Anyway, do you think problem with compiled EXE arises due to some missing dll in OS?
I'll try to get crash dump.

---
BTW, about subclassing, please forget what I wrote, I confused the source of the problem.

---

Your issue is solved when you do: (see Notes in first Post)
In order to trap error raises via "On Error Goto ..." or "On Error Resume Next" it is necessary to have "Break on Unhandled Errors" selected instead of "Break in Class Module" on Tools -> Options... -> General -> Error Trapping.

I decided to compare snapshots with ProcMon.

I found that after adding such reg fix:

Code:

---

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}]
@="VBPropertyBag"

[HKEY_CLASSES_ROOT\CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}\InProcServer32]
@="C:\\WINNT\\system32\\MSVBVM60.DLL"
"ThreadingModel"="Apartment"

---

ComCtlsDemo.exe is no longer crashes on fresh Win 2k without VB6 IDE installed.

Is it can be fixed somehow?

Update released.

Improvement in the CommonDialog.cls. However, the improvement is only meaningful for the ActiveX Control version.
The owner window of an dialog box was determined as following:

Code:

---

If Not Screen.ActiveForm Is Nothing Then
    .hWndOwner = Screen.ActiveForm.hWnd
Else
    .hWndOwner = GetActiveWindow()
End If

---

But 'Screen' will certainly not be meaningful from within the ActiveX Control. It will only be properly in the Std-EXE Version.
Now in order to work in both worlds the 'Screen' object needs to be eliminated. (like it was done with the 'Printer' object before)

Now the owner window for the dialog box is retrieved via API with an helper function in CommonDialog.cls:

Code:

---

.hWndOwner = GetOwnerWindow()

Private Function GetOwnerWindow() As Long
Dim hWnd As Long, hWndMDIClient As Long
hWnd = GetActiveWindow()
If hWnd <> 0 Then hWndMDIClient = FindWindowEx(hWnd, 0, StrPtr("MDIClient"), 0)
If hWndMDIClient <> 0 Then
    Const WM_MDIGETACTIVE As Long = &H229
    GetOwnerWindow = SendMessage(hWndMDIClient, WM_MDIGETACTIVE, 0, ByVal 0&)
Else
    GetOwnerWindow = hWnd
End If
End Function

---

Quote:

---

Originally Posted by Karl77

The toolbar flickers in it's whole size when I set another image for a single button.
It also flickers when I set the same image that was already set.

---

This was fixed by changing 'ClipControls' to True in the UserControl of the ToolBar.

Quote:

---

Originally Posted by Dragokas

Is it can be fixed somehow?

---

No, I have no influence about missing registration key of "VBPropertyBag" on W2K.

Label CCVerticalAlignmentCenter vs. TextBoxW

I discovered this option recently and thought 'nice, now it's easy to align a label to a textbox'.
But now I see it's not perfect.
The label's text is not vertically centered correct.
It is 1 pixel too low.

Attachment 151803

(the red cross is 1 pixel)

Quote:

---

No, I have no influence about missing registration key of "VBPropertyBag" on W2K.

---

It is not missed. It is by default.

Update released.

Major memory usage reduction in the ListView control. The text for the list and list sub items are now retrieved via callback. (LPSTR_TEXTCALLBACK)
Before this update the text for a list item (or list sub item) was stored in a class and also in the API ListView.
Now the text strings are only stored once in the class.

The TreeView, for instance, works different. The text for the nodes are not stored in the class and only in the API TreeView.
So there is actually no need for a callback, so it remains now like it is.

Reason why in the ListView the texts are stored in a class is easy to explain by few examples: (why the texts must be persisted in the class)
- The ListItems and ListSubItems can be created before creating the ColumnHeaders.
- The ListSubItems can be created in any View. So it is possible to change the View later on.

And, by the way, the MS ListView works internally also via LPSTR_TEXTCALLBACK.

Quote:

---

Originally Posted by Karl77

Label CCVerticalAlignmentCenter vs. TextBoxW

I discovered this option recently and thought 'nice, now it's easy to align a label to a textbox'.
But now I see it's not perfect.
The label's text is not vertically centered correct.
It is 1 pixel too low.

Attachment 151803

(the red cross is 1 pixel)

---

The TextBoxW vertical alignment is Top, that's why at some point there will be an offset.
But when I set the TextBoxW and LabelW Height to 255 the offset is 0.
When setting the Height to 315 the offset is 1 and will increase the more the Height is.
Again such thing is expected as the vertical alignment of the TextBoxW is Top.

Also the border on the TextBoxW pushes the text down and right slightly (probably 1 pixel). So if possible, make the LabelW's height smaller (instead of same as TextBoxW's) to account for the TextBoxW border for better alignment.

Quote:

---

Originally Posted by chosk

Also the border on the TextBoxW pushes the text down and right slightly (probably 1 pixel). So if possible, make the LabelW's height smaller (instead of same as TextBoxW's) to account for the TextBoxW border for better alignment.

---

I don't like the idea so very much.
The good thing with the label's vertical centering is to not have to think about this...

EDIT:
Last paragraph removed, that was nonsense.

Textbox problem

In my program I have a routine that selects all text in a textbox when it gets the focus (optional).
This doesn't work with TextBoxW so very well.

Code:

---

Private Sub TextBoxW1_GotFocus()

With TextBoxW1
.SelStart = 0
.SelLength = 999
End With

End Sub

---

The effect is, that the text gets selected from the start to the clicked point.

The intrinsic textbox doesn't show this behavior.
The text gets completely selected as intended.

Quote:

---

Originally Posted by Karl77

Textbox problem

In my program I have a routine that selects all text in a textbox when it gets the focus (optional).
This doesn't work with TextBoxW so very well.

Code:

---

Private Sub TextBoxW1_GotFocus()

With TextBoxW1
.SelStart = 0
.SelLength = 999
End With

End Sub

---

The effect is, that the text gets selected from the start to the clicked point.

The intrinsic textbox doesn't show this behavior.
The text gets completely selected as intended.

---

I did a test with an intrinsic VB TextBox and the TextBoxW:

Code:

---

Private Sub Text1_GotFocus()
With Text1
.SelStart = 0
.SelLength = 999
End With
End Sub

Private Sub TextBoxW2_GotFocus()
With TextBoxW2
.SelStart = 0
.SelLength = 999
End With
End Sub

---

Both do select the whole text at GotFocus but the mouse click changes the length of selection to actual clicked point.
So in my point behavior is exactly the same.

EDIT:
Proper implementation of AutoSelect by OnFocus would be as following:

Code:

---

Private Sub TextBoxW2_GotFocus()
If GetMouseStateFromMsg() = 0 Then
    With TextBoxW2
    .SelStart = 0
    .SelLength = Len(.Text)
    .Tag = "Focused"
    End With
End If
End Sub

Private Sub TextBoxW2_LostFocus()
TextBoxW2.Tag = vbNullString
End Sub

Private Sub TextBoxW2_MouseUp(Button As Integer, Shift As Integer, X As Single, Y As Single)
With TextBoxW2
If .SelLength = 0 And .Tag = vbNullString Then
    .Tag = "Focused"
    .SelStart = 0
    .SelLength = Len(.Text)
End If
End With
End Sub

---

EDIT2:
I could include an "AutoSelectOnFocus" property which would take care of this internally.

i've got SP6, and can confirm the standard common controls textbox has this behavior.

Quote:

---

Originally Posted by Krool

EDIT2:
I could include an "AutoSelectOnFocus" property which would take care of this internally.

---

That would be a nice addition from the MS Access Textbox.

The intrinsic works different from my view and experience.
It is forgiving regarding the mouseclick.

Quote:

---

Originally Posted by Krool

I could include an "AutoSelectOnFocus" property which would take care of this internally.

---

Highly appreciated.
I need the tag property for other things.
Thank you very much.

EDIT:
I'm not sure if "AutoSelectOnFocus" is enough.
This would cover only the case when all shall be selected.

There are other behaviors which require different handling.
All with GotFocus by mouse click into the textbox.
A: Move the cursor to the end
B: Select all and move cursor to the end
C: Select all and move cursor to the start
D: Do nothing, just leave the cursor where it was set by click
As said, no problem with the intrinsic textbox.

If all this should happen in the textbox control, I would need "OnFocusSelectMode".

Wouldn't it be easier to swallow the mouseclick 1x?

EDIT2:
It seems to be a completely different problem.
See from #1758 on.

Quote:

---

Originally Posted by Karl77

The intrinsic works different from my view and experience.
It is forgiving regarding the mouseclick.

---

Can you please provide a Demo showing the different behaviors?

Quote:

---

Originally Posted by Krool

Can you please provide a Demo showing the different behaviors?

---

In the standard textbox, if the click is short (normal click), the selection that was made in the GotFocus event is preserved, but if the mouse button is hold pressed down a bit more time (longer click), in that case the end of selection changes to the clicking point.

(it is my conclussion after a test)

Quote:

---

Originally Posted by Krool

Can you please provide a Demo showing the different behaviors?

---

Good you asked.
In a first attempt, I couldn't find any difference either.
And then I found out why.

See the attached project.
It is made with intrinsic controls only.
Try the different options and see them working as expected.

And then place a TextBoxW1 somewhere.
Don't add any code to it.
See how the formerly working selection in the intrinsic textbox doesn't work anymore.

Interesting effect.
Attachment 151953

Quote:

---

Originally Posted by Karl77

Good you asked.
In a first attempt, I couldn't find any difference either.
And then I found out why.

See the attached project.
It is made with intrinsic controls only.
Try the different options and see them working as expected.

And then place a TextBoxW1 somewhere.
Don't add any code to it.
See how the formerly working selection in the intrinsic textbox doesn't work anymore.

Interesting effect.
Attachment 151953

---

Yes, interesting. But it is not my TextBoxW which is causing this.
You can put any blank UserControl with 'CanGetFocus' to True on the Form.
The issue also only happens when you click on the VB.TextBox from an VB.UserControl. When you click from the VB.CommandButton to the VB.TextBox you have your expected behavior.

EDIT: Again it is better behavior to select all in GotFocus by tab key and in MouseUp when clicking. In MouseUp also only all text will be selected if SelLength is 0. Thus the user is still free to select partially text without overriding. (See my example above)

Quote:

---

Originally Posted by Krool

Yes, interesting. But it is not my TextBoxW which is causing this.
You can put any blank UserControl with 'CanGetFocus' to True on the Form.
The issue also only happens when you click on the VB.TextBox from an VB.UserControl. When you click from the VB.CommandButton to the VB.TextBox you have your expected behavior.

---

That's not what happens to me.

Quote:

---

Originally Posted by Eduardo-

That's not what happens to me.

---

Eduardo, Krool is right.
In here, it also happens with your example.
Not always.

Krool's suggestion to do the selection on MouseUp helps, kind of.

As we must be able to set the focus by Tab key, we need the GotFocus event.
Works good.
But when we set the focus by mouse, the GotFocus kicks in, and does something which is not ok.
No problem, MouseUp cures it.

But it doesn't look clean, we can see the selection change from GotFocus to MouseUp.

I remember there is a possibility to check HOW a control got the focus.
http://www.devx.com/vb2themax/Tip/18274

EDIT:
Solved.
We just need to invoke the selection routine in both GotFocus and MouseUp.
See attached project.
Attachment 151957

Sorry Krool for the suspicion on your control.

Quote:

---

Originally Posted by Karl77

As we must be able to set the focus by Tab key, we need the GotFocus event.
Works good.
But when we set the focus by mouse, the GotFocus kicks in, and does something which is not ok.
No problem, MouseUp cures it.

But it doesn't look clean, we can see the selection change from GotFocus to MouseUp

---

That is handled in my example...

Code:

---

Private Sub TextBoxW2_GotFocus()
If GetMouseStateFromMsg() = 0 Then
    With TextBoxW2
    .SelStart = 0
    .SelLength = Len(.Text)
    .Tag = "Focused"
    End With
End If
End Sub

---

Quote:

---

Originally Posted by Krool

That is handled in my example...

Code:

---

Private Sub TextBoxW2_GotFocus()
If GetMouseStateFromMsg() = 0 Then
    With TextBoxW2
    .SelStart = 0
    .SelLength = Len(.Text)
    .Tag = "Focused"
    End With
End If
End Sub

---

---

Oh well, I didn't see, my eyes only saw the Tag property.
Sorry again.

Quote:

---

Originally Posted by Karl77

Eduardo, Krool is right.
In here, it also happens with your example.

---

Ah, now I think that you mean that it happens to the standard VB TextBox when the focus comes from a Krool's TexBoxW.
I didn't test that.

I tested just with a CommandButton and an UserControl, and it doesn't happen.

Quote:

---

Originally Posted by Karl77

Not always.

---

Only when the click is long. May be VB checks that if the click doesn't pass the double click time, then it preserves the selection, always (at least here in my machine).

Pager small error

I wondered why it is not possible to set the border of a Pager, or the button size.
To retrace, place a command button on the Pager form in the demo, and try

Code:

---

With Pager1
.BorderWidth = 5
.ButtonSize = 200
End With

---

Or use the properties panel.

Nothing happens, because

Code:

---

Public Property Let BorderWidth(ByVal Value As Single)
If Value < 0 Then
    If Ambient.UserMode = False Then
        MsgBox "Invalid property value", vbCritical + vbOKOnly
        Exit Property
    Else
        Err.Raise 380
    End If
End If
Dim IntValue As Integer, ErrValue As Long
On Error Resume Next
IntValue = CInt(UserControl.ScaleX(Value, vbContainerSize, vbPixels))
ErrValue = Err.Number
On Error GoTo 0
If IntValue >= 0 And ErrValue = 0 Then
    PropBorderWidth = IntValue
    If PagerHandle <> 0 Then
        SendMessage PagerHandle, PGM_SETBORDER, 0, ByVal PropBorderWidth
        Me.Refresh
    End If
Else
    If Ambient.UserMode = False Then
        MsgBox "Invalid property value", vbCritical + vbOKOnly
        Exit Property
    Else
        Err.Raise 380
    End If
End If
UserControl.PropertyChanged "BorderWidth"
End Property

---

Something is wrong with IntValue.
If I, just for a test, use Value, then something happens.

---

Perhaps there are some more 'instances' of this.

Attachment 151999



Karl

Quote:

---

Originally Posted by Karl77

Pager small error

I wondered why it is not possible to set the border of a Pager, or the button size.
To retrace, place a command button on the Pager form in the demo, and try

Code:

---

With Pager1
.BorderWidth = 5
.ButtonSize = 200
End With

---

Or use the properties panel.

Nothing happens, because

Code:

---

Public Property Let BorderWidth(ByVal Value As Single)
If Value < 0 Then
    If Ambient.UserMode = False Then
        MsgBox "Invalid property value", vbCritical + vbOKOnly
        Exit Property
    Else
        Err.Raise 380
    End If
End If
Dim IntValue As Integer, ErrValue As Long
On Error Resume Next
IntValue = CInt(UserControl.ScaleX(Value, vbContainerSize, vbPixels))
ErrValue = Err.Number
On Error GoTo 0
If IntValue >= 0 And ErrValue = 0 Then
    PropBorderWidth = IntValue
    If PagerHandle <> 0 Then
        SendMessage PagerHandle, PGM_SETBORDER, 0, ByVal PropBorderWidth
        Me.Refresh
    End If
Else
    If Ambient.UserMode = False Then
        MsgBox "Invalid property value", vbCritical + vbOKOnly
        Exit Property
    Else
        Err.Raise 380
    End If
End If
UserControl.PropertyChanged "BorderWidth"
End Property

---

Something is wrong with IntValue.
If I, just for a test, use Value, then something happens.

---

Perhaps there are some more 'instances' of this.

Attachment 151999



Karl

---

That's normal. Since the ScaleMode of the Form is Twips a value of 5 results in 0 pixels.

Code:

---

That's normal. Since the ScaleMode of the Form is Twips a value of 5 results in 0 pixels.

---

Again I was stupid.
Twips not Pixels.

Update released.

The reason why the StatusBar flickers so much because it flashes between erasing (WM_ERASEBKGND) and drawing (WM_PAINT).
As there was no in-built DoubleBuffer support for the StatusBar it needed to be done manually.
This was achieved by blocking WM_ERASEBKGND and do the erasing and drawing into a memory DC in WM_PAINT.

Also updated the ToolBar concerning the DoubleBuffer property.
The built-in TBSTYLE_EX_DOUBLEBUFFER style is not used anymore. It is now done "manually", likewise as in the StatusBar control now.
This has the advantage that the BackColor and Transparent property are now also working whe DoubleBuffer is set to True.
Also it can be used on comctl32 version 5.8x. (TBSTYLE_EX_DOUBLEBUFFER needed version 6.0 or higher)

Spinbox question

Tried in the 2017-09-22 demo

I want do disallow the user input by keyboard, only the up/down buttons and the mousewheel shall work.
Is the Locked property the right one?
Seems to have no effect...
And what about HideSelection?
I see no difference when True/False.

I assume I'm too blind again, but can't avoid to ask.
What do I have to do to disable the textbox part for direct input?

Thanks,
Karl

Quote:

---

Originally Posted by Karl77

I want do disallow the user input by keyboard, only the up/down buttons and the mousewheel shall work.
Is the Locked property the right one?
Seems to have no effect...
And what about HideSelection?
I see no difference when True/False.

---

The Locked property is the right one. On my side it is working. (also the HideSelection property works as expected)

Quote:

---

Originally Posted by Krool

The Locked property is the right one. On my side it is working. (also the HideSelection property works as expected)

---

Yes, Locked locks the input.
But the cursor blinks, also the whole text is selected.
It looks like an input is possible.
It gets selected when using the up/down buttons.

Try with the attached example.

I get this:
Attachment 152107

Attachment 152109

For those with HideSelection = False did you select the 0 before, because when nothing is selected there is no difference between HideSelection False or True.
The Locked property works as in the normal TextBox. It is your responsibility to give it a "Locked look" by for example setting BackColor to vbButtonFace.

Quote:

---

Originally Posted by Krool

For those with HideSelection = False did you select the 0 before, because when nothing is selected there is no difference between HideSelection False or True..

---

Ok, I didn't understand the meaning of HideSelection, now I do.

Quote:

---

The Locked property works as in the normal TextBox. It is your responsibility to give it a "Locked look" by for example setting BackColor to vbButtonFace.

---

Also understood.

In a normal TextBox I can HideCaret on GotFocus.

Code:

---

Call HideCaret(SpinBox3.hWndEdit)

---

Fine.
Now it doesn't look like as we can type in something.

When the SpinBox has the focus the border indicates that it has it.
When I now use the arrow up/down keys or the mousewheel, we can see the changing numbers.
But when I use the up/down buttons with the mouse, the text gets highlighted.
Not wanted.

I tried this, but it has no effect:

Code:

---

Private Sub SpinBox3_TextChange()

Debug.Print "SpinBox3_TextChange"

SpinBox3.SelStart = 0
SpinBox3.SelLength = 0

Debug.Print "len(SpinBox3.SelText)", Len(SpinBox3.SelText)

End Sub

---

Any idea what I can do to remove the highlight when using the buttons?

Quote:

---

Originally Posted by Karl77

When the SpinBox has the focus the border indicates that it has it.
When I now use the arrow up/down keys or the mousewheel, we can see the changing numbers.
But when I use the up/down buttons with the mouse, the text gets highlighted.
Not wanted.

---

According to MSDN about UpDown controls with edit buddy control:
"WM_LBUTTONUP: Completes the position change and releases the mouse capture if the up-down control has captured the mouse. If the buddy window is an edit control, it selects all the text in the edit control."

So you could process the MouseUp event and undo the text highlighting.

But why you want an locked SpinBox control at all?
If you do not "trust" user input you can validate the user input right away after every input:

Code:

---

Private Sub SpinBox1_TextChange()
Static InProc As Boolean
If InProc = True Then Exit Sub
InProc = True
SpinBox1.ValidateText
InProc = False
' other stuff to do
End Sub

---

Or later on:

Code:

---

Private Sub SpinBox1_LostFocus()
SpinBox1.ValidateText
End Sub

---

Quote:

---

But why you want an locked SpinBox control at all?

---

Because it will replace a now existing selfmade spinbox UC (>10 years old).
And I don't want to change feel.

I will end up in re-creating my old Spinbox UC.
It has a feature that is not there in VBCCR:
Fire the change event after a determined time only.
This means that when I scroll from 1 to 100, I don't get 100 change events.
But after let's say after 0.2 sec. from the last real change.

This 'Change delay' is quite useful when there is more time consuming code to execute.

Quote:

---

Originally Posted by Karl77

Because it will replace a now existing selfmade spinbox UC (>10 years old).
And I don't want to change feel.

I will end up in re-creating my old Spinbox UC.
It has a feature that is not there in VBCCR:
Fire the change event after a determined time only.
This means that when I scroll from 1 to 100, I don't get 100 change events.
But after let's say after 0.2 sec. from the last real change.

This 'Change delay' is quite useful when there is more time consuming code to execute.

---

You can implement this behavior by putting the time-consuming code in a timer. The timer should be initially disabled, interval=200.
Then, all you have to do is:

vb Code:

Private Sub SpinBox1_TextChange()
Timer1.Enabled = False  'Reset timer
Timer1.Enabled = True
End Sub
 
Private Sub Timer1_Timer()
Timer1.Enabled = False
 
'Your code ...
End Sub

Quote:

---

Originally Posted by Cube8

You can implement this behavior by putting the time-consuming code in a timer. The timer should be initially disabled, interval=200.
Then, all you have to do is:

vb Code:

Private Sub SpinBox1_TextChange()
Timer1.Enabled = False  'Reset timer
Timer1.Enabled = True
End Sub
 
Private Sub Timer1_Timer()
Timer1.Enabled = False
 
'Your code ...
End Sub

---

That's what I have in my old ugly UC.
I would like to have the timer in the UC, because if you have some SpinBoxes on a form, then you need as much timers or a more sophisticated approach.
Not so comfy and save.

EDIT:
Regarding the manual input into the SpinBox, I changed my mind.
While investigating the old UC, I saw there is the min/max range check already in the change event.
So no risk to trust the user, the value is always correct.

EDIT2:
This automatic 'stay in range' is not given in the VBCCR SpinBox.
Set Max to 10, and type in 123.
It can be that that is a correct behavior.
But correct doesn't always make sense.

EDIT3:
The VBCCR SpinBox is far better than mine, no question.
Mousewheel, arrow keys etc.
That's why I want to use it instead of my 'solution'.

In the end, too easy...

I can pack the VBCCR Spinbox into an own UC and add the wanted functionality.

Still don't like that the text gets selected when using the up/down control.
Ok, I could set the SpinBox text again in it's Change event, but with a delay it doesn't look very well.
So I leave it as it is.

This is my solution now:
Attachment 152191

EDIT:
Found a glitch in the VBCCR SpinBox.
If I paste a value using the context menu, the Change event doesn't fire.
To retrace:
Select the text in the SpinBox by mouse.
Right-click, and Paste.
As the Change event doesn't come, no chance to check for the Min/Max range.

I was using a previous version of the ocx . It was the one released about 10 days ago and everything was fine . I have a user control which has a listview .

I have just updated to the current version and here is what happens :

If the listview is populated and I end the project by "End" word or even by pressing the "break"command in IDE , VB crashes . This does not happen when the listview is not populated .
Note 1 I use no subclassing at all .

Edit 1 : I have no code in form_unload or in usercontrol_terminate

Edit 2 : the previous version number is
14-Sep-2017
- Revision update. (Version 1.4.51)

Quote:

---

Originally Posted by Karl77

EDIT:
Found a glitch in the VBCCR SpinBox.
If I paste a value using the context menu, the Change event doesn't fire.
To retrace:
Select the text in the SpinBox by mouse.
Right-click, and Paste.
As the Change event doesn't come, no chance to check for the Min/Max range.

---

It's not a bug. The Change event does only fire when the .Value property changes.

When I open your project and Paste via ContextMenu a value of 342 the Change event will be fired as the value has changed to 100.
In case you paste again 342 you get then "342342". However the value has not changed from 100. (equal to Max)
If you want to catch up everything you need to handle the TextChange event and do .ValidateText.

Quote:

---

Originally Posted by Hosam AL Dein

I was using a previous version of the ocx . It was the one released about 10 days ago and everything was fine . I have a user control which has a listview .

I have just updated to the current version and here is what happens :

If the listview is populated and I end the project by "End" word or even by pressing the "break"command in IDE , VB crashes . This does not happen when the listview is not populated.

---

I cannot replicate with the current OCX. at least in a blank project. Can you provide a demo showing the problem?

Quote:

---

Originally Posted by Krool

The reason why the StatusBar flickers so much because it flashes between erasing (WM_ERASEBKGND) and drawing (WM_PAINT).
As there was no in-built DoubleBuffer support for the StatusBar it needed to be done manually.
This was achieved by blocking WM_ERASEBKGND and do the erasing and drawing into a memory DC in WM_PAINT.

---

Thanks Krool, this was probably the cause of the issue I mentioned in a prior post . I'll try to setup my example again and confirm if the problem is gone.

I made a separate project then added the usercontrol with the latest ocx version and the problem does not occur . How can I replicate the bug which causes vb to crash ?

Quote:

---

Originally Posted by Hosam AL Dein

I made a separate project then added the usercontrol with the latest ocx version and the problem does not occur . How can I replicate the bug which causes vb to crash ?

---

If that didn't work the typical strategy is to start with a copy of your project, and continue stripping it down until you find your bug.

Quote:

---

Originally Posted by DEXWERX

If that didn't work the typical strategy is to start with a copy of your project, and continue stripping it down until you find your bug.

---

thanks dexwerx , I will give this a try

the frameW control forecolor is not working . Is this because I am using an earlier version or I am missing something ? . I am using version 14-Sep-2017 - Revision update. (Version 1.4.51)

Quote:

---

Originally Posted by Hosam AL Dein

the frameW control forecolor is not working . Is this because I am using an earlier version or I am missing something ? . I am using version 14-Sep-2017 - Revision update. (Version 1.4.51)

---

The new FrameW is only in the Std-EXE version. It will be included in the next OCX version 1.5.

Quote:

---

Originally Posted by Hosam AL Dein

I made a separate project then added the usercontrol with the latest ocx version and the problem does not occur . How can I replicate the bug which causes vb to crash ?

---

btw, ending a project with "END" keyword should only be used for debugging purpose.
it's like telling Vb to "crash" the project, like the Stop button in the IDE.
all handle will stay open wich might under some circonstance crash the project like you experience.

Krool: does some of the component of the use Subclassing ? could crash under some circonstance.

RichTextBox

.SelFontName returns the string + a bunch of 00.
When using Richtx32.ocx it's correct.

Try the attached.Attachment 152317

Quote:

---

Originally Posted by Karl77

RichTextBox

.SelFontName returns the string + a bunch of 00.
When using Richtx32.ocx it's correct.

---

Done. Thanks
OCX + Std-EXE got updated.

Quote:

---

Originally Posted by VbNetMatrix

Krool: does some of the component of the use Subclassing ? could crash under some circonstance.

---

What do you mean? If you mean the ComCtls then yes, they make heavy use of subclassing. Also VTable wise subclassing.
The Std-EXE version will never be "End" secure as even when the subclassing could be done via ASM the VTable subclassing will still crash.
So I stick to non-ASM subclassing (as it makes no sense) and just catch the "Stop" button via ComCtlsInitIDEStopProtection.
However, the OCX should be certainly crash-free, even by "End".

Toolbar question

I use the EXE version, but it is exactly the same with the OCX.

I found that my way of populating a toolbar takes quite long.
39 buttons/placeholders take 250msec.
Also while a toolbar gets filled, the whole screen flickers.
This happens when the containing form gets loaded, at this time it is not visible.
Don't know if the toolbar itself flickers.
I'm unhappy with the _screen_ flicker and the long processing time.

I already tried to set Visible and Enabled, but it has no effect on the loading times and still flickers.
Is there a built-in method to get that much faster, and also to avoid the screen flicker?

Code:

---

tc = GetTickCount

With MF.tbr_Main

    .AllowCustomize = False
    .BackColor = ToolbarBackColor
    .Buttons.Clear
    Set .ImageList = IL 'the ImageList is a VBBCR ImageList
    .Divider = False
    .ShowTips = True
    .DoubleBuffer = False
    .Transparent = Not True
    .MinButtonWidth = 0
    .MaxButtonWidth = 0
    .TextAlignment = TbrTextAlignBottom

    Set B = .Buttons.Add(, "new", , TbrButtonStyleDefault, "new")
    B.ToolTipText = "New"

    Set B = .Buttons.Add(, , , TbrButtonStyleSeparator)

    'etc.

    .GetIdealSize WS, HS
    .Width = WS
    .Height = HS

    Set B = Nothing

End With

ms = CStr(GetTickCount - tc) & " msec."
m = m & "Time to populate: " & vbCrLf & ms & vbCrLf

'this comes after all toolbars are ready
Debug.Print m

---

Karl

Make .DoubleBuffer = True instead of False to avoid flicker.

Quote:

---

Originally Posted by Krool

Make .DoubleBuffer = True instead of False to avoid flicker.

---

I tried before.
No effect on the screen flicker.
It is a desktop flicker, not the toolbar itself.

I can clearly see in my app the flicker comes from populating the toolbars.
I have 11 toolbars, and the flicker occurs 11x.
Nothing else is done when it happens.

Unfortunately, and 'of course', in a small demo app there is no desktop flicker.

But the long time to populate.
The CC5 toolbar is ready in no time.
Hmm.

Still need an idea.

What is the possibility of getting a multicolumn Combobox in the queue? Or is there one already there?

Quote:

---

Originally Posted by Karl77

Still need an idea.

---

Found out how to avoid the screen flicker.
When I comment out this:

Code:

---

.TextAlignment = TbrTextAlignBottom

---

then no flicker occurs.

EDIT:
Also the performance is FAR better, 78 instead of 250msec.
Of course without the TextAlignment property, the toolbars are not as intended.

EDIT2:
The flicker is also there when I set TextAlignment after populating the buttons.

Update released.

The performance of the ToolBar has been increased.
This was achieved by internally doing at some points (if applicable) a invalidation instead of a refresh.

Quote:

---

Originally Posted by Karl77

Found out how to avoid the screen flicker.
When I comment out this:

Code:

---

.TextAlignment = TbrTextAlignBottom

---

then no flicker occurs.

---

Changing .TextAlignment will cause re-creating of the control. During the re-creation LockWindowUpdate is used:

Code:

---

Private Sub ReCreateToolBar()
Dim Locked As Boolean
With Me
Locked = CBool(LockWindowUpdate(UserControl.hWnd) <> 0)
[...]
If Locked = True Then LockWindowUpdate 0
.Refresh
End With

---

Maybe LockWindowUpdate does cause a screen flicker in your particular app, just a guess.

Solution could be to set the .TextAlignment already at design-time to the wanted value.

Quote:

---

Originally Posted by gwboolean

What is the possibility of getting a multicolumn Combobox in the queue? Or is there one already there?

---

You mean something like this ?

Hi Krool,

That's a nifty little C# project you've linked to in the prior post. Too bad it's not VB6.

It looks like they've taken a standard ComboBox and attached a ListView to it for the dropdown. With that understanding, this seems like it'd be a fairly straightforward project for a custom User Control (possibly using your controls to start with). It's also somewhat nifty that the dropdown can go outside of the main form (which is also true of a standard ComboBox). It may take a bit of doing to work that out, but not that big a deal. As stated in a recent thread, I'd just use a second form to do that.

Take Care,
Elroy

Quote:

---

Originally Posted by Krool

During the re-creation LockWindowUpdate is used:

---

From what I understand, MS says WM_SETREDRAW should be used instead.
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx
Why did you decide for LockWindowUpdate?
Just curious.

Quote:

---

Originally Posted by Karl77

From what I understand, MS says WM_SETREDRAW should be used instead.
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx
Why did you decide for LockWindowUpdate?
Just curious.

---

Refer to http://www.vbforums.com/showthread.p...=1#post5108773 for reason and explanation.

Hello,

Sorry for my English, (google translated!)

Me too, I noticed this effect with "LockWindowUpdate (0)":(. The whole screen is refreshed, causing the flicker.
I prefer the "ValidateRect / InvalidateRect" method and generate a PAINT when necessary. Or make a DoEvents (by managing the reantrance)..
With this method, I do not have the blinking of the screen.