dcsimg
Page 61 of 62 FirstFirst ... 11515859606162 LastLast
Results 2,401 to 2,440 of 2452

Thread: CommonControls (Replacement of the MS common controls)

  1. #2401

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Karl77 View Post
    That's now logical to me, because the list gets populated before the UC can read the property.
    And after I set the ExcludeList property there is not function to recreate the list.
    So no need to check on this.


    That seems to be the only correct way to me, and not a workaround.
    Because the EnumFontFunction runs twice as you explained, it makes no sense to do the exclusion in that place.

    Could you make a very short example on how to CB_DELETESTRING from the Combobox?
    I fear to destroy the order when certain items get deleted.

    Thank you for that.
    I can't code right now. It's just illustration and not tested. But it should give you the idea.

    Code:
    With FontCombo1
    Do
      bDelete = False
      For i = 0 To .ListCount - 1
        If .List(i) = strExcludeList Then
          SendMessage .hWnd, CB_DELETESTRING, i, ByVal 0&
          bDelete = True
          Exit For
        End If
      Next i
    Loop Until bDelete = False
    End With

  2. #2402
    Hyperactive Member
    Join Date
    Aug 2011
    Location
    Palm Coast, FL
    Posts
    296

    Re: Run-time-error ī429ī ActiveX component canīt create object

    Quote Originally Posted by AAraya View Post
    Did you ever discover the cause of this? I'm having what I believe is a similar issue. Upon launching my application, two users both report a msgbox window with title "VBCCR16" and a message of "Run-time error 0". When they click OK they get a Run-time-error 429. And my app never appears. This is my first app I've deployed with VBCCR16 so any support tips for dealing with these issues would be appreciated!
    As an update for any others who may encounter this problem. I replace hundreds of 32-bit icons with 24-bit icons in my app but it did not resolve the problem.

    Three of my users were having this issue. One had Vista and two had Win 7 which had not had all updates installed. When the Windows 7 computer was updated, the VBCCR16 "run-time error 0" issue no longer happens.

    Hope this saves someone a bunch of time chasing down other possibilities.

  3. #2403
    Junior Member
    Join Date
    Nov 2015
    Posts
    29

    Re: Run-time-error ī429ī ActiveX component canīt create object

    Quote Originally Posted by AAraya View Post
    When the Windows 7 computer was updated, the VBCCR16 "run-time error 0" issue no longer happens.

    What specifically was updated? What changed? Thanks

  4. #2404
    Hyperactive Member
    Join Date
    Aug 2011
    Location
    Palm Coast, FL
    Posts
    296

    Re: Run-time-error ī429ī ActiveX component canīt create object

    Quote Originally Posted by DaveInCaz View Post
    What specifically was updated? What changed? Thanks
    The Windows 7 OS was updated. No idea exactly which patch(es) resolved this issue. These are end-users, not computer engineers. They didn't go one-by-one, install update, test, install update, test. They just let Windows install all needed OS updates that hadn't been applied yet.
    Last edited by AAraya; Oct 1st, 2019 at 08:18 AM.

  5. #2405
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,554

    Re: CommonControls (Replacement of the MS common controls)

    This is for Krool. Others may want to experiment.

    Background: When a DPI-aware project is loaded into non-integral DPI (my own term), 175%, 200%, etc, where VB's twipsPerPixel (TPP) is not the same as the system's (1440 / realDPI) <> VB's TPP, then OCXs have problems. An ocx for simplicity: any control that is not a VB intrinsic control.

    Problem: The ocx does not draw into the full width/height of the ocx, it draws smaller than expected. This is directly related to the TPP discrepancy.

    Fix when resizing ocxs in this scenario: while sizing, also move the control +1 units Left & Top, then re-move the control -1 units left and top. Though this does address the problem, it still fails when an OCX has an Align property that is set to other than vbAlignNone (zero). You can try with common controls progressbar and set its Align property to non-zero. Again project must be DPI-aware and loaded into 175% DPI or similar non-integral DPI

    Ultimate fix is to send the control the dimensions of itself as pixels via an Interface method. That addresses the problem whether the ocx is aligned or not. This requires a bit of low-level API calls, if no TLB for that interface. We would call that interface method each time the form is resized because resizing the form changes the ocx dimensions when Align is non-zero.

    Here is some sample code that can be used from the parent/form of an ocx. It should be called from within the Form_Resize event for ocxs that have an Align property set to non-zero.
    Code:
    Private Declare Function DispCallFunc Lib "oleaut32.dll" (ByVal pvInstance As Long, ByVal offsetinVft As Long, ByVal CallConv As Long, ByVal retTYP As Integer, ByVal paCNT As Long, ByVal paTypes As Long, ByVal paValues As Long, ByRef retVAR As Variant) As Long
    Private Declare Function IIDFromString Lib "ole32.dll" (ByVal lpsz As Long, ByVal lpiid As Long) As Long
    
    Public Sub SyncOcxClientToParent(theControl As Control)
    
        ' This can be called in any DPI, but for for non-intrinsic controls, should always
        ' be called in non-integral DPI. In that case, external OCXs (not VB
        ' intrinsic controls) may not render to the full bounds of the control. This method
        ' attempts to fix that. It should only be called for non-intrinsic controls and
        ' after the control is sized. 
    
        Dim oIUnk As IUnknown, oObj As Object, frm As Form
        Dim vParamPtr(0 To 1) As Long, vParamType(0 To 1) As Integer
        Dim vRtn As Variant, vParams(0 To 1) As Variant
        Dim aData(0 To 3) As Long
        Dim hWnd As Long, sm As ScaleModeConstants
        Const IID_IOleInPlaceObject = "{00000113-0000-0000-c000-000000000046}"
        Const IOIP_SetRects As Long = 28&
    
        On Error Resume Next
        Set oObj = theControl.object
        If Err Then
            Err.Clear
        Else
            Set frm = theControl.Parent
            If Err Then                     ' applies to forms only
                Err.Clear: Set oObj = Nothing
            Else
                sm = theControl.Container.ScaleMode
                If Err Then
                    Err.Clear: sm = vbTwips
                End If
            End If
        End If
        On Error GoTo 0
        
        If oObj Is Nothing Then Exit Sub
        
        IIDFromString StrPtr(IID_IOleInPlaceObject), VarPtr(aData(0))
        ' set up call to DispCallFunc for querying for IID_IOleInPlaceObject
        vParams(0) = VarPtr(aData(0)): vParams(1) = VarPtr(oIUnk)
        vParamType(0) = vbLong: vParamType(1) = vbLong
        vParamPtr(0) = VarPtr(vParams(0)): vParamPtr(1) = VarPtr(vParams(1))
        ' does object implement IID_IOleInPlaceObject?
        DispCallFunc ObjPtr(oObj), 0&, 4&, vbLong, 2, VarPtr(vParamType(0)), VarPtr(vParamPtr(0)), vRtn
        If oIUnk Is Nothing Then
            With theControl
                .Move .Left + frm.ScaleX(1, vbPixels, sm), .Top + frm.ScaleX(1, vbPixels, sm)
                .Move .Left - frm.ScaleX(1, vbPixels, sm), .Top - frm.ScaleX(1, vbPixels, sm)
            End With
        Else
            aData(0) = frm.ScaleX(theControl.Left, sm, vbPixels)
            aData(1) = frm.ScaleX(theControl.Top, sm, vbPixels)
            aData(2) = aData(0) + frm.ScaleX(theControl.Width, sm, vbPixels)
            aData(3) = aData(1) + frm.ScaleX(theControl.Height, sm, vbPixels)
            vParams(1) = VarPtr(aData(0))
            DispCallFunc ObjPtr(oIUnk), IOIP_SetRects, 4&, vbLong, 2, VarPtr(vParamType(0)), VarPtr(vParamPtr(0)), vRtn
        End If
        Set oObj = Nothing: Set oIUnk = Nothing: Set frm = Nothing
    
    End Sub
    Now, the above should work in most cases, but can still fail when multiple aligned controls are stacked on each other. Multiple sizing events may occur that undoes the call to SyncOcxClientToParent. In that case, you need a delay. For example, use a disabled timer with a short interval and when Form_Resize kicks off, enable the timer. When the timer kicks off, disable it, and call SyncOcxClientToParent for the affected controls.

    For Krool: The above code is for an external call. I'd imagine you can fix your own CCR controls using the same logic. However, here's some things to consider:

    1. That sample code needs the UC's position/dimensions from the container's point of view and translated to pixels relative to the form's client area. Consider using the UC's Extender. You can't use GetWindowRect on the UC.hWnd because it will return the wrong dimensions. Actually, you could but would need to scale it by the difference in VB TPP vs real TPP. But not all UCs have hWnds (windowless).

    2. The interface method expects two rectangles. Both are identical, so use the same pointer: VarPtr(udtRect)

    3. If you are using TLBs, may want to include IOleInPlaceObject. Doing so should negate the DispCallFunc, IIDFromString calls along with the variables used for those calls.

    4. From trial and error. Calling the interface method should be done whenever the control resizes, after it resizes, i.e., trap WM_SIZE if possible. If no subclassing is in play, see if Usercontrol_Resize will be good enough & if not, maybe a timer delay method like described earlier.

    Questions? PM me.
    Last edited by LaVolpe; Oct 1st, 2019 at 06:16 PM. Reason: typos
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  6. #2406
    Hyperactive Member
    Join Date
    Apr 2015
    Posts
    454

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    I can't code right now. It's just illustration and not tested. But it should give you the idea.

    Code:
    With FontCombo1
    Do
      bDelete = False
      For i = 0 To .ListCount - 1
        If .List(i) = strExcludeList Then
          SendMessage .hWnd, CB_DELETESTRING, i, ByVal 0&
          bDelete = True
          Exit For
        End If
      Next i
    Loop Until bDelete = False
    End With
    Perfect, thank you.
    I implemented it in the UC directly.

  7. #2407

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Response to LaVolpe's post:

    As preparation I included now IOleInPlaceObject in the OLEGuids.tlb.
    In a second update then all the UC's will be updated. It needs time and to test everything out.

    ---

    PS: The ComCtlsDemo in the thread's first post is now only as .zip and not anymore with .docx extension. This was now possible as the VBForums file size limit has been increas for ZIP to 1,024,000.

  8. #2408

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Criticial bug for the OLEGuids.tlb.
    The recent modification - few hours ago - included interface IOleInPlaceObject.
    However, it was defined as:
    Code:
    interface IOleInPlaceObject : IUnknown
    But should have been
    Code:
    interface IOleInPlaceObject : IOleWindow
    This is now fixed. If anyone replaced OLEGuids.tlb just recently please do again.
    If not replaced again now it's not an issue "right now" but may become in future an issue.

    Sorry for the inconvinience caused.

  9. #2409

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    This is for Krool. Others may want to experiment.

    Background: When a DPI-aware project is loaded into non-integral DPI (my own term), 175%, 200%, etc, where VB's twipsPerPixel (TPP) is not the same as the system's (1440 / realDPI) <> VB's TPP, then OCXs have problems. An ocx for simplicity: any control that is not a VB intrinsic control.

    Problem: The ocx does not draw into the full width/height of the ocx, it draws smaller than expected. This is directly related to the TPP discrepancy.

    Fix when resizing ocxs in this scenario: while sizing, also move the control +1 units Left & Top, then re-move the control -1 units left and top. Though this does address the problem, it still fails when an OCX has an Align property that is set to other than vbAlignNone (zero). You can try with common controls progressbar and set its Align property to non-zero. Again project must be DPI-aware and loaded into 175% DPI or similar non-integral DPI

    Ultimate fix is to send the control the dimensions of itself as pixels via an Interface method. That addresses the problem whether the ocx is aligned or not. This requires a bit of low-level API calls, if no TLB for that interface. We would call that interface method each time the form is resized because resizing the form changes the ocx dimensions when Align is non-zero.

    Here is some sample code that can be used from the parent/form of an ocx. It should be called from within the Form_Resize event for ocxs that have an Align property set to non-zero.
    Code:
    Private Declare Function DispCallFunc Lib "oleaut32.dll" (ByVal pvInstance As Long, ByVal offsetinVft As Long, ByVal CallConv As Long, ByVal retTYP As Integer, ByVal paCNT As Long, ByVal paTypes As Long, ByVal paValues As Long, ByRef retVAR As Variant) As Long
    Private Declare Function IIDFromString Lib "ole32.dll" (ByVal lpsz As Long, ByVal lpiid As Long) As Long
    
    Public Sub SyncOcxClientToParent(theControl As Control)
    
        ' This can be called in any DPI, but for for non-intrinsic controls, should always
        ' be called in non-integral DPI. In that case, external OCXs (not VB
        ' intrinsic controls) may not render to the full bounds of the control. This method
        ' attempts to fix that. It should only be called for non-intrinsic controls and
        ' after the control is sized. 
    
        Dim oIUnk As IUnknown, oObj As Object, frm As Form
        Dim vParamPtr(0 To 1) As Long, vParamType(0 To 1) As Integer
        Dim vRtn As Variant, vParams(0 To 1) As Variant
        Dim aData(0 To 3) As Long
        Dim hWnd As Long, sm As ScaleModeConstants
        Const IID_IOleInPlaceObject = "{00000113-0000-0000-c000-000000000046}"
        Const IOIP_SetRects As Long = 28&
    
        On Error Resume Next
        Set oObj = theControl.object
        If Err Then
            Err.Clear
        Else
            Set frm = theControl.Parent
            If Err Then                     ' applies to forms only
                Err.Clear: Set oObj = Nothing
            Else
                sm = theControl.Container.ScaleMode
                If Err Then
                    Err.Clear: sm = vbTwips
                End If
            End If
        End If
        On Error GoTo 0
        
        If oObj Is Nothing Then Exit Sub
        
        IIDFromString StrPtr(IID_IOleInPlaceObject), VarPtr(aData(0))
        ' set up call to DispCallFunc for querying for IID_IOleInPlaceObject
        vParams(0) = VarPtr(aData(0)): vParams(1) = VarPtr(oIUnk)
        vParamType(0) = vbLong: vParamType(1) = vbLong
        vParamPtr(0) = VarPtr(vParams(0)): vParamPtr(1) = VarPtr(vParams(1))
        ' does object implement IID_IOleInPlaceObject?
        DispCallFunc ObjPtr(oObj), 0&, 4&, vbLong, 2, VarPtr(vParamType(0)), VarPtr(vParamPtr(0)), vRtn
        If oIUnk Is Nothing Then
            With theControl
                .Move .Left + frm.ScaleX(1, vbPixels, sm), .Top + frm.ScaleX(1, vbPixels, sm)
                .Move .Left - frm.ScaleX(1, vbPixels, sm), .Top - frm.ScaleX(1, vbPixels, sm)
            End With
        Else
            aData(0) = frm.ScaleX(theControl.Left, sm, vbPixels)
            aData(1) = frm.ScaleX(theControl.Top, sm, vbPixels)
            aData(2) = aData(0) + frm.ScaleX(theControl.Width, sm, vbPixels)
            aData(3) = aData(1) + frm.ScaleX(theControl.Height, sm, vbPixels)
            vParams(1) = VarPtr(aData(0))
            DispCallFunc ObjPtr(oIUnk), IOIP_SetRects, 4&, vbLong, 2, VarPtr(vParamType(0)), VarPtr(vParamPtr(0)), vRtn
        End If
        Set oObj = Nothing: Set oIUnk = Nothing: Set frm = Nothing
    
    End Sub
    Now, the above should work in most cases, but can still fail when multiple aligned controls are stacked on each other. Multiple sizing events may occur that undoes the call to SyncOcxClientToParent. In that case, you need a delay. For example, use a disabled timer with a short interval and when Form_Resize kicks off, enable the timer. When the timer kicks off, disable it, and call SyncOcxClientToParent for the affected controls.

    For Krool: The above code is for an external call. I'd imagine you can fix your own CCR controls using the same logic. However, here's some things to consider:

    1. That sample code needs the UC's position/dimensions from the container's point of view and translated to pixels relative to the form's client area. Consider using the UC's Extender. You can't use GetWindowRect on the UC.hWnd because it will return the wrong dimensions. Actually, you could but would need to scale it by the difference in VB TPP vs real TPP. But not all UCs have hWnds (windowless).

    2. The interface method expects two rectangles. Both are identical, so use the same pointer: VarPtr(udtRect)

    3. If you are using TLBs, may want to include IOleInPlaceObject. Doing so should negate the DispCallFunc, IIDFromString calls along with the variables used for those calls.

    4. From trial and error. Calling the interface method should be done whenever the control resizes, after it resizes, i.e., trap WM_SIZE if possible. If no subclassing is in play, see if Usercontrol_Resize will be good enough & if not, maybe a timer delay method like described earlier.
    This seems not to be an issue because when the control moves +1 units Left & Top, then re-move -1 units left and top adresses the issue properly when done within UserControl_Resize.
    However, I will consider using IOleInPlaceObject::SetObjectRects as this will move the control once instead of twice. (Small benefit)
    Also it looks better, rather a direct fix instead a strange looking workaround.
    LaVolpe confirmed it.

  10. #2410

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    1. That sample code needs the UC's position/dimensions from the container's point of view and translated to pixels relative to the form's client area. Consider using the UC's Extender. You can't use GetWindowRect on the UC.hWnd because it will return the wrong dimensions. Actually, you could but would need to scale it by the difference in VB TPP vs real TPP. But not all UCs have hWnds (windowless).
    To assume VB.Form as control's container is not secure. It could be nested within another UserControl.
    I liked the idea to use GetWindowRect and correct accordingly VB TPP vs real TPP. However, as you mention, it's not possible for windowless controls. (e.g. LabelW)

    So, I come up with this function below. It seems to work. Can you review/comment and/or confirm?
    removed

    In this context I noticed that in the DPICorrectionFactor common function was a flaw. It should be:
    Code:
    Public Function DPICorrectionFactor() As Single
    Static Done As Boolean, Value As Single
    If Done = False Then
        Value = ((96 / DPI_X()) * 15) / Screen.TwipsPerPixelX
        Done = True
    End If
    ' Returns exactly 1 when no corrections are required.
    DPICorrectionFactor = Value
    End Function
    instead of
    Code:
    Public Function DPICorrectionFactor() As Single
    Static Done As Boolean, Value As Single
    If Done = False Then
        Value = Screen.TwipsPerPixelX / ((96 / DPI_X()) * 15)
        Done = True
    End If
    ' Returns exactly 1 when no corrections are required.
    DPICorrectionFactor = Value
    End Function
    So currently the Factor must be divided. Which is odd, because a Factor means by definition always multiplication from a result.

    I wait a little bit before doing something ..
    Last edited by Krool; Oct 8th, 2019 at 02:47 PM.

  11. #2411
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,554

    Re: CommonControls (Replacement of the MS common controls)

    @Krool, we we're talking about the Align property. A control cannot have it set to other than vbAlignNone if the form is not its container. That is correct, isn't it?

    In that code, the form was located to use ScaleX,ScaleY. The scalemode of the control's parent was retrieved from theControl.Container.

    And non-integral TPP/DPI only needs to compare the system DPI to the form's TPP, if project is system aware or better. VB can only be loaded into system DPI or virtual 100% DPI.
    Last edited by LaVolpe; Oct 7th, 2019 at 06:22 PM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  12. #2412

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    @Krool, we we're talking about the Align property. A control cannot have it set to other than vbAlignNone if the form is not its container. That is correct, isn't it?

    In that code, the form was located to use ScaleX,ScaleY. The scalemode of the control's parent was retrieved from theControl.Container.

    And non-integral TPP/DPI only needs to compare the system DPI to the form's TPP, if project is system aware or better. VB can only be loaded into system DPI or virtual 100% DPI.
    The fix to sync the object rect is always necessary regardless of Align property. Right?
    If the new fix should only be used for <> vbAlignNone than I can keep the current implementation and change nothing? Sounds easier for me..
    My attempt was now to get rid of the double resizing and only fix resize once for all cases.

  13. #2413
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,554

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    The fix to sync the object rect is always necessary regardless of Align property. Right?
    Yes, if (1440 / Screen.TwipsPerPixelX) <> (1440 \ Screen.TwipsPerPixelX)

    However, and this may not apply to you, but maybe it does. With Win10, one could load forms into different DPI awareness contexts. This means on one form with your controls can be running in per-monitor awareness, while in another form they run in system awareness and in yet in another they run as unaware. In all three cases VB's TwipsPerPixel values do not change. Those values are set when VB initially loads and do not change for the life of the project. When forms are run in a different awareness than what the project loaded into, it has an affect on UCs/OCXs similar to running @ 175% DPI in some cases. I've just discovered that yesterday and am still trying to understand when/why it happens so it can be addressed. I'll follow up once I know more details.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  14. #2414

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    Yes, if (1440 / Screen.TwipsPerPixelX) <> (1440 \ Screen.TwipsPerPixelX)

    However, and this may not apply to you, but maybe it does. With Win10, one could load forms into different DPI awareness contexts. This means on one form with your controls can be running in per-monitor awareness, while in another form they run in system awareness and in yet in another they run as unaware. In all three cases VB's TwipsPerPixel values do not change. Those values are set when VB initially loads and do not change for the life of the project. When forms are run in a different awareness than what the project loaded into, it has an affect on UCs/OCXs similar to running @ 175% DPI in some cases. I've just discovered that yesterday and am still trying to understand when/why it happens so it can be addressed. I'll follow up once I know more details.
    I understand.
    In logic I first need to fix the object rect to an system DPI aware state and the VB TPP vs real TPP bug within UserControl_Resize.
    I would skip per monitor awareness in that case.

    Then later in another step there could be a DPIMonitorVsSystemScaleFactor(...) which when <> 1 on WM_DPICHANGE_BEFOREPARENT then scale another time object rect accordingly with the current diff factor to system aware state.

    Agree?

    EDIT: maybe this was too easy thought. What happens when the control resizes again due to .Align? I don't know how the behavior is exactly. Maybe such a DPIMonitorVsSystemScaleFactor needs to be done already also within UserControl_Resize...

    It's a messy topic. Something in me tells just stick to system dpi awareness and just don't do a per monitor manifest.
    Even MS states in their memo about it that it still is in early stages where sometimes mixed-mode dpi awareness is necessary.
    So best IMO is to get system dpi aware done properly and don't loose the nerves for per monitor awareness.
    I don't find it bad when the OS bitmap stretches system dpi vs monitor dpi the applications. This at least ensures ecerything is in correct physical sizes.
    Last edited by Krool; Oct 8th, 2019 at 12:54 PM.

  15. #2415
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,554

    Re: CommonControls (Replacement of the MS common controls)

    You can always ensure the user has access to graphical items so that they can change the scale if they want to, i.e., ensure fonts and images (that don't change automatically by the API window) are available to the user either via SendMessage and/or public UC properties. That might be a good workaround and allows users to make your control fully DPI aware.

    The biggest issue I have right now with per-monitor awareness is that not all API windows may support it. And when they do, is there any guarantee that what isn't scaled now won't be scaled in future versions (backward compatibility). It would also have been nice if Microsoft required WM_DPICHANGED_BEFOREPARENT to return non-zero if it DPI changes are going to be handled by the window.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  16. #2416

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    So I think I got my SyncObjectRectsToContainer now pretty straight forward without any cumbersum calculations.

    It now receives the border rect of the parent window where the object's window should be located. IOleInPlaceSite::GetWindowContext
    Together with IOleInPlaceObject::SetObjectRects it functions now as a perfect straight forward fix for the VB TPP vs real TPP bug.
    Or in other words: Apply the dimensions what the host reports to the client.

    Doesn't it look clean the new function? Works for all scenarios.
    Code:
    Public Sub SyncObjectRectsToContainer(ByVal This As Object)
    On Error GoTo CATCH_EXCEPTION
    Dim PropOleObject As OLEGuids.IOleObject
    Dim PropOleInPlaceObject As OLEGuids.IOleInPlaceObject
    Dim PropOleInPlaceSite As OLEGuids.IOleInPlaceSite
    Dim PosRect As OLEGuids.OLERECT
    Dim ClipRect As OLEGuids.OLERECT
    Dim FrameInfo As OLEGuids.OLEINPLACEFRAMEINFO
    Set PropOleObject = This
    Set PropOleInPlaceObject = This
    Set PropOleInPlaceSite = PropOleObject.GetClientSite
    PropOleInPlaceSite.GetWindowContext Nothing, Nothing, VarPtr(PosRect), VarPtr(ClipRect), VarPtr(FrameInfo)
    PropOleInPlaceObject.SetObjectRects VarPtr(PosRect), VarPtr(ClipRect)
    CATCH_EXCEPTION:
    End Sub
    LaVolpe: I wait your feedback until I release an update.
    The question remains. Should this new function be always called to ensrue integrity between host and client dimensions? Or only when DPICorrectionFactor() is <> 1 ? (DPICorrectionFactor is only system DPI; not per monitor)
    Last edited by Krool; Oct 9th, 2019 at 02:02 PM.

  17. #2417
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,554

    Re: CommonControls (Replacement of the MS common controls)

    Don't wait too long for feedback. You are using some interfaces and methods I have never played with. I'm interested in it as it does look like it should be a better option than using ScaleX,ScaleY and trying to get container scalemode, etc, that I was initially using.

    BTW, I did figure out in what scenarios mixing DPI awareness within a project would cause the OCX to not size correctly. It isn't just DPIs like 175%. The logic looks like this: If 1440 / GetDpiForSystem <> Screen.TwipsPerPixel. At 175%, 200% DPI, that calculation returns not equal. And when mixed awareness is in play, the calculation appears to work perfectly. When that calculation returns not equal, then sync is needed else is not. This is just FYI for you. I don't know if you plan on calling your new SyncObjectRectsToContainer during every resize or not. Prior to Win8.1, the old calculation will work just fine.

    Tip: GetDpiForSystem is for Win10,v1607 or better. Need to use GetProcessAwareness for Win8.1 to Win10 before v1607.

    Just saw your edited question. That's kinda tough. Right now, I know of two specific/different scenarios that cause DPICorrectionFactor<>1. Will there be more in future Win10 updates. If your new function does not trigger extra resize events, maybe always call it, else only call it when DPICorrectionFactor<>1.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  18. #2418

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    I don't know if you plan on calling your new SyncObjectRectsToContainer during every resize or not.
    That's the questions.. Should I just call SyncObjectRectsToContainer on every UserControl_Resize. My feeling says just call it when it's necessary.
    But what should be the condition when to call it? So that system DPI user or per Monitor DPI user will be happy and face no issues with the VBCCR.

  19. #2419
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,554

    Re: CommonControls (Replacement of the MS common controls)

    Krool, I tried your new routine and converted it to TLB-less calls and tested that too. All looks good.

    In my tests, I chose only to sync when DPICorrectionFactor<>1 and it worked well.

    FYI: I re-ran your CCR project in that other DPI awareness scenario discussed earlier: Started VB in per-monitor & then loaded your test form as DPI unaware. The current method of moving the control twice worked there too. So I think that answers your question -- maybe just sync when DPICorrectionFactor<>1
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  20. #2420

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    New function SyncObjectRectsToContainer now in place for all controls to support non-integral DPI.
    For the end-user is no visible impact. Before it "works" and now it works. However, the number of resizes is reduced a lot for non-integral DPI.

  21. #2421

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Affected are all controls which has a Transparent property and set to True and also the app runs on non-integral DPI. (dpi-aware)
    The background most likely is black. A .Refresh fixes this issue but it's unfair when on integral DPI it's not necessary. So the developer is most likely not aware to call .Refresh after load.
    Thus now whenever UserControl_Resize is called the transparent background will be updated.

  22. #2422
    Addicted Member
    Join Date
    Aug 2016
    Posts
    191

    Re: CommonControls (Replacement of the MS common controls)

    EN_SETEVENTMASK value (although CCR's RichTextBox doesn't use it) is 1073 (&H431) or 1093 (&H445)? I am confused.

    Edited: EN_SETEVENTMASK should be 1093. I am confused on some pages by google search.

    internal const int EM_SCROLLCARET = (NativeMethods.WM_USER + 49);
    internal const int EM_SETEVENTMASK = (NativeMethods.WM_USER + 69);
    Last edited by DaveDavis; Oct 14th, 2019 at 10:33 PM.

  23. #2423

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by DaveDavis View Post
    EN_SETEVENTMASK value (although CCR's RichTextBox doesn't use it) is 1073 (&H431) or 1093 (&H445)? I am confused.

    Edited: EN_SETEVENTMASK should be 1093. I am confused on some pages by google search.

    internal const int EM_SCROLLCARET = (NativeMethods.WM_USER + 49);
    internal const int EM_SETEVENTMASK = (NativeMethods.WM_USER + 69);
    ?
    EM_SETEVENTMASK is used already.

  24. #2424
    Addicted Member
    Join Date
    Aug 2016
    Posts
    191

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    ?
    EM_SETEVENTMASK is used already.
    Sorry, I missed. CCR used during creation.

    I taught EM_SETEVENTMASK can do fast updating. But I have no evidence.

    Code:
    private int updating = 0;
    private int oldEventMask = 0;
    public void BeginUpdate() //Faster Updating
            {
                ++updating;
                if (updating <= 1)
                {                
                    const int EM_SETEVENTMASK = 0x445;
                    const int WM_SETREDRAW = 0xB;    
                    //Prevent the control from raising any events. This message returns the previous event mask.                         
                    oldEventMask = SendMessage(new HandleRef(this, base.Handle), EM_SETEVENTMASK, 0, 0); 
                    // Prevent the control from redrawing itself.
                    SendMessage(new HandleRef(this, base.Handle), WM_SETREDRAW, 0, 0); 
                }
            }
    
            public void EndUpdate() 
            {
    
                --updating;
                if (updating <= 0)
                {                
                    const int EM_SETEVENTMASK = 0x445; 
                    const int WM_SETREDRAW = 0xB;                
                    // Allow the control to redraw itself.
                    SendMessage(new HandleRef(this, base.Handle), WM_SETREDRAW, 1, 0); 
                    // Allow the control to raise event messages.
                    SendMessage(new HandleRef(this, base.Handle), EM_SETEVENTMASK, 0, oldEventMask); 
                }
            }
    Last edited by DaveDavis; Oct 15th, 2019 at 01:38 AM.

  25. #2425
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    2,351

    Re: CommonControls (Replacement of the MS common controls)

    So the TabStrip randomly stopped working today. Didn't make any changes to any control-related files. The tabs stopped displaying, and when I try to open the (Custom) property page, I get run-time error 0x80010108 'The object invoked has disconnected from its clients.' at which point VB freezes and has to be killed from a process manager. No idea where this could be coming from.
    I'm using it as a UserControl; added all needed files. It's been stable for years. A frame control also stopped drawing but deleting it and creating a new one fixed that issue; deleting and creating a new TabStrip however did not.

  26. #2426

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by fafalone View Post
    So the TabStrip randomly stopped working today. Didn't make any changes to any control-related files. The tabs stopped displaying, and when I try to open the (Custom) property page, I get run-time error 0x80010108 'The object invoked has disconnected from its clients.' at which point VB freezes and has to be killed from a process manager. No idea where this could be coming from.
    I'm using it as a UserControl; added all needed files. It's been stable for years. A frame control also stopped drawing but deleting it and creating a new one fixed that issue; deleting and creating a new TabStrip however did not.
    At which spot the error raises?
    Can you encapsulate it in a demo?

  27. #2427
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    2,351

    Re: CommonControls (Replacement of the MS common controls)

    It happens when I click the button to bring up the property page of the (Custom) property at the top... couldn't initially tell the exact line because it was frozen, but...

    I tried to place one on another form in the same project, and it worked normally.

    Then I tried a 3rd form, and it didn't lock up when the run-time error popped up, and the problem is arising in PPTabStripGeneral:
    Code:
    Private Sub PropertyPage_SelectionChanged()
    Dim i As Long
    FreezeChanged = True
    With PropertyPage.SelectedControls(0)
    CheckEnabled.Value = IIf(.Enabled = True, vbChecked, vbUnchecked)
    CheckVisualStyles.Value = IIf(.VisualStyles = True, vbChecked, vbUnchecked)
    For i = 0 To ComboMousePointer.ListCount - 1
        If ComboMousePointer.ItemData(i) = .MousePointer Then
            ComboMousePointer.ListIndex = i
            Exit For
        End If
    Next i
    If ImageListEnumerated = False Then
        Dim ControlEnum As Object
        For Each ControlEnum In .ControlsEnum
    The error is raised on that last line. VB crashes entirely a few seconds later.

    Edit: I think it's some kind of system condition... like I mentioned the code hadn't changed, and the same problem seems to be happening in backup copies where definitely nothing has changed.
    Edit2: Tried to upgrade to the newest version and now nothing works at all. Can't open any old form that had one of the controls on it, placing new controls stops working random (crash), tried to open the ComCtlsDemo.vbp and whenever I go to open one of those forms, app crash (no runtime error, just full-on crash). Unregistered the old version of OLEGuids and registered the new one, so that's not the issue.

  28. #2428
    Addicted Member
    Join Date
    Jul 2017
    Posts
    190

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool ,

    In listview control , when I try to read the hint property of a listview group , the IDE crashes . I have downloaded and re-registered the OCX and replaced the OleGUID files to the latest ones but same problem still happens . I tested this in a fresh-downloaded comctlsdemo project and the result was the same .

    I tried to read it by index and key but these were not successful

    Code:
    Msgbox listview1.groups(1).hint   ' failed
    Msgbox listview1.groups("SomeKey").hint   ' failed
    All other properties I have tested for the groups collection are working properly .

  29. #2429

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Hosam AL Dein View Post
    In listview control , when I try to read the hint property of a listview group , the IDE crashes . I have downloaded and re-registered the OCX and replaced the OleGUID files to the latest ones but same problem still happens . I tested this in a fresh-downloaded comctlsdemo project and the result was the same .

    I tried to read it by index and key but these were not successful

    Code:
    Msgbox listview1.groups(1).hint   ' failed
    Msgbox listview1.groups("SomeKey").hint   ' failed
    All other properties I have tested for the groups collection are working properly .
    Thanks!
    It's fixed now.

  30. #2430
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    2,351

    Re: CommonControls (Replacement of the MS common controls)

    I've tried different versions and they're all just crashing... all my projects that use these controls are completely unusable now

    Best I can offer at this point is the call stack leading up to
    Exception thrown at 0x770630BD (ntdll.dll) in VB6.EXE: 0xC0000005: Access violation reading location 0x6CE044C7.
    Code:
    >	ntdll.dll!_RtlSizeHeap@12()	Unknown
     	AcXtrnal.dll!NS_FaultTolerantHeap::APIHook_RtlFreeHeap(void *,unsigned long,void *)	Unknown
     	kernel32.dll!_HeapFree@12()	Unknown
     	VB6.EXE!0049fc2b()	Unknown
     	[Frames below may be incorrect and/or missing, no symbols loaded for VB6.EXE]	
     	VBA6.DLL!0fc01e3a()	Unknown
     	VBA6.DLL!0fc01dfd()	Unknown
     	VBA6.DLL!0fa91baa()	Unknown
     	VBA6.DLL!0fb48b8f()	Unknown
     	VBA6.DLL!0fa91e09()	Unknown
     	VBA6.DLL!0fc01e3a()	Unknown
     	comctl32.dll!_CallNextSubclassProc@20()	Unknown
     	comctl32.dll!_MasterSubclassProc@16()	Unknown
     	user32.dll!_InternalCallWinProc@20()	Unknown
     	user32.dll!_UserCallWinProcCheckWow@32()	Unknown
     	user32.dll!_SendMessageWorker@24()	Unknown
     	user32.dll!_SendMessageW@16()	Unknown
     	comctl32.dll!_CCSendNotify@12()	Unknown
     	comctl32.dll!CReBar::_ResizeChildren(void)	Unknown
     	comctl32.dll!CReBar::_ResizeNow(void)	Unknown
     	comctl32.dll!CReBar::_Resize(int)	Unknown
     	comctl32.dll!CReBar::_SetBarInfo(struct tagREBARINFO *)	Unknown
     	comctl32.dll!CReBar::_WndProc(struct HWND__ *,unsigned int,unsigned int,long)	Unknown
     	comctl32.dll!CReBar::s_WndProc(struct HWND__ *,unsigned int,unsigned int,long)	Unknown
     	user32.dll!_InternalCallWinProc@20()	Unknown
     	user32.dll!_UserCallWinProcCheckWow@32()	Unknown
     	user32.dll!_SendMessageWorker@24()	Unknown
     	user32.dll!_SendMessageW@16()	Unknown
     	VBA6.DLL!0fc01d67()	Unknown
     	VBA6.DLL!0fc01e3a()	Unknown
     	VBA6.DLL!0fc01826()	Unknown
     	VBA6.DLL!0fc01826()	Unknown
     	VB6.EXE!0047b936()	Unknown
     	VB6.EXE!0047b90f()	Unknown
     	VB6.EXE!0047b700()	Unknown
     	VB6.EXE!00478921()	Unknown
     	VB6.EXE!00403882()	Unknown
     	VB6.EXE!00405bc3()	Unknown
     	user32.dll!_NtUserGetCPD@12()	Unknown
     	user32.dll!_InternalCallWinProc@20()	Unknown
     	user32.dll!_UserCallWinProcCheckWow@32()	Unknown
     	user32.dll!_DispatchMessageWorker@8()	Unknown
     	user32.dll!_DispatchMessageA@4()	Unknown
     	VB6.EXE!0047acce()	Unknown
     	VB6.EXE!0047ac2e()	Unknown
     	MSO97RT.DLL!3078d393()	Unknown
     	MSO97RT.DLL!3078d224()	Unknown
     	VB6.EXE!0047ad57()	Unknown
     	VB6.EXE!004653c3()	Unknown
     	VB6.EXE!00463f5a()	Unknown
     	kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     	ntdll.dll!___RtlUserThreadStart@8()	Unknown
     	ntdll.dll!__RtlUserThreadStart@8()	Unknown
    770630BD mov cx,word ptr [ecx+10h]
    Happens whenever I try to view the main form (but not the other forms) in the ComCtlsDemo.vbp project, or any of my projects with most of the controls.

    Copied everything to a fresh VM with Win8, the ComCtlsDemo project worked, I opened my other project, it crashed on form load, then ComCtlsDemo also started crashing on form load, this time with error pointing to AcLayers.dll instead of ntdll. Somehow something has happened whereby just viewing a form in my old project completely breaks this project for the entire system and all future projects going forward even if reinstalled, despite not changing a single byte in any project file.

    Edit: It might possibly just be something about that form... I recovered it by deleting all controls from this project manually in Notepad, but my project has other forms with the controls and no crashing occurs, but if I even try to create a new one on my main form, boom... needless to say, this is baffling.
    As an experiment, I copied all controls to a new form; created a new TabStrip and crashed outright. Created new form, created TabStrip, works normally, paste controls from other form, 'Object has disconnected from clients' runtime error on property page, then crash. (Only controls being copied are pure native VB controls at this point, not even regular common controls)

  31. #2431
    Addicted Member
    Join Date
    Jul 2017
    Posts
    190

    Re: CommonControls (Replacement of the MS common controls)

    Thanks for your response Krool ,

    In ListView , When I added 30 columns and some list items ( Enough to fill the height space of ListView ) , horizontal scrolling process is too slow and produces much flicker within the control . I have made some tests to get the factors affecting this issue and I trapped some and excluded some more .

    I came to a conclusion that this is affected by the number of ListView columns and the VISIBLE ListView items and consequently ListView height ( which can hide or show some populated list items ) .

    I was suspicious about if it was the control width or the columns widths are those who causing this lag too as they increase the columns visual space for the control , but found that they are not involved .

    I encapsulated a demo by which you can control :

    1. Number of columns
    2. Listview height ( Number of visible list items)
    3. Number of total list items
    4. ListView Width
    5. ListView Columns Widths


    Actually , the first two factors are those who affect this issue .

    Scenario :

    1. Add 30 columns with say 14 rows . Scroll Horizontally and notice the lag .
    2. Add 30 columns with say 200 rows . Scroll Horizontally and notice the lag >> Same lag as above with no increase
    3. Start decreasing the ListView height by 10 % to reduce the number of visible list items and notice the lag >> Scrolling is smoother
    4. Repeat the last step until there is one or two visible list items >> Almost no lag at all .
    5. With any of the steps above , ListView width and columns widths don`t affect scrolling smoothly nor laggy .


    I switched to windows explorer and watched the listview behavior with about 40 columns horizontal scrolling and this was not an issue and scrolled smoothly .

    Demo :
    ListView Hscroll Demo.zip
    Last edited by Hosam AL Dein; Oct 27th, 2019 at 12:17 AM.

  32. #2432
    Addicted Member
    Join Date
    Jul 2017
    Posts
    190

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by fafalone View Post
    I've tried different versions and they're all just crashing... all my projects that use these controls are completely unusable now
    Hi fafalone ,
    I faced issues like these for a long time and I fixed them through time by suspicion , experiment and luck nothing else . Because when it comes to sudden IDE crashes I have no clue of what is going on .

    I will not provide fixes but rather areas to watch and consider and I am sure you are totally aware of them but you may find them somehow useful .

    Considering the Aclayers.dll module crash , I faced this exact error and with the same scenario you provided , as I remember , this module does some graphical manipulations and this explains why comctlsdemo project crashes when you try to view the main form in IDE rather than running the project and showing it in runtime . In both cases it will not show and the IDE will crash .

    What fixed this issue for me ?

    1 - It was some conflict and bad data in the manifest of VB6 exe and the manifest resource file included in my project .

    I have also faced these IDE crash occurrences in earlier time before the manifest issue and these were some mistakes I have been doing :

    2 - At every OCX version update , I was not correctly replacing the old one . I did not un-register the previous version or the update file with the same version . So , It was registry issue .When I ran older projects with older versions registered and disk file locations for the OCX conflicted with those found in registry , the project re-registers the old OCX file maybe from the same location as the newer one or even from its original place if it was still kept in place . I mean it was registry issue related to updating the OCX with either new version or same version with a little tweak .

    3 - The last thought is that you maybe using something "Globally" in another project which conflicted with VBCCR . Instancing and scopes of Activex COM classes are the items that I would start searching if I was suspecting the last point because I am not close enough to them .

  33. #2433

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Hosam AL Dein View Post
    In ListView , When I added 30 columns and some list items ( Enough to fill the height space of ListView ) , horizontal scrolling process is too slow and produces much flicker within the control . I have made some tests to get the factors affecting this issue and I trapped some and excluded some more .

    I came to a conclusion that this is affected by the number of ListView columns and the VISIBLE ListView items and consequently ListView height ( which can hide or show some populated list items ) .

    I was suspicious about if it was the control width or the columns widths are those who causing this lag too as they increase the columns visual space for the control , but found that they are not involved .

    I encapsulated a demo by which you can control :

    1. Number of columns
    2. Listview height ( Number of visible list items)
    3. Number of total list items
    4. ListView Width
    5. ListView Columns Widths


    Actually , the first two factors are those who affect this issue .

    Scenario :

    1. Add 30 columns with say 14 rows . Scroll Horizontally and notice the lag .
    2. Add 30 columns with say 200 rows . Scroll Horizontally and notice the lag >> Same lag as above with no increase
    3. Start decreasing the ListView height by 10 % to reduce the number of visible list items and notice the lag >> Scrolling is smoother
    4. Repeat the last step until there is one or two visible list items >> Almost no lag at all .
    5. With any of the steps above , ListView width and columns widths don`t affect scrolling smoothly nor laggy .


    I switched to windows explorer and watched the listview behavior with about 40 columns horizontal scrolling and this was not an issue and scrolled smoothly .
    Thanks for your report.

    However, I think I can't do something about it.

    1. Windows Explorer don't use ListView. There use a direct internal control not exposed to comctl32.dll since Win 7.
    2. I have no control over comctl32.dll. I removed NM_CUSTOMDRAW as potential bottle neck and no improvement noticed. So that's not the cause.
    3. Microsoft Windows Common Controls 5.0 (COMCTL32.OCX) shows the same lag for their ListView. This OCX is also directly linked to comctl32.dll

  34. #2434
    Addicted Member
    Join Date
    Jul 2017
    Posts
    190

    Re: CommonControls (Replacement of the MS common controls)

    I have an idea which I don`t know if it is applicable or not . It is built on some information I have extracted from some testing . If the info is wrong then you may forget about the rest of the post .

    Info :

    After a scroll operation , the entire control is redrawn . So , while holding down the horizontal scrollbar and start scrolling , the control is redrawn at every change of the scrollbar ( which is DeltaX ) whose minimum value is the small change of the scrollbar .DeltaX value is not always number of many small changes it can be greater than small change as the public method Scroll does . And that`s a good point to build a solution on .

    What I have thought about depending on the previous info :

    I tried to implement a solution that hides the columns that are not in the visible area of the ListView . >> This failed because of first , there is no property to hide a column . second , I thought that the left property of the column changes while a scroll operation has finished ,which was not true . so , I could not control Visibility depending on the Column Left

    In the previous demo I provided , I updated it by adding the following

    Code:
    Private Sub ListView1_AfterScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
    ListView1.Redraw = False
    End Sub
    Code:
    Private Sub ListView1_BeforeScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
    ListView1.Redraw = False
    End Sub
    to stop redrawing the control and it scrolled very smoothly but surely the control appearance was exploited because it had to be redrawn after the scroll operation has ended . This was the point which made me sure the process uses entire control redrawing .

    I edited the code to the following :

    Code:
    Private Sub ListView1_AfterScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
    Timer1.Enabled = True
    End Sub
    Code:
    Private Sub ListView1_BeforeScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
    ListView1.Redraw = False
    End Sub
    Code:
    Private Sub Timer1_Timer()
    ListView1.Redraw = True
    Timer1.Enabled = False
    End Sub
    So ,the control will not be redrawn at every change of the scrollbar but rather in one second after the scroll has ended which is the code of Timer1 (Sets the redraw to true and then disables it self) . Of course , this is not an optimal solution but I was just testing the behavior . The result was better and lagging is now discrete and happens every one second .

    I tried to refine the solution by combining mouse_down event of listview to fire the redrawing at one second after the scroll has ended and while the mouse is not down . and this event was not firing with lisview scrollbars (intrinsic behavior as I think) . Also It will not be applicable if the scroll is done automatically by mouse scroll , here the mouse down refinement will not be present .

    So , now , my solution has two suggestions based on two points :

    1- Redrawing only the columns which appear in the visible width space of the listview ? like the way of Virtual List Items does . And this is changed in every horizontal scroll change .

    2- Keep entire control redrawing but firing it after a scrollbar journey ends not during the journey . I mean some event like Scroll_In_Progress . In this event we will not be redrawing the control but will only redraw after the scroll really ends . And the words Really ends here is not meant to be fired at end of a change event of a scroll bar but I think it can be implemented by measuring the silence time of a scroll bar after the first scroll . I mean , now I grabbed the the scrollbar , moving it right and left , this should not fire redrawing until it is not moved and remained still for a specific period of time say 100 ms . the we can say the Journey of scroll really ended and then we can fire the redrawing . This approach is a bit like the public method Scroll of the listview . The control is redrawn after a full DeltaX journey and that`s what I think it should be done .This method summarizes what I mean to say in this suggestion .

    3 - Combine both solutions . By replacing the last four words of suggestion 1 and applying the suggestion 2 .

    I have attached the previous demo with a timer firing the redrawing after one second of horizontal scrolling process completion and you can notice it is smooth for a second >> lags when redrawing >> smooth for a second >> lags when redrawing >> and so on .


    Attachment 171851

  35. #2435
    Hyperactive Member
    Join Date
    Apr 2015
    Posts
    454

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by fafalone View Post
    I've tried different versions and they're all just crashing... all my projects that use these controls are completely unusable now
    When I began using VBCCR I experienced 'unexplainable' crashes as well.
    But I didn't give up...

    In some scenarios the IDE failed to write the .frx files correctly.
    It took me some time to find out, because the .frm/.bas etc. were identical to the working version.

    Check the .frx files.
    Just an idea.

  36. #2436
    Lively Member
    Join Date
    Jul 2017
    Posts
    71

    Question ListView - cant change the KEY property

    VBCCR16 v.1.6.50
    VB6SP6

    i get the error message 457 - This key is already associated with an element of this collection when i try to change the KEY property of an listview item.

    thats what i do to get the error message:

    - add a new item with the KEY "test"
    - set the KEY property to "TEST"

    is this a bug or is the KEY property read only?

    update:

    i checked your function FChangeKey

    Code:
    Friend Sub FChangeKey(ByVal Ptr As Long, ByRef OldKey As String, ByVal NewKey As String)
    Dim Item As Variant, i As Long
    For Each Item In PropListItem
        i = i + 1
        If ObjPtr(Item) = Ptr Then
            If NewKey = vbNullString Then
                PropListItem.Add Item
                OldKey = vbNullString
            Else
                PropListItem.Add Item, NewKey
                OldKey = NewKey
            End If
            PropListItem.Remove i
            Exit For
        End If
    Next Item
    End Sub
    i guess the item with the "old" key has to be removed first before you add a new item with the same key but a different upper/lower-case...or?
    Last edited by Mith; Nov 1st, 2019 at 12:32 AM. Reason: added more information

  37. #2437

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: ListView - cant change the KEY property

    Quote Originally Posted by Mith View Post
    VBCCR16 v.1.6.50
    VB6SP6

    i get the error message 457 - This key is already associated with an element of this collection when i try to change the KEY property of an listview item.

    thats what i do to get the error message:

    - add a new item with the KEY "test"
    - set the KEY property to "TEST"

    is this a bug or is the KEY property read only?

    update:

    i checked your function FChangeKey

    Code:
    Friend Sub FChangeKey(ByVal Ptr As Long, ByRef OldKey As String, ByVal NewKey As String)
    Dim Item As Variant, i As Long
    For Each Item In PropListItem
        i = i + 1
        If ObjPtr(Item) = Ptr Then
            If NewKey = vbNullString Then
                PropListItem.Add Item
                OldKey = vbNullString
            Else
                PropListItem.Add Item, NewKey
                OldKey = NewKey
            End If
            PropListItem.Remove i
            Exit For
        End If
    Next Item
    End Sub
    i guess the item with the "old" key has to be removed first before you add a new item with the same key but a different upper/lower-case...or?
    The collection has always been text compare and not binary compare.
    So don't change from lower to upper case a key.
    Keep for example always in lower case and change key when it's really changed text compare wise only.

  38. #2438
    Lively Member
    Join Date
    Jul 2016
    Posts
    100

    Re: CommonControls (Replacement of the MS common controls)

    Hey

    Thanks to MountainMan's documentation, I'm finally starting to use VBCCR, great stuff!

    I haven't found documentation nor examples of how the ListView column filter is to be used - how do I get the listview to show only matches once something is typed into the filter? I'm not supposed to manually clear and re-populate the listview, am I?

    If I need to be able to edit cells in other columns than the first, should I use vbflxgrd or something else from vbccr?

  39. #2439

    Thread Starter
    Frenzied Member
    Join Date
    Jun 2012
    Posts
    1,322

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by OldClock View Post
    Hey

    Thanks to MountainMan's documentation, I'm finally starting to use VBCCR, great stuff!

    I haven't found documentation nor examples of how the ListView column filter is to be used - how do I get the listview to show only matches once something is typed into the filter? I'm not supposed to manually clear and re-populate the listview, am I?

    If I need to be able to edit cells in other columns than the first, should I use vbflxgrd or something else from vbccr?
    Filtering ListView needs you to re-populate.
    The best performance is to use VirtualMode in ListView, thus making filtering fast.

    For cell editing vbflexgrid is the feature richest variant in my controls. So yes, use then vbflexgrid instead of ListView for complex data represantion (view) and cell edits.
    vbflexgrid cell edit allows textbox edit, combobox style edit or custom dialog box edit and many events for data validation etc.

  40. #2440
    Addicted Member
    Join Date
    Jul 2017
    Posts
    190

    Re: CommonControls (Replacement of the MS common controls)

    In CmoboBoxW , How Can I draw items manually ? and What is the difference between Fixed and Variable drawing Enums in DrawMode property .

    I am asking this question because I - in most cases - use the combo style "List" , which draws a gray background for the combo box , once I changed the DrawMode property , the backcolor I set is what is shown .
    My last concern is , If I draw items manually , would this affect some features or other properties ?

    Thanks in advance .

    Edit 1 :
    Another question . what is the property ExtendedUI is intended to do . The only effect I noticed is that : If it is set to true , scrolling the combobox opens the list otherwise , scrolling does not open the list and changes the list index and text of the combobox while the list is not opened or dropped down .

    Edit 2 :
    I have tested the ItemDraw Event and noticed that it is not fired when the DrawMode property is set to Normal . Thus I thought it would be something to start with . But , I did not get the point of some parameters like ItemAction and ItemState . Or This is not right start point ?
    Last edited by Hosam AL Dein; Nov 27th, 2019 at 11:10 PM.

Page 61 of 62 FirstFirst ... 11515859606162 LastLast

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