Re: CommonControls (Replacement of the MS common controls)
I noticed a small glitch in the display of the StatusBar (using VBCCR14.ocx). When a panel is visible showing the time there is a noticeable flicker whenever the time is updated. This could be, obviously, at a rate of 1 Hz (once per second) which is frequent enough to be an inconvenient problem.
I eventually realized that this occurs whether you use the built-in time feature of the control, or do something like use a timer control to manually update the time string. Probably it flickers with any update but only the frequent clock-based ones are noticed.
I have no idea if this is something which could conceivably be fixed, and it may not be worth the time even if it is, but I thought I should at least point it out. I'm running Windows 7 64 bit in case that makes any difference.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
If it is time display on a Statusbar panel, I don't see any flicker. I attached a short video. For this I am using the VBCCR14.ocx. Win7 x64.
After seeing your video (nicely done BTW) I did some more tests to see if I could find another cause of the flicker. I could not. I disabled the entire timer event because it did some other manipulations of form controls and thought it was possible this could be causing the flicker. But no, even with the timer totally nonfunctional the flicker occurs. And if I switch the panel type from time to text, the flicker stops.
What difference between our programs (or systems) are we overlooking which might cause this?
Re: CommonControls (Replacement of the MS common controls)
Update released.
The AutoSize property in the LabelW control got improved. The auto sizing is now done independently in a separate routine with a memory DC, thus not located anymore in the UserControl_Paint procedure.
That change makes it now possible set the .AutoSize = True during Form_Load and check immediately after the .Width property.
Therefore the behavior in below test from Schmidt is now the same as in the original VB.Label control.
Originally Posted by Schmidt
by another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:
Code:
Private Sub Form_Load()
With Label1
Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
.Font.Name = "Arial"
.Font.Size = 10
.Caption = "Some Text"
.AutoSize = True
Debug.Print .Name; ".Width, after AutoSize True: "; .Width
.Caption = "Some more Text"
Debug.Print .Name; ".Width, after Caption-Change: "; .Width
End With
With LabelW1
.WordWrap = False '<- just to match with the VB.Label Default
Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
.Font.Name = "Arial"
.Font.Size = 10
.Caption = "Some Text"
.AutoSize = True
Debug.Print .Name; ".Width, after AutoSize True: "; .Width
.Caption = "Some more Text"
Debug.Print .Name; ".Width, after Caption-Change: "; .Width
End With
End Sub
The OCX version has also been updated concerning this.
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Regarding the RichTextBox (OCX version. Haven't try the Std-Exe).
I don't know whether this is a bug or is a setting I missed. I have Multiline is True and ScrollBar is 3 - vbBoth. When the content is full, the vertical scroll bar will auto appear. Then when I resize the Form taller (therefore RichTextBox taller) to show all the content, the scrollbar disappear as normal behaviour. However, when I resize the Form back to shorter, the vertical scrollbar doesn't auto re-appear. Only after I let go the mouse and then resize again, then the vertical scrollbar re-appear.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
In that case, a "manually applied" (explicitely coded) HelpContextID-Property might help (altough probably
breaking the BinComp or the SxS-manifest then - but for the next version it might worth a try)...
Then managing the F1-KeyPress yourself inside FrameW (when it got "EnterFocus"-state) - and then
delegating to the usual "Show-Help"-API-Call manually as well.
I want to address that issue further.
Issue is that the FrameW control does not provide a HelpContextID property. (like the VB.Frame)
The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.
So your idea sounds good but in practice how to accomplish?
The manual calling HtmlHelp part with HH_HELP_CONTEXT does work. However, problem remains of how to catch such an F1 keypress?
VB's logic is like this: The current context number is the value of HelpContextID for the object that has the focus. If HelpContextID is set to 0, then Visual Basic looks in the HelpContextID of the object's container, and then that object's container, and so on. If a nonzero current context number can't be found, the F1 key is ignored.
So how to play within that chain in a manual HelpContextID property?
Originally Posted by chosk
I don't know whether this is a bug or is a setting I missed. I have Multiline is True and ScrollBar is 3 - vbBoth. When the content is full, the vertical scroll bar will auto appear. Then when I resize the Form taller (therefore RichTextBox taller) to show all the content, the scrollbar disappear as normal behaviour. However, when I resize the Form back to shorter, the vertical scrollbar doesn't auto re-appear. Only after I let go the mouse and then resize again, then the vertical scrollbar re-appear.
Interesting, thanks for reporting.
Indeed this seems like a minor issue. However, if you set the 'DisableNoScroll' to True this issue will not appear, like in the TextBoxW.
Only when 'DisableNoScroll' is False there is a issue on resize and auto re-appear as you described.
I have found an solution, but I am not quite sure why this is necessary.
Like it is current within UserControl_Resize:
Code:
If RichTextBoxHandle <> 0 Then MoveWindow RichTextBoxHandle, 0, 0, .ScaleWidth, .ScaleHeight, 1
Possible fix:
Code:
If RichTextBoxHandle <> 0 Then
MoveWindow RichTextBoxHandle, 0, 0, .ScaleWidth, .ScaleHeight, 1
InvalidateRect RichTextBoxHandle, ByVal 0&, 0
UpdateWindow RichTextBoxHandle
End If
Possible fix alternative:
Code:
If RichTextBoxHandle <> 0 Then
MoveWindow RichTextBoxHandle, 0, 0, .ScaleWidth, .ScaleHeight, 0
InvalidateRect RichTextBoxHandle, ByVal 0&, 0
UpdateWindow RichTextBoxHandle
SetWindowPos RichTextBoxHandle, 0, 0, 0, 0, 0, SWP_DRAWFRAME Or SWP_NOMOVE Or SWP_NOSIZE Or SWP_NOOWNERZORDER Or SWP_NOZORDER
End If
I don't know why this is necessary as when bRepaint is 1 on MoveWindow this is all supposed to be done...
MSDN: If the bRepaint parameter is TRUE, the system sends the WM_PAINT message to the window procedure immediately after moving the window (that is, the MoveWindow function calls the UpdateWindow function)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
I want to address that issue further.
Issue is that the FrameW control does not provide a HelpContextID property. (like the VB.Frame)
The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.
So your idea sounds good but in practice how to accomplish?
The manual calling HtmlHelp part with HH_HELP_CONTEXT does work. However, problem remains of how to catch such an F1 keypress?
VB's logic is like this: The current context number is the value of HelpContextID for the object that has the focus. If HelpContextID is set to 0, then Visual Basic looks in the HelpContextID of the object's container, and then that object's container, and so on. If a nonzero current context number can't be found, the F1 key is ignored.
So how to play within that chain in a manual HelpContextID property?
If that gets too complicated, there's a quite simple way out (since it's a *very* simple Control really).
Here's a working, pure VB6-approach for such a Frame:
- which consists of an "outer" Public ucFrame.ctl
- and an inner, Private ucNoFocus.ctl (which does the Drawing on itself).
Into the inner ucNoFocus (which gets adjusted with CanGetFocus = False):
Code:
Option Explicit
Private mCaption As String
Private Sub UserControl_Initialize()
AutoRedraw = True
ScaleMode = vbPixels
End Sub
Public Property Get BackColor() As Long
BackColor = UserControl.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
UserControl.BackColor = RHS
End Property
Public Property Get Caption() As String
Caption = mCaption
End Property
Public Property Let Caption(ByVal RHS As String)
mCaption = RHS: UserControl_Resize
End Property
Private Sub UserControl_Resize()
Dim yOffs, xOffs, TW
Const BorderColor = &H888888
Cls
xOffs = 8
yOffs = TextHeight(mCaption) / 2
If Len(mCaption) Then
TW = TextWidth(mCaption)
CurrentX = xOffs + 3: CurrentY = 0: Print mCaption
Line (0, yOffs)-(xOffs, yOffs), BorderColor
Line (0, yOffs)-(0, ScaleHeight), BorderColor
Line (0, ScaleHeight - 1)-(ScaleWidth, ScaleHeight - 1), BorderColor
Line (ScaleWidth - 1, yOffs)-(ScaleWidth - 1, ScaleHeight), BorderColor
Line (ScaleWidth - 1, yOffs)-(xOffs + 6 + TW, yOffs), BorderColor
Else
Line (0, 0)-(ScaleWidth - 1, ScaleHeight - 1), BorderColor, B
End If
End Sub
And this into the outer ucFrame-Control with the above ucNoFocus1 on it (adjust it with "ControlContainer=True"):
Code:
Option Explicit
Public Property Get BackColor() As Long
BackColor = ucNoFocus1.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
ucNoFocus1.BackColor = RHS
End Property
Public Property Get Caption() As String
Caption = ucNoFocus1.Caption
End Property
Public Property Let Caption(ByVal RHS As String)
ucNoFocus1.Caption = RHS
End Property
Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
Extender.TabStop = False
End Sub
Private Sub UserControl_Resize()
ucNoFocus1.Move 0, 0, ScaleWidth, ScaleHeight
End Sub
And that's it - no APIs, no SubClassing, no VTable-manipulations... just straight-forward VB6...
Ok, TextOutW would have to be used for rendering the Caption in a real implementation,
but the Main-Problem, how to get the VB6-HelpContextID-behaviour back on a "NonFocusable/NonTabStopable" Container seems solved.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
If that gets too complicated, there's a quite simple way out (since it's a *very* simple Control really).
Here's a working, pure VB6-approach for such a Frame:
- which consists of an "outer" Public ucFrame.ctl
- and an inner, Private ucNoFocus.ctl (which does the Drawing on itself).
Into the inner ucNoFocus (which gets adjusted with CanGetFocus = False):
Code:
Option Explicit
Private mCaption As String
Private Sub UserControl_Initialize()
AutoRedraw = True
ScaleMode = vbPixels
End Sub
Public Property Get BackColor() As Long
BackColor = UserControl.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
UserControl.BackColor = RHS
End Property
Public Property Get Caption() As String
Caption = mCaption
End Property
Public Property Let Caption(ByVal RHS As String)
mCaption = RHS: UserControl_Resize
End Property
Private Sub UserControl_Resize()
Dim yOffs, xOffs, TW
Const BorderColor = &H888888
Cls
xOffs = 8
yOffs = TextHeight(mCaption) / 2
If Len(mCaption) Then
TW = TextWidth(mCaption)
CurrentX = xOffs + 3: CurrentY = 0: Print mCaption
Line (0, yOffs)-(xOffs, yOffs), BorderColor
Line (0, yOffs)-(0, ScaleHeight), BorderColor
Line (0, ScaleHeight - 1)-(ScaleWidth, ScaleHeight - 1), BorderColor
Line (ScaleWidth - 1, yOffs)-(ScaleWidth - 1, ScaleHeight), BorderColor
Line (ScaleWidth - 1, yOffs)-(xOffs + 6 + TW, yOffs), BorderColor
Else
Line (0, 0)-(ScaleWidth - 1, ScaleHeight - 1), BorderColor, B
End If
End Sub
And this into the outer ucFrame-Control with the above ucNoFocus1 on it (adjust it with "ControlContainer=True"):
Code:
Option Explicit
Public Property Get BackColor() As Long
BackColor = ucNoFocus1.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
ucNoFocus1.BackColor = RHS
End Property
Public Property Get Caption() As String
Caption = ucNoFocus1.Caption
End Property
Public Property Let Caption(ByVal RHS As String)
ucNoFocus1.Caption = RHS
End Property
Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
Extender.TabStop = False
End Sub
Private Sub UserControl_Resize()
ucNoFocus1.Move 0, 0, ScaleWidth, ScaleHeight
End Sub
And that's it - no APIs, no SubClassing, no VTable-manipulations... just straight-forward VB6...
Ok, TextOutW would have to be used for rendering the Caption in a real implementation,
but the Main-Problem, how to get the VB6-HelpContextID-behaviour back on a "NonFocusable/NonTabStopable" Container seems solved.
Olaf
Great, I was looking for exactly something like this. Thanks
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
And that's it - no APIs, no SubClassing, no VTable-manipulations... just straight-forward VB6...
You know that this project has nothing todo with a simple, no subclassing, no VTable-manipulations etc... solution.
It is intended that the FrameW control hosts a BS_GROUPBOX window to draw the system frame border and all other overheads, like VisualStyles, RightToLeft etc. as well as replace all existing VB.Frame equivalent properties of course.
So I do have an interest of including the missing HelpContextID property, but it is not about simple.
Also on ToolBar control there is also a HelpContextID missing.
I need a way of including such functionality without the trick with an outer and inner UserControl. With that trick there is also the cosmetic downside that other methods and properties gets exposed which are not wanted, e.g. .SetFocus.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Interesting, thanks for reporting.
Indeed this seems like a minor issue. However, if you set the 'DisableNoScroll' to True this issue will not appear, like in the TextBoxW.
Only when 'DisableNoScroll' is False there is a issue on resize and auto re-appear as you described.
...
...
I don't know why this is necessary as when bRepaint is 1 on MoveWindow this is all supposed to be done...
MSDN: If the bRepaint parameter is TRUE, the system sends the WM_PAINT message to the window procedure immediately after moving the window (that is, the MoveWindow function calls the UpdateWindow function)
I set the 'DisableNoScroll' to True and I believe issue remains.
Regarding the Repaint, I am no expert in this. I wonder whether there is similarity with the VB6 Picturebox where the paint event won't fire when the picturebox is resized smaller but will fire when resized bigger. Because there may be resemblance experience.
Re: CommonControls (Replacement of the MS common controls)
Just stumbled across this thread
Is it possible to have a checkbox with a bold label WITHOUT removing its theme ?
By that I mean I want the checkbox to remain visually the same, have bold text and when it has the focus the focus rectangle goes around the box and the label (and not just the box which i would if you used a separate label object)
Re: CommonControls (Replacement of the MS common controls)
@Krool,
I started using your controls collection for displaying very long and unicode path/file names.
It's the first time I'm using a ListView control so please excuse if the following question sounds somehow trivial for you.
It seems that the ListView control isn't able to display a string (path) that exceeds the 260 chars boundary.
I created a ListView control with default options.
Simple code snippset:
Code:
Dim sPath as string
sPath="\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\test33\test34\test35\test36\test37\
test38\test39\test40\test41\123456789_123456789\1DEKOのじゃんくぼっくす。.mht"
With lvwData
.ColumnHeaders.Clear
.ListItems.Clear
.ColumnHeaders.Add , , "File Paths", , LvwColumnHeaderAlignmentLeft
.ListItems.Add , , sPath
If Len(sPath) > 259 then .ForeColor = vbRed
.ColumnHeaders(1).AutoSize (1)
End With
Result in the ListView:
"\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\ test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\te st33\test34\test35\test36\test37"
...whereas the label tooltip shows the full path
Although this behaviour offers a very simple possibility to display the potions of
a file path that can be accessed from the OS I wonder if this is "by design" or if it is a bug?
I fiddled around with possible options of the ListView property page - but no success.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Zphere
I started using your controls collection for displaying very long and unicode path/file names.
It's the first time I'm using a ListView control so please excuse if the following question sounds somehow trivial for you.
It seems that the ListView control isn't able to display a string (path) that exceeds the 260 chars boundary.
I created a ListView control with default options.
Simple code snippset:
Code:
Dim sPath as string
sPath="\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\test33\test34\test35\test36\test37\
test38\test39\test40\test41\123456789_123456789\1DEKOのじゃんくぼっくす。.mht"
With lvwData
.ColumnHeaders.Clear
.ListItems.Clear
.ColumnHeaders.Add , , "File Paths", , LvwColumnHeaderAlignmentLeft
.ListItems.Add , , sPath
If Len(sPath) > 259 then .ForeColor = vbRed
.ColumnHeaders(1).AutoSize (1)
End With
Result in the ListView:
"\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\ test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\te st33\test34\test35\test36\test37"
...whereas the label tooltip shows the full path
Although this behaviour offers a very simple possibility to display the potions of
a file path that can be accessed from the OS I wonder if this is "by design" or if it is a bug?
I fiddled around with possible options of the ListView property page - but no success.
It's not a bug.
MSDN: Note that although the list-view control allows any length string to be stored as item text, only the first 260 TCHARs are displayed.
Re: CommonControls (Replacement of the MS common controls)
I mainly am a VBA programmer so I don't use .ctl files very often but I have a question for you. The .ocx approach is good because compile times are much better and because we can use unicode at design time. However, the .ctl approach allows us to have just one file and not have to deal with a separate .ocx file for our users. So, is there any way to get the best of both worlds? Can we develop code with the .ocx and then switch to the .ctl files for the production code? I haven't read every post in the thread but I have read most and I haven't seen anyone bring this up. It this possible?
Re: CommonControls (Replacement of the MS common controls)
No you can not work with the compiled OCX in the IDE and somehow have the source code of the controls compiled in your final executable, unless you create 2 separate project files.
In project A you use the OCX and all your own source files.
In project B you use the CTLs and the same source files.
But why not use the OCX and use a manifest which will be embedded in your application? No need to install the OCX on a client computer.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
However, the .ctl approach allows us to have just one file and not have to deal with a separate .ocx file for our users. So, is there any way to get the best of both worlds? Can we develop code with the .ocx and then switch to the .ctl files for the production code? I haven't read every post in the thread but I have read most and I haven't seen anyone bring this up. It this possible?
This is exactly what I am doing.
You have to first do a bit of test work to see what is needed to change from the OCX to .ctl Std-Exe. To get myself familiar with what to change/switch, I created 2 simple and similar test projects with some codes for the control event handler to see the diffrences in the files. One project with the OCX and the other with the Std-Exe. Then open the .vbp and all the .frm with Notepad to see what are the differences and these differences are what need to be changed/switched.
When time come for switching, make a copy of the project as backup. Add in all the Std-Exe controls, modules, class modules and pages that you will need so that your projects will have everything needed. Then open .vbp and all the .frm with Notepad and do a Replace to replace the OCX with the Std-Exe ctls. Make very sure you have a backup before doing this so that if anything, you know where you need to redo amd more.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
You know that this project has nothing todo with a simple, no subclassing, no VTable-manipulations etc... solution.
I certainly didn't intend to "push a button" on your end - just to provide a simple example which solved the problem (how to make a NonFocusable Control with a HelpContextID) -
my comment was meant for those, who wanted to use the example "on its own" (as a starting-point for a simple Frame-Control).
Originally Posted by Krool
It is intended that the FrameW control hosts a BS_GROUPBOX window to draw the system frame border and all other overheads, like VisualStyles, RightToLeft etc. as well as replace all existing VB.Frame equivalent properties of course.
So I do have an interest of including the missing HelpContextID property, but it is not about simple.
Kind of disagreeing here... being the nerds we are, it is *always* about, how to accomplish things in a simpler way IMO.
In this regard though (now that we are at it) - some of your controls surely *could* be written with significantly less lines of code
(FrameW being one of those, which are "graphically" not really challenging, ButtonW, CheckBoxW, OptionBoxW ... etc are others).
If you think logically about it for a moment..., what is it that a FrameControl really does? - right, nothing (besides being a container).
And what does it consist of graphically? - right, 5 thin lines have to be drawn + a single TextString-Caption has to be rendered.
Can somebody here explain to me, why on earth such a simple Control would need interaction with an MS-Dll which provides a Control-Window,
then allows communication only per SendMessage - (and is hiding the most interesting bits - easy to use Rendering-Interfaces - from developers) -
instead of simply drawing things on your own - or using (if Win-conform-Theming is wanted), uxTheme.dll directly for that?
Originally Posted by Krool
Also on ToolBar control there is also a HelpContextID missing.
Then the code below for a transparent, unicode-aware (uxTheme.dll using) VB.Frame-compatible-Control might inspire you, to
maybe rewrite/shorten your codebase for at least some of your Controls which are similar (Button-like Controls and ToolBar included).
The savings compared to your current FrameW-Control are about 500 lines - so I guess with a consequently applied
uxTheme.dll based approach you could save about 5000 lines of code over your whole project - and make most of your Controls
look much more "VBish" (and understandable) on the inside.
Originally Posted by Krool
I need a way of including such functionality without the trick with an outer and inner UserControl.
With that trick there is also the cosmetic downside that other methods and properties gets exposed which are not wanted, e.g. .SetFocus.
Well, the inner UC was used to avoid having to use SubClassing in my previous example - the new Demo
below will use a single-Control + SubClassing (to suppress the MouseActivation of the FrameControl) instead.
That leaves the remaining "SetFocus" (along with the also available Focus-Events) - but having "something extra to just ignore"
would not bother me at all - compared to "something badly missing" - and perhaps some users will find creative uses for a
Focus- and Tabbing-enabled Frame or ToolBar (e.g. in case of a ToolBar I'd find the ability to "Tab through its Buttons" a convenient feature.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
If you think logically about it for a moment..., what is it that a FrameControl really does? - right, nothing (besides being a container).
And what does it consist of graphically? - right, 5 thin lines have to be drawn + a single TextString-Caption has to be rendered.
Can somebody here explain to me, why on earth such a simple Control would need interaction with an MS-Dll which provides a Control-Window,
then allows communication only per SendMessage - (and is hiding the most interesting bits - easy to use Rendering-Interfaces - from developers) -
instead of simply drawing things on your own - or using (if Win-conform-Theming is wanted), uxTheme.dll directly for that?
Yes I will consider it for future to-do to make the drawing directly, without resorting to MS-Dll Control-Window.
There will be actually no difference on the appearance like now (also in regard to transparency etc.) but indeed it will simplify that control at some point.
Originally Posted by Schmidt
Then the code below for a transparent, unicode-aware (uxTheme.dll using) VB.Frame-compatible-Control might inspire you, to
maybe rewrite/shorten your codebase for at least some of your Controls which are similar (Button-like Controls and ToolBar included).
The savings compared to your current FrameW-Control are about 500 lines - so I guess with a consequently applied
uxTheme.dll based approach you could save about 5000 lines of code over your whole project - and make most of your Controls
look much more "VBish" (and understandable) on the inside.
Thanks. On FrameW control I certainly agree to abandon the MS-Dll Control-Window. (like stated above)
However, for ToolBar control I do disagree and will stay with the MS-Dll Control-Window.
About the lines of code:
Please note that on each control there is a coding "overhead" of at least 110 lines because I do expose some "Extender" properties explicity.
Example:
Code:
FrameW1.ZOrder vbBringToFront
Will do always work. However the following will only work when doing that "overhead":
Code:
Dim This As FrameW
Set This = FrameW1
This.ZOrder vbBringToFront
That's why you can count 3,410 lines of codes only to this "overhead" cause, by exposing some Extender properties.
Originally Posted by Schmidt
Well, the inner UC was used to avoid having to use SubClassing in my previous example - the new Demo
below will use a single-Control + SubClassing (to suppress the MouseActivation of the FrameControl) instead.
Yes I would also going the SubClassing way. At least for the Std-EXE version it would be irritating to have another UC just for private use in the FrameW control.
Re: CommonControls (Replacement of the MS common controls)
Minor change in the OLEGuids.tlb file.
Just included ISpecifyPropertyPages, which allows to show the property pages at run-time for a control.
As there was no "break change" to existing interfaces, it was compiled with the same uuid. Means just overwrite to the existing file is OK.
However, that change is not crucial to this project.
It was included just for enrichement and due to preparations for the VBFlexGrid (MSFlexGrid replacement) Demo project.
Re: CommonControls (Replacement of the MS common controls)
I have developed a VBA solution to the opportunity of being able to develop VB6 programs using Krool's controls in an OCX form but then having the capability of doing a re-compile with a copy of your program using the raw code embedded into your file. This means a) there can be EXE that have no additional files (especially if you embed your manifest into the EXE file), b) you only have code for the controls you have actually used on your forms included in your code instead of code for all controls by using the OCX version and c) your file size is 3-3.5 MB smaller because you don't include the OCX file with code for all controls.
I did this using VBA but I have code that works in VB6 and all 32 and 64-bit versions of Microsoft Office. If someone wants to take my simple user interface (on the "Main" sheet) and make the equivalent VB6 form out of it please do and post it.
There is only 1 file, Controls.xlsb and it should work in all versions of Excel. Just make sure you turn on the option to run Macros.
There is an Instructions sheet and then you will likely go to the Main sheet (red tab) where you will use the (hopefully) simple interface to achieve what you need.
I am using several of my personal libraries that I have been using for a very long time. I have written (MS Word) documentation on most of the modules which I can send you if you are interested.
Re: CommonControls (Replacement of the MS common controls)
Thanks, that's what I thought. I have a VB6 version of the utility I posted a couple of days ago that allows a developer to switch from the OCX version to the Std-EXE version. I will post it in the next day or so. I hope you don't mind the add-on. I know this is your thread and if you would prefer I won't post it but it seems like the best place to keep it since it is specifically designed to work with what you've done.
Re: CommonControls (Replacement of the MS common controls)
Krool,
One more question. The utility I am writing re-compiles the project after switching all of the references in the project from the OCX to the Std-Exe controls. The compilation occurs using the commandline compiler and does not use the IDE. Do I need to include the line "Call ComCtlsInitIDEStopProtection" since we aren't using the IDE? I am writing some code to find the .BAS file in the project that contains Sub Main but it gets to be a bit of a hassle knowing where exactly to drop in this line in that subroutine. It would be nice to not have to include it if we don't need it.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
Krool,
One more question. The utility I am writing re-compiles the project after switching all of the references in the project from the OCX to the Std-Exe controls. The compilation occurs using the commandline compiler and does not use the IDE. Do I need to include the line "Call ComCtlsInitIDEStopProtection" since we aren't using the IDE? I am writing some code to find the .BAS file in the project that contains Sub Main but it gets to be a bit of a hassle knowing where exactly to drop in this line in that subroutine. It would be nice to not have to include it if we don't need it.
The Sub ComCtlsInitIDEStopProtection does only have an effect when running in IDE. In that Sub is a InIDE() test and does nothing when False.
So when you debug with OCX and compile with Std-EXE you certainly do not need to call that sub.
Means: ignore it completly.
And: Yes, please share that utility you are working right now.
The textbox scrolls to the end, not just one line!
I stepped through your code and there was no handling for EM_LINESCROLL.
It is some time since I updated so this may have been added. If it has, please let me know. If not, is there any chance of a patch to add to handle it?
Re: CommonControls (Replacement of the MS common controls)
xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1) works for me scrolling one line at a time with the latest version. I can also scroll any number of lines I want.
EM_LINESCROLL can be found in the TextBoxW.ScrollToLine method and is used there to handle scroll to a particular linenumber, not for your intended purpose.
Re: CommonControls (Replacement of the MS common controls)
Well I downloaded the latest version and still...
xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1)
scrolls to the end, not just one line!
There's no panic as I got round the problem by using Sendkey and the down arrow to scroll the number of lines I wanted. However, it would be nice to know if TextBoxW responds incorrectly to an EM_LINESCROLL message or whether I am doing something wrong!
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by JohnTurnbull
Well I downloaded the latest version and still...
xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1)
scrolls to the end, not just one line!
There's no panic as I got round the problem by using Sendkey and the down arrow to scroll the number of lines I wanted. However, it would be nice to know if TextBoxW responds incorrectly to an EM_LINESCROLL message or whether I am doing something wrong!
Maybe you Need to do it as:
xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, ByVal 1&)
Re: CommonControls (Replacement of the MS common controls)
Update - In post #1480, Sam_ asked if the package could be adjusted so that a project using none of Krools's controls but using the CommonDialog could be set to not use the OCX but the individual files. This update enables that plus cleans up some other stuff. That was addressed in version was 0.9.1 and the new one attached to this post is version 0.9.2. It addresses the situation where the reference to the CommonDialog function was done inside of a form. I had previously checked .cls and .bas files in the project but not .frm files. This is now fixed.
Introduction
In post #1463 I uploaded a version of a utility that takes a project using Krool's .OCX controls and adjusts everything so that the OCX is no longer required and the code for each control used in your project (and only those used in your project) was compiled within the program. The earlier post was done in VBA with Excel and kind of tossed together. This post discusses an update to that effort and it is available for VB6 and Excel. The VB6 version is "OCX2StdExe.vbp" and the Excel version is "OCX2StdExe.xlsb".
Basically you develop a project in VB6 using the OCX version of Krool's controls and then when you get to (or near) the final version you run this utility to make a new project that is just like the old one except that it no longer needs the OCX file because all of the controls code is in the file (like it does for his ComCtlsDemo that is on the first page of this thread. Your original project is unchanged.
The current version is 0.9.2. One zip file includes a detailed ReadMe.doc file with usage instructions and screenshots. The other contains the Excel version. I hope you find the utility easy to use and productive.
Last edited by MountainMan; Jul 9th, 2017 at 06:04 AM.
Reason: Updated program files.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Major internal improvement in the FrameW control. Thanks to Schmidt for bringing this up.
I have done the graphical drawing directly, without resorting to BS_GROUPBOX window.
It supports and behave like the intrinsic Frame control. It will draw themed when VisualStyles are in use, or classic when not.
Also 'Flat' appearance is supported. (Classic only)
The Border property got renamed to 'BorderStyle'. Thus making a replacement easier.
The code got now clearly more compact and more efficient.
Other side benefits are that the ForeColor property is now even working when VisualStyles are in use.
Nevertheless in Windows XP the ForeColor is still ignored when VisualStyles are in use, since the API to draw themed colored text is Vista+ only.
Also the Transparent property will work in design-time.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
I have developed a VBA solution to the opportunity of being able to develop VB6 programs using Krool's controls in an OCX form but then having the capability of doing a re-compile with a copy of your program using the raw code embedded into your file. This means a) there can be EXE that have no additional files (especially if you embed your manifest into the EXE file), b) you only have code for the controls you have actually used on your forms included in your code instead of code for all controls by using the OCX version and c) your file size is 3-3.5 MB smaller because you don't include the OCX file with code for all controls.
I did this using VBA but I have code that works in VB6 and all 32 and 64-bit versions of Microsoft Office. If someone wants to take my simple user interface (on the "Main" sheet) and make the equivalent VB6 form out of it please do and post it.
There is only 1 file, Controls.xlsb and it should work in all versions of Excel. Just make sure you turn on the option to run Macros.
There is an Instructions sheet and then you will likely go to the Main sheet (red tab) where you will use the (hopefully) simple interface to achieve what you need.
I am using several of my personal libraries that I have been using for a very long time. I have written (MS Word) documentation on most of the modules which I can send you if you are interested.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
In post #1463 I uploaded a version of a utility
[...]
The current version is 0.9.0. The zip file includes a detailed ReadMe.doc file with usage instructions and screenshots.
In one program I have the only part of Krools pack that is used is the Common Dialogue Control - this tells me that there are no controls in use (which is kind of true as nothing is on any forms) so does not insert any code. Is this intentional or can it be added?