CommonControls (Replacement of the MS common controls) - Page 37-VBForums
Page 37 of 37 FirstFirst ... 2734353637
Results 1,441 to 1,476 of 1476

Thread: CommonControls (Replacement of the MS common controls)

  1. #1441
    New Member
    Join Date
    Nov 2015
    Posts
    7

    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.

    Thanks Krool

  2. #1442
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    Re: CommonControls (Replacement of the MS common controls)

    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.
    Attached Files Attached Files

  3. #1443
    New Member
    Join Date
    Nov 2015
    Posts
    7

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chosk View Post
    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?

  4. #1444

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    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.

    Quote Originally Posted by Schmidt View Post
    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.
    Last edited by Krool; Jun 1st, 2017 at 04:31 PM.

  5. #1445
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    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.

    No problem with the horizontal scrollbar.

  6. #1446
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    Re: CommonControls (Replacement of the MS common controls)

    The same issue with the Std-Exe. Resize the Form taller will trigger the vertical scrollbar to appear.

    I attach a video.
    Attached Files Attached Files

  7. #1447

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Schmidt View Post
    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?

    Quote Originally Posted by chosk View Post
    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)
    Last edited by Krool; Jun 6th, 2017 at 04:35 PM.

  8. #1448
    PowerPoster
    Join Date
    Jun 2013
    Posts
    2,988

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    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.

    Olaf

  9. #1449
    New Member
    Join Date
    May 2017
    Location
    Germany
    Posts
    15

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Schmidt View Post
    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

  10. #1450

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Schmidt View Post
    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.

  11. #1451
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    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.
    Last edited by chosk; Jun 7th, 2017 at 11:42 PM.

  12. #1452
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    Re: CommonControls (Replacement of the MS common controls)

    I search and found this article:
    https://www.vb-helper.com/tip_refres...nvalidate.html

    So I added RichTextBox1.Refresh after RichTextBox1 is resized and it seems to solve the issue.

  13. #1453
    New Member
    Join Date
    Nov 2015
    Posts
    2

    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)

    Thanks

  14. #1454
    Junior Member
    Join Date
    Dec 2009
    Location
    Germany
    Posts
    19

    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.

    Thanks in advance for any response.

  15. #1455

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Zphere View Post
    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.

  16. #1456
    Junior Member
    Join Date
    Dec 2009
    Location
    Germany
    Posts
    19

    Re: CommonControls (Replacement of the MS common controls)

    Thanks much for clarification.
    That's exactly what I wanted to know.

  17. #1457
    Junior Member
    Join Date
    Feb 2015
    Posts
    24

    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?

  18. #1458
    PowerPoster
    Join Date
    Oct 2013
    Posts
    2,652

    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.

  19. #1459
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by MountainMan View Post
    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.

    Hope this help.
    Last edited by chosk; Jun 9th, 2017 at 03:34 AM.

  20. #1460
    PowerPoster
    Join Date
    Jun 2013
    Posts
    2,988

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    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).

    Quote Originally Posted by Krool View Post
    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?

    Quote Originally Posted by Krool View Post
    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.

    Quote Originally Posted by Krool View Post
    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.

    Ok, here a ScreenShot:


    And here the Demo-Code for "ucFrameT": http://vbRichClient.com/Downloads/ucFrameT.zip

    Olaf

  21. #1461

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Schmidt View Post
    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.

    Quote Originally Posted by Schmidt View Post
    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.

    Quote Originally Posted by Schmidt View Post
    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.

  22. #1462

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    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.
    Last edited by Krool; Jun 10th, 2017 at 04:50 PM.

  23. #1463
    Junior Member
    Join Date
    Feb 2015
    Posts
    24

    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.
    Attached Files Attached Files

  24. #1464
    Junior Member
    Join Date
    Feb 2015
    Posts
    24

    Re: CommonControls (Replacement of the MS common controls)

    Krool,

    In ComCtrlsDemo there are two lines in the Main procedure in Startup.bas for which I have a question.

    Code:
    Call ComCtlsInitIDEStopProtection
    Call InitVisualStyles
    Are these two lines required when using the OCX version of your controls or does your code do these steps automatically?

  25. #1465

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by MountainMan View Post
    Krool,

    In ComCtrlsDemo there are two lines in the Main procedure in Startup.bas for which I have a question.

    Code:
    Call ComCtlsInitIDEStopProtection
    Call InitVisualStyles
    Are these two lines required when using the OCX version of your controls or does your code do these steps automatically?
    Call ComCtlsInitIDEStopProtection is not needed for OCX.
    The other is needed depended if your app is manifested or not to use theming.

  26. #1466
    Junior Member
    Join Date
    Feb 2015
    Posts
    24

    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.

  27. #1467
    Junior Member
    Join Date
    Feb 2015
    Posts
    24

    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.

  28. #1468

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by MountainMan View Post
    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.

  29. #1469
    Addicted Member
    Join Date
    Jul 2006
    Posts
    138

    Handling EM_LINESCROLL

    Hi Krool,

    I have your TextboxW as Text1. When I call...

    xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1)

    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?

  30. #1470
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    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.
    Last edited by chosk; Jun 18th, 2017 at 01:39 PM.

  31. #1471
    Addicted Member
    Join Date
    Jul 2006
    Posts
    138

    Re: CommonControls (Replacement of the MS common controls)

    Thank you for your quick reply.
    I will download the latest version.
    .SrollToLine doesn't seve my purpose

  32. #1472

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chosk View Post
    EM_LINESCROLL can be found in the TextBoxW.ScrollToLine method and is used there to handle scroll to a particular linenumber
    Improved the ScrollToLine method. The selection and caret position is not changed anymore by this method.

  33. #1473
    Addicted Member
    Join Date
    Jul 2006
    Posts
    138

    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!

  34. #1474
    Lively Member
    Join Date
    Feb 2014
    Posts
    119

    Re: CommonControls (Replacement of the MS common controls)

    It is working with me. I did a screen capture.
    Attached Files Attached Files

  35. #1475

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    667

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by JohnTurnbull View Post
    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&)

    Depends on how you declared the SendMessage API.

  36. #1476
    Addicted Member
    Join Date
    Jul 2006
    Posts
    138

    Re: CommonControls (Replacement of the MS common controls)

    Ah!

    The older I get, the dumber I get!

    Thank you both.

Page 37 of 37 FirstFirst ... 2734353637

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.