Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Erwin69
Thanks Karl. I'll need to study this a bit more.
My app has a limited set of buttons, so manually adding these is not the issue. The challenge is more the use of transparency.
I've taken this update as an opportunity to "modernize" the toolbar look and feel. As part of the pre-work, I collected/designed/created a series of images that are all saved in PNG-format with transparency. As that format unfortunately isn't supported by the VBCCR imagelist (and not by the original either), I need to figure out what the best approach is.
About transparency, you can communicate with me in this respect. I also like to make the controls more beautiful.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by xiaoyao
About transparency, you can communicate with me in this respect. I also like to make the controls more beautiful.
StdPicture objects are restricted.
They can be "enhanced" by vtable hacks to allow gdi+.
However, that is the responsibility of the app todo and not of the VBCCR.
The pictures are "owned" by the app and VBCCR just "borrows" them. It would be dangerous if there is any action on the objects which will "change" them.
And doing private copies would kill "compatibility".
Anyhow, see below for a solution: https://www.vbforums.com/showthread....to-Support-GDI
Re: CommonControls (Replacement of the MS common controls)
I have recently started using these common control replacements and have found that in the existing TabStrip control there is a way to disable 1 specific Tab to prevent it from being selected using an Enabled variable in the Tab object of the TabCollection, however I cannot clearly see a way to do so utilising the replacement, unless I rework the event handle to ignore input to that tab unless a seperate boolean is used to control the function.
Is such functionality not possible to expose, or is there a better alternative method?
Re: CommonControls (Replacement of the MS common controls)
the MS Common Control Tabstrip does not have an Enable Property for each tab (although I don't know why).
You are referring to the SSTab, which is a complete different control, which creates its own container for each tab.
to get around this limitation, you can use the TabBeforeClick Event.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Shadic
I have recently started using these common control replacements and have found that in the existing TabStrip control there is a way to disable 1 specific Tab to prevent it from being selected using an Enabled variable in the Tab object of the TabCollection, however I cannot clearly see a way to do so utilising the replacement, unless I rework the event handle to ignore input to that tab unless a seperate boolean is used to control the function.
Is such functionality not possible to expose, or is there a better alternative method?
I've been converting my application to the VBCCR Unicode controls, and added the VBFlexGrid (also by Krool) and the SSTabEx (by Eduardo) to the toolkit. I am very happy with the quality of the controls, and the great support that is given via this forum.
Re: CommonControls (Replacement of the MS common controls)
Krool,
I'm using your tab control and no text is being shown for Labels. Button and textboxes seem fine. It's like the Label control will not bind to the tab page at all. Link Labels seem to work.
Using VBCCR17.
Last edited by ScriptBASIC; Apr 23rd, 2021 at 01:36 PM.
Re: CommonControls (Replacement of the MS common controls)
I set the form to use pixel scaling mode which has been working fine until I got to adding controls to the tab page. It looks like twips is the only scale mode the tab page accepts.
Re: CommonControls (Replacement of the MS common controls)
Krool,
I decided to go with the SSTab control. It allows me to add controls to the pages in design time and easier to deal with. FWIW this control also only accepts twips. I guess that is just how it is.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by ScriptBASIC
I set the form to use pixel scaling mode which has been working fine until I got to adding controls to the tab page. It looks like twips is the only scale mode the tab page accepts.
What does not work in pixel scaling mode? Demo? Code?
Re: CommonControls (Replacement of the MS common controls)
Adding controls worked fine. My only comment was that if I use pixel scaling the tab pages only accepts twips, nothing else. As mentioned I moved to SSTab as I don't what to have to deal with separate forms for tab pages and only able to test in runtime.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by ScriptBASIC
Adding controls worked fine. My only comment was that if I use pixel scaling the tab pages only accepts twips, nothing else. As mentioned I moved to SSTab as I don't what to have to deal with separate forms for tab pages and only able to test in runtime.
The TabStrip has no "tab pages". if you use a VB.Frame (or FrameW) then this container ("tab page") is always in twips. If you want to use pixels, then use a VB.PictureBox.
Re: CommonControls (Replacement of the MS common controls)
My understanding is the tabstrip is just that. "Tab pages" are referred to as property pages which threw me for a loop. The tabstrip only shows the first page and clicking on the other tabs do nothing in the IDE. SSTab made that work like I expected. Thanks for the tip on using picturebox rather then frames to use pixel scaling.
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Here is the result of our conversations. The picturebox frame replacement to get pixel scaling and using SSTab saved me a ton of time with this migration project I'm doing.
Re: CommonControls (Replacement of the MS common controls)
Hi krool ,
1- In toolbar , Is there a way to assign a font for a specific button instead of affecting all the buttons ? Like the ForeColor property that is assigned for the toolbar button .
The reason , to replace button images by font icons like font awesome as an example .
This will add flexibility to color changing and the size of the button graphics .
Last edited by Hosam AL Dein; May 7th, 2021 at 05:16 AM.
Re: CommonControls (Replacement of the MS common controls)
Dear Krool,
Thanks, as always, for your altruistic work.
I have been, for the first time, trying the CoolBar control since the past 2 or 3 days. I have an issue with UseChevron option.
I followed your instructions in https://www.vbforums.com/showthread....=1#post5002991, on how to avail the UseChevron option. The thing is that when the ideal width is reached, a white vertical strip appears but without the chevron symbol. When I click on that white strip, the BandChevronPushed event does get fired.
So, I experimented by ticking and unticking the various options in quite a few combinations. What worked finally was unticking the 'VisualStyles' option under 'General' tab. But then, naturally, the visual styles are gone. I created the ComCtlsDemo.exe (with 'VisualStyles' option ticked) and tried it. Only white strip appears. Clicking on it fired the BandChevronPushed event. I tried that same ComCtlsDemo.exe in a Win7 system. There also, same result.
So, am I missing something? How to make the chevron appear without unticking the 'VisualStyles' option?
And, one more question. After unticking the 'VisualStyles' option and making the chevron appear, I tried it for a band with Toolbar control. When the ideal width is reached, the chevron appears. But when I clicked the chevron, the hidden items of the toolbar control do not show up. Have we to show the hidden items manually by writing code in BandChevronPushed event?
Note:
- I am using the latest version of your controls (downloaded 2 days back)
- I am on Windows 10 Home. I created the ComCtlsDemo.exe therein only.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Hosam AL Dein
Hi krool ,
1- In toolbar , Is there a way to assign a font for a specific button instead of affecting all the buttons ? Like the ForeColor property that is assigned for the toolbar button .
The reason , to replace button images by font icons like font awesome as an example .
This will add flexibility to color changing and the size of the button graphics .
It's possible to return CDRF_NEWFONT on NM_CUSTOMDRAW for a toolbar. However, I can remember playing around with it and it bugged as the button size will not change accordingly.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by ScriptBASIC
Hi Krool,
Here is the result of our conversations. The picturebox frame replacement to get pixel scaling and using SSTab saved me a ton of time with this migration project I'm doing.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by softv
Dear Krool,
Thanks, as always, for your altruistic work.
I have been, for the first time, trying the CoolBar control since the past 2 or 3 days. I have an issue with UseChevron option.
I followed your instructions in https://www.vbforums.com/showthread....=1#post5002991, on how to avail the UseChevron option. The thing is that when the ideal width is reached, a white vertical strip appears but without the chevron symbol. When I click on that white strip, the BandChevronPushed event does get fired.
So, I experimented by ticking and unticking the various options in quite a few combinations. What worked finally was unticking the 'VisualStyles' option under 'General' tab. But then, naturally, the visual styles are gone. I created the ComCtlsDemo.exe (with 'VisualStyles' option ticked) and tried it. Only white strip appears. Clicking on it fired the BandChevronPushed event. I tried that same ComCtlsDemo.exe in a Win7 system. There also, same result.
So, am I missing something? How to make the chevron appear without unticking the 'VisualStyles' option?
And, one more question. After unticking the 'VisualStyles' option and making the chevron appear, I tried it for a band with Toolbar control. When the ideal width is reached, the chevron appears. But when I clicked the chevron, the hidden items of the toolbar control do not show up. Have we to show the hidden items manually by writing code in BandChevronPushed event?
Note:
- I am using the latest version of your controls (downloaded 2 days back)
- I am on Windows 10 Home. I created the ComCtlsDemo.exe therein only.
Kind Regards.
I found the bug and know how to fix it when I have time.
Meanwhile you can workaround it by setting the conditional compilation constant 'ImplementThemedReBarFix' to False.
This results that the ForeColor property though does not work anymore for a band. Also something else does not work in exotic circumstances.
That's why I have implemented such a themed "fix" and as side effect it allows custom fore color for a band.
What I simply missed was to draw the chevron. But that will be an easy one to fix I think as the v6 rebarbandinfo has the chevron rects and states.
Be patient, thanks.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
I found the bug and know how to fix it when I have time.
Meanwhile you can workaround it by setting the conditional compilation constant 'ImplementThemedReBarFix' to False.
This results that the ForeColor property though does not work anymore for a band. Also something else does not work in exotic circumstances.
That's why I have implemented such a themed "fix" and as side effect it allows custom fore color for a band.
What I simply missed was to draw the chevron. But that will be an easy one to fix I think as the v6 rebarbandinfo has the chevron rects and states.
Be patient, thanks.
Thanks a TON, krool. I shall definitely wait. No urgency at all.
You give such fabulous controls for free!
And, on top of it, you give 100% free support too!!
That too, so promptly!!!
Re: CommonControls (Replacement of the MS common controls)
Update released.
The RP_CHEVRON/RP_CHEVRONVERT parts are now included in the 'ImplementThemedReBarFix'. (reported by softv)
In this regard I found another bug. When the UseChevron property of a Band will be changed then the band's header portion will not be automatically refreshed.
As can be seen in the image below, after the UseChevron got applied, the text "asd" is truncated. Now with the bugfix the band's header portion will be refreshed. (.CXHeader member, RBBIM_HEADERSIZE, = -1)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released.
The RP_CHEVRON/RP_CHEVRONVERT parts are now included in the 'ImplementThemedReBarFix'. (reported by softv)
In this regard I found another bug. When the UseChevron property of a Band will be changed then the band's header portion will not be automatically refreshed.
As can be seen in the image below, after the UseChevron got applied, the text "asd" is truncated. Now with the bugfix the band's header portion will be refreshed. (.CXHeader member, RBBIM_HEADERSIZE, = -1)
Dear Krool,
Warm Greetings! And, Thanks a TON for the update.
By the by, I have one more observation to share. As far as I tested (trying out various options), the vbSizeWE mouse pointer was not getting set when mouse moves over the resizing portion (dotted line) of a child coolbar. By child coolbar, I mean a coolbar (say, cbr2) which is nested in one of the bands of a parent coolbar (say, cbr1). I tried putting cbr2 inside a frame too (the frame being inside one of the bands of cbr1)
As of now, my workaround is as follows. My 'cbr2' has 3 bands with 3 command buttons (as a control array) in them:
--
Private Sub cbr2_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
cbr2.MousePointer = vbSizeWE
End Sub
Private Sub CommandButtonW_MouseMove(Index As Integer, Button As Integer, Shift As Integer, X As Single, Y As Single)
cbr2.MousePointer = vbNormal
End Sub
--
Sorry if I am wrong in my observation (which resulted in the above workaround). If there is indeed a straightforward solution, kindly let me know the same.
Re: CommonControls (Replacement of the MS common controls)
I'm sorry for my bad English.
I am a user of VB6 only as a hobby, without extensive training. I learn by doing.
I was very happy when I discovered this great project. For me it is a boon. I got there looking for both a RichText control and a slider, both of which can be modified to suit my needs.
Regarding the slider I have already found a way to implement the resizing of the cursor (Thumb - TBS_FIXEDLENGTH - TBM_SETTHUMBLENGTH), so that it is more suitable for touch screens.
Would there be a not too difficult way to change the cursor image (Thumb)? If I'm not mistaken, I've seen the possibility exists (NM_CUSTOMDRAW - TBCD_THUMB) but I just don't know how to use it.
Re: CommonControls (Replacement of the MS common controls)
I found and resolved several critical errors that can cause controls to crash at runtime especially with multiple instances. Most of them are due to naming collisions with VB keywords, ie Format, Width, Height, Month, Day etc. Microsoft warned that overriding keywords can cause runtime/designtime errors to occur. I posted a video listing the errors that need to be addressed. A few of them are false positives due to an earlier error in the parsing. But, there are also false negatives hidden that appear once the original errors have been resolved. VBCCR17 name collision errors causing random crashes at runtime
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by softv
By the by, I have one more observation to share. As far as I tested (trying out various options), the vbSizeWE mouse pointer was not getting set when mouse moves over the resizing portion (dotted line) of a child coolbar. By child coolbar, I mean a coolbar (say, cbr2) which is nested in one of the bands of a parent coolbar (say, cbr1). I tried putting cbr2 inside a frame too (the frame being inside one of the bands of cbr1)
As of now, my workaround is as follows. My 'cbr2' has 3 bands with 3 command buttons (as a control array) in them:
--
Private Sub cbr2_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
cbr2.MousePointer = vbSizeWE
End Sub
Private Sub CommandButtonW_MouseMove(Index As Integer, Button As Integer, Shift As Integer, X As Single, Y As Single)
cbr2.MousePointer = vbNormal
End Sub
Update released.
If the child control is only in the CoolBar "container" then there was no issue. But if it's a child control of a band (= child of ReBarWindow32) then the issue occured.
The CoolBar has been updated so the child controls can walk up the chain properly in the WM_SETCURSOR handler.
There is no workaround needed anymore.
I have tested it well, also in regards to Form.MousePointer in play etc. and this is the most straight forward solution for natural behavior in VB.
For those interested, the code marked in blue is the addition.
Code:
Case WM_SETCURSOR
If LoWord(lParam) = HTCLIENT Then
Dim hCursor As Long
If MousePointerID(PropMousePointer) <> 0 Then
hCursor = LoadCursor(0, MousePointerID(PropMousePointer))
ElseIf PropMousePointer = 99 Then
If Not PropMouseIcon Is Nothing Then hCursor = PropMouseIcon.Handle
End If
If hCursor <> 0 Then
SetCursor hCursor
WindowProcControl = 1
Exit Function
ElseIf hWnd <> wParam And wParam <> 0 Then
' Ensures that the cild controls can walk up the chain properly.
WindowProcControl = DefWindowProc(hWnd, wMsg, wParam, lParam)
Exit Function
End If
End If
[...]
WindowProcControl = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
Originally Posted by TTn
Multiple instances of a control on a form.
Can you provide samples to replicate such crashes ?
Re: CommonControls (Replacement of the MS common controls)
It's a random thing at runtime as I said. Not all of the controls appear to have the problem. The only easy solution for me was to resolve any and all naming collisions to take the load off of the designer/runtime.
Did you see the video?
The word "Format" is causing the designer to jump to a definition in another procedure. But then, I tested after the video, and that word jumped correctly to the right definition.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by TTn
Multiple instances of a control on a form.
I use multiple instances of the following controls on many forms and never run into any problems: labelW, textboxW, comboboxW, checkboxW, optionbuttonW, frameW
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
I use multiple instances of the following controls on many forms and never run into any problems: labelW, textboxW, comboboxW, checkboxW, optionbuttonW, frameW
How to force this problem?
Again, this problem is intermittent, aka random at design/runtime.
Microsoft said that you should not use those reserved words because design/runtime errors can occur.
Here is a list released by MS that includes Format, Width, Height etc.
Abs Access AddItem AddNew Alias And Any App AppActivate Append AppendChunk
Arrange As Asc Atn Base Beep BeginTrans Binary ByVal Call Case CCur CDbl
ChDir ChDrive Chr Chr$ CInt Circle Clear Clipboard CLng Close Cls Command
Command$ CommitTrans Compare Const Control Controls Cos CreateDynaset CSng
CStr CurDir$ Currency CVar CVDate Data Date Date$ DateSerial DateValue Day
Debug Declare DefCur CefDbl DefInt DefLng DefSng DefStr DefVar Delete Dim
Dir Dir$ Do DoEvents Double Drag Dynaset Edit Else ElseIf End EndDoc EndIf
Environ$ EOF Eqv Erase Erl Err Error Error$ ExecuteSQL Exit Exp Explicit
False FieldSize FileAttr FileCopy FileDateTime FileLen Fix For Form Format
Format$ Forms FreeFile Function Get GetAttr GetChunk GetData DetFormat GetText
Global GoSub GoTo Hex Hex$ Hide Hour If Imp Input Input$ InputBox InputBox$
InStr Int Integer Is IsDate IsEmpty IsNull IsNumeric Kill LBound LCase
LCase$ Left Left$ Len Let Lib Like Line LinkExecute LinkPoke LinkRequest
LinkSend Load LoadPicture Loc Local Lock LOF Log Long Loop LSet LTrim
LTrim$ Me Mid Mid$ Minute MkDir Mod Month Move MoveFirst MoveLast MoveNext
MovePrevious MoveRelative MsgBox Name New NewPage Next NextBlock Not Nothing
Now Null Oct Oct$ On Open OpenDataBase Option Or Output Point Preserve
Print Printer PrintForm Private PSet Put QBColor Random Randomize Read ReDim
Refresh RegisterDataBase Rem RemoveItem Reset Restore Resume Return RGB Right
Right$ RmDir Rnd Rollback RSet RTrim RTrim$ SavePicture Scale Second Seek
Select SendKeys Set SetAttr SetData SetFocus SetText Sgn Shared Shell Show
Sin Single Space Space$ Spc Sqr Static Step Stop Str Str$ StrComp String
String$ Sub System Tab Tan Text TextHeight TextWidth Then Time Time$ Timer
TimeSerial TimeValue To Trim Trim$ True Type TypeOf UBound UCase UCase$
Unload Unlock Until Update Using Val Variant VarType Weekday Wend While
Width Write Xor Year ZOrder
Trust me, it serves no good purpose to use these words as parameters etc.
Re: CommonControls (Replacement of the MS common controls)
Confirm the fix by changing the two/or-more affected functions in the RichTextBox module.
Code:
Public Sub OLEObjectsAddFromPicture(ByVal Picture As IPictureDisp, Optional ByVal fmt As Variant)
'new body here
Format 'Right click Format token, then click goto definition in the object browser. Success!
End Sub
Public Sub SaveFile(ByVal FileName As String, Optional ByVal fmt As RtfLoadSaveFormatConstants = RtfLoadSaveFormatRTF, Optional ByVal SelectionOnly As Boolean)
'new body here
End Sub
Now the variable/param can't jump to another function/sub.
Re: CommonControls (Replacement of the MS common controls)
Just so everyone can get an idea of the various ways these manifest, take a look at line 461 in the Slider module.
Code:
Dim Width As Long, Height As Long
Width = .ScaleWidth
Height = .ScaleHeight
'some code end with
MoveWindow SliderHandle, 0, 0, Width, Height, 0
Looks ok, but it ran into a different kind of collision. Comment out the dimensions for Width and Height.
Now jump to definition from the param Width in the MoveWindow function.
You will end up jumping to the module property for Width, that expects an argument.
Technically, this word token should stay hidden and reserved for Width of Me.
Another kind of problem is assignments to constants not permitted. Line 958 of module CommonDialog.
The word "Color" is a member of LoadPictureConstants.
Line 158 of LvwColumnHeader. The word "Checked" is a member of OLE_TRISTATE.
Code should be explicitly named not to collide, because it causes a collective load at design/runtime.
Some other words to fixup are: Month, Day, DateValue. Some of these may have various layers of issues that can occur in different ways, because the month and day are used in a loop, and as properties, and as reserved words.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Eduardo-
Could you describe steps by steps how to reproduce a single problem? (just one case, but clear)
Are you complaining that it is confusing the object browser when you look for a definition or what?
I want to see one example to reproduce this problem without altering the existing code like he described at #3157.
i only use the original compiled VBCCR OCX version and never expierend any problems.
Maybe you can run into this problem only when you use the source code?
Re: CommonControls (Replacement of the MS common controls)
I described enough for you to reproduce a design error that jumps between procedures. Confirm by changing the word/function "Format" to "fmt". I've been clear. You're not supposed to use reserved words. The compiler does an error parsing in a specific order, when looking for definitions deciding to filter a parsed error or not. Errors like that can cause false results as seen, because those words are seen globally. Why would you want to continue using the word Format if it can cause global jumps to unrelated parameters? I've presented a clear list of words that should not be used as parameters or variables.