CommonControls (Replacement of the MS common controls) - Page 36-VBForums
Page 36 of 47 FirstFirst ... 263334353637383946 ... LastLast
Results 1,401 to 1,440 of 1872

Thread: CommonControls (Replacement of the MS common controls)

  1. #1401
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    634

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    I just want to put out a question in the room.
    Shall my new VBFlexGrid (almost completed) be included in this project or separated as initially intended to be?
    Reason for my struggle is that it would fit perfectly in the architecture of this project, but did it separate because of the size and complexity.
    However, who cares if the VBCCR15.OCX will be 4.4 MB or 5.6 MB?
    Thanks
    My first thought is that it's better to have everything in a single file.

    Let's try to find the pros and cons:

    Pros:
    1) Everything in a single file/reference, is simpler.
    2) Easier to find for people that don't know that it is available out there.
    3) The file size is not a problem nowadays (at least in most of cases, perhaps 99%).

    Cons:
    1) To have everything together increase the number of types available. I mean, for example, one reason I don't like to use ADO is because I'm used to declare String variables as Dim a as str[and press Space or Enter] and it becomes Dim a as String, but having a reference to ADO it becomes Dim a as Stream, and I need to navigate down for several types to find String.
    The point is that having unused Types is not good for intellisense.

    Others?

  2. #1402
    Hyperactive Member
    Join Date
    Apr 2015
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    I would prefer a single file solution as well.
    When fixes like the last DPI issue are solved, then the grid inherits the changes automatically.
    Separate solutions are more work to maintain.
    ---
    The OCX is not small anyway.
    I personally don't care about the file size, but it is important nowadays as well.
    We can always use and strip the EXE version to optimize the overall file size.
    ---
    A new Grid control is definitely a very good thing.
    I use the MSFLEXGRID for too many years now.
    It lacks some very basic functionality, but it is 'easy' to implement it (edit, sorting etc.).
    But the appearance is fixed: Scrollbars, fixed columns...
    Eager to play with the new control!

    Karl

  3. #1403
    Hyperactive Member
    Join Date
    Sep 2012
    Posts
    459

    Re: CommonControls (Replacement of the MS common controls)

    Edit: The size of the VBCCR is not a problem. However, the VBFlexGrid is a new control, when it is a separated OCX, it will be more convenient to debug, correct errors and add new features. At the same time, it won't affect the original VBCCR controls. Of course, if the VBFlexGrid is integrated into a single file, there are other benefits.

    Whether it is a separated OCX or integrated into a single file, it isn't a big problem. The most exciting thing is that Krool's new VBFlexGrid is almost completed.
    Last edited by dreammanor; May 8th, 2017 at 06:11 AM.

  4. #1404
    PowerPoster
    Join Date
    Oct 2013
    Posts
    2,917

    Re: CommonControls (Replacement of the MS common controls)

    I'm quite curious to see what the VBFlexGrid has to offer.
    For years I'm using the vsFlexGrid from ComponentOne and I really really like it.

  5. #1405
    Junior Member
    Join Date
    Oct 2016
    Posts
    17

    Re: CommonControls (Replacement of the MS common controls)

    You are great, all this AND a Grid, A1.

    I vote for a single file, for the reasons you have suggested

    thank you so much

  6. #1406
    New Member
    Join Date
    Nov 2015
    Posts
    9

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool, from my point of view having a single OCX to manage in development and deployment is preferable. And I agree, an extra 1 MB plus or minus is not important.

    Since it seems that managing the code is also easier from your side of things, and you do all this work graciously than that is also something to be optimized for!

    Dave

  7. #1407
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,605

    Thumbs up Re: CommonControls (Replacement of the MS common controls)

    I would expect the VBGrid to ultimately be a seperate OCX.

    1 Question - how API compatible with the flexgrid will it be?

    Also - just like to point out you've single handedly:
    - Replaced all VB's Common Controls with updated Unicode Compatible replacements
    - Made Multithreading easy in VB
    - Will have replaced the flexgrid (arguably the most used control beyond the common controls)

    All open source... Quite epic as far as classic VB goes.

    Cheers!
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  8. #1408

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by DEXWERX View Post
    I would expect the VBGrid to ultimately be a seperate OCX.

    1 Question - how API compatible with the flexgrid will it be?
    I tend to the separate solution again. (again )
    Since updates are isolated. Own thread for community etc.

    What you mean API compatible?
    Like an old fashioned dll control?
    The control itself is an own registered window. But the interface is all tru the UserControl container properties and method. There will be no separate message based 'interaction'.

  9. #1409
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,605

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    I tend to the separate solution again. (again )
    Since updates are isolated. Own thread for community etc.

    What you mean API compatible?
    Like an old fashioned dll control?
    The control itself is an own registered window. But the interface is all tru the UserControl container properties and method. There will be no separate message based 'interaction'.
    I just meant, are your VBGrid's properties and methods going to be the same as an MSHFlexGrid?

    Regards,
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  10. #1410

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by DEXWERX View Post
    I just meant, are your VBGrid's properties and methods going to be the same as an MSHFlexGrid?

    Regards,
    Yes, of course. It will be an replacement where not much code needs to be changed. Of course limitation and bugfixes will be removed and new features added.

  11. #1411
    Hyperactive Member
    Join Date
    Apr 2015
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    Krool,

    before your gift comes out, could you please look again at #1382?
    Thank you.

    Karl

  12. #1412
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,211

    Re: CommonControls (Replacement of the MS common controls)

    I think I've found an incompatibility to the old intrinsic Controls (whilst updating an older Project at work, which had
    quite some amount of Forms - by just replacing "Begin VB.TextBox " with "Begin VBCCR14.TextBoxW " same for CommandButtons -
    ... all done in a Replace-loop over all *.frm Files, just to lift-up the old TextBoxes and CommandButtons to Unicode-awareness)

    That worked well enough - the Project loaded just fine after that.

    The only problem (currently) seems to be, that Validate-Events are not raised, when a Mouse-triggered Focus-Change happens
    from any Control - to another CCR14-Control... (on the "any Control" that is)...
    Mouse-triggered FocusChanges to older Intrinsic-Controls work fine though and *do* trigger the Validate-Event in a CCR14-Control,
    which is about to loose the Focus.


    TabKey-based Focus-Changes work fine (as in: "they always trigger the Validate-Events on CCR14-Controls")
    Also Form.ValidateControls seems to work the same way as with the Intrinsics (triggering a response in the currently focused CCR14-Control).
    It's (as said) only the problem with MouseBased-FocusChanges.

    Here's an example (please place the appropriate CCR14-Controls like listed in the snippet below on an otherwise empty Form)
    Code:
    Option Explicit
    
    Private Sub TextBoxW1_Validate(Cancel As Boolean)
      Debug.Print "TextBoxW1_Validate"
    End Sub
    
    Private Sub TextBoxW2_Validate(Cancel As Boolean)
      Cancel = True
      Debug.Print "TextBoxW2_Validate (Cancel set to True)"
    End Sub
    
    Private Sub ComboBoxW1_Validate(Cancel As Boolean)
      Debug.Print "ComboBoxW1_Validate"
    End Sub
     
    Private Sub CommandButtonW1_Click()
      Unload Me 'we should not reach this, when the Focus was sitting within TextBoxW2
    End Sub
    
    Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
       On Error GoTo 1
         Me.ValidateControls 'this seems to work correcly (same as with intrinsics)
    1  If Err.Number = 380 Then Cancel = 1
    End Sub
    Olaf
    Last edited by Schmidt; May 11th, 2017 at 06:21 AM.

  13. #1413

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Schmidt View Post
    I think I've found an incompatibility to the old intrinsic Controls (whilst updating an older Project at work, which had
    quite some amount of Forms - by just replacing "Begin VB.TextBox " with "Begin VBCCR14.TextBoxW " same for CommandButtons -
    ... all done in a Replace-loop over all *.frm Files, just to lift-up the old TextBoxes and CommandButtons to Unicode-awareness)

    That worked well enough - the Project loaded just fine after that.

    The only problem (currently) seems to be, that Validate-Events are not raised, when a Mouse-triggered Focus-Change happens
    from any Control - to another CCR14-Control... (on the "any Control" that is)...
    Mouse-triggered FocusChanges to older Intrinsic-Controls work fine though and *do* trigger the Validate-Event in a CCR14-Control,
    which is about to loose the Focus.


    TabKey-based Focus-Changes work fine (as in: "they always trigger the Validate-Events on CCR14-Controls")
    Also Form.ValidateControls seems to work the same way as with the Intrinsics (triggering a response in the currently focused CCR14-Control).
    It's (as said) only the problem with MouseBased-FocusChanges.

    Here's an example (please place the appropriate CCR14-Controls like listed in the snippet below on an otherwise empty Form)
    Code:
    Option Explicit
    
    Private Sub TextBoxW1_Validate(Cancel As Boolean)
      Debug.Print "TextBoxW1_Validate"
    End Sub
    
    Private Sub TextBoxW2_Validate(Cancel As Boolean)
      Cancel = True
      Debug.Print "TextBoxW2_Validate (Cancel set to True)"
    End Sub
    
    Private Sub ComboBoxW1_Validate(Cancel As Boolean)
      Debug.Print "ComboBoxW1_Validate"
    End Sub
     
    Private Sub CommandButtonW1_Click()
      Unload Me 'we should not reach this, when the Focus was sitting within TextBoxW2
    End Sub
    
    Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
       On Error GoTo 1
         Me.ValidateControls 'this seems to work correcly (same as with intrinsics)
    1  If Err.Number = 380 Then Cancel = 1
    End Sub
    Olaf
    Thank you.

    I could replicate this problem, but only in the OCX version.
    The Std-EXE version works fine.

    The problem lies in the WM_MOUSEACTIVATE handlers in the controls.
    It seems the OCX has a problem with:
    Code:
    Screen.ActiveForm.ValidateControls
    I suppose replacing it with
    Code:
    UserControl.Parent.ValidateControls
    could probably fix this issue. (But that fix would not work when mouseactivating from a form control to a nested control in another UserControl)

    I will investigate soon further.

  14. #1414
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,605

    Re: CommonControls (Replacement of the MS common controls)

    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  15. #1415
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    634

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    It seems the OCX has a problem with:
    Code:
    Screen.ActiveForm.ValidateControls
    Yes, because Screen.ActiveForm returns a reference to the active form (when there is any) of the current project, the OCX, not of the client project.

  16. #1416
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,211

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    I could replicate this problem, but only in the OCX version...
    Yep, that's what we're using here...

    Before you might undertake a recompilation, there's another thing with
    TextBoxes that we made use of in our old Forms - it's the DataChanged-Property,
    which (in case of the TextBoxW-replacements) never seems to be set (when content
    is changed that is different from the "initial Form-Designer-Value").

    We also have detected a Bug in the TreeView, which on Node-Deletes (which contain Children)
    does not seem to delete the Children, not updating the "Count" properly - and then later
    (whilst collapsing/re-expanding Nodes) will run into an error.

    In case you cannot reproduce that Tree-behaviour easily, I'd be happy to provide an example...
    (a collegue of mine discovered that, and we don't have a "reduced test-case" prepared yet).

    Regards,

    Olaf

  17. #1417
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,605

    Re: CommonControls (Replacement of the MS common controls)

    a github would be convenient for bug tracking, version control and for others to supply patches. *nudge*
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  18. #1418
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,211

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by DEXWERX View Post
    a github would be convenient for bug tracking, version control and for others to supply patches. *nudge*
    Yep.

    @Krool
    Just coming in from my colleague again... (sorry for just throwing that stuff out "as it happens", but maybe it's easy to fix along with the other things)

    - the "DataChanged-Prop-not-set"-thingy seems not only restricted to TextBoxW, but also to CheckBoxW and OptionButtonW
    - the FrameW does not contain a "HelpContextID"-Property (as the VB-original)

    The latter one would probably break compatibility with the OCX-TypeLib (or the Manifest) -
    but it'd be nice to have in the long run.

    As said, this all came up in our "simple replace-test" we undertook (just replacing the ProgIDs in the VB *.frm Files)
    on a larger (older) VB6-App - it's surprising how well that worked out, aside from these small "glitches" I've reported
    (which came up when running some of the "upgraded" Forms in question).

    Regards,

    Olaf

  19. #1419

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Eduardo- View Post
    Yes, because Screen.ActiveForm returns a reference to the active form (when there is any) of the current project, the OCX, not of the client project.
    Yes. Thus I need to abandon the Screen.ActiveForm.
    I have found a way to solve a nested UserControl in another UserControl, however this solution goes only one deep. So nesting 2x times would not work. But for now this would be a good hotfix and solves nearly all scenarios. Again, only if somebody is nesting like crazy it won't work. :-)

    Code:
    If TypeOf UserControl.Parent is VB.Form Then
        UserControl.Parent.ValidateControls
    Else
        UserControl.ParentControls(0).Parent.ValidateControls
    End If
    So I think I will implement that solution soon for the moment until something better comes up.
    Last edited by Krool; May 12th, 2017 at 12:45 PM.

  20. #1420
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,605

    Re: CommonControls (Replacement of the MS common controls)

    courtesy of Vlad (wqweto)

    takes advantage of the fact that UserControls all derive from the UserControl interface, even though they don't respond to a
    QI for _UserControl. It seems that VB nicely skips the QI when it thinks it's assigning between the same interfaces.
    I would have come up with this eventually.

    Of course the assumption is that if the parent is not a Form, its a UserControl...
    This may not work if it's not hosted on a Form!

    Code:
    Private Property Get ParentForm() As Form
        Dim oTopParent      As Object
        Dim oUserControl    As UserControl
        
        Set oTopParent = Extender.Parent
        Set oUserControl = AsUserControl(oTopParent)
        Do While Not oUserControl Is Nothing
            If oUserControl.Parent Is Nothing Then
                Exit Do
            End If
            Set oTopParent = oUserControl.Parent
            Set oUserControl = AsUserControl(oTopParent)
        Loop
        Set ParentForm = oTopParent
    End Property
    
    Private Function AsUserControl(oObj As Object) As UserControl
        Dim pControl        As UserControl
      
        If TypeOf oObj Is Form Then
            '--- do nothing
        Else
            Call CopyMemory(pControl, ObjPtr(oObj), 4)
            Set AsUserControl = pControl
            Call CopyMemory(pControl, 0&, 4)
        End If
    End Function


    This doesn't seem to fix if a ComboboxW gets the focus?
    although my patch was a bit hurried.
    Last edited by DEXWERX; May 12th, 2017 at 05:35 PM.
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  21. #1421

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Update released. Thanks DexWerx for the code to get the parent form of the UserControl, regardless of how deep it is nested.

    I have found the bug with the CausesValidation not working on mouse activation quite urgent. (though it concerns effectively only the OCX, however)
    The OCX version is therefore also updated.

    In the Common.bas module the following new function is included:
    Code:
    Public Function GetUserControlParentForm(ByVal Parent As Object) As VB.Form
    If Parent Is Nothing Then Exit Function
    If TypeOf Parent Is VB.Form Then
        Set GetUserControlParentForm = Parent
    Else
        On Error Resume Next
        Dim UserControl As VB.UserControl, TempObj As VB.UserControl
        CopyMemory TempObj, ObjPtr(Parent), 4
        Set UserControl = TempObj
        CopyMemory TempObj, 0&, 4
        Do While Not UserControl Is Nothing
            If TypeOf UserControl.Parent Is VB.Form Then
                Set GetUserControlParentForm = UserControl.Parent
                Exit Do
            Else
                CopyMemory TempObj, ObjPtr(UserControl.Parent), 4
                Set UserControl = TempObj
                CopyMemory TempObj, 0&, 4
            End If
        Loop
        On Error GoTo 0
    End If
    End Function
    Of course the GetUserControlParentForm function will return Nothing in case the UserControl is sited on:
    - Internet Explorer
    - Excel, Word etc. (VBA)
    - VB.PropertyPage

    But when GetUserControlParentForm is used with an error handler then they should be no harm actually.
    In this case then .ValidateControls will not be invoked.

    However, it would be good to make this work also with VB.PropertyPage as .ValidateControls is supported on it.
    But I was not able to get it done...

    If somebody finds a way please let me know.
    I will then extend the function and might rename it from 'GetUserControlParentForm' As VB.Form to 'GetUserControlTopParent' As Object.

    In the meantime it then stays like this.

    Quote Originally Posted by DEXWERX View Post
    This doesn't seem to fix if a ComboboxW gets the focus?
    It does fix the ComboBoxW as well.

    PS:
    I do not forget the other open issues, which are:
    - TextBoxW CCBorderStyleSingle border draw problem on certain conditions.
    - "DataChanged-Prop-not-set" on TextBoxW, CheckBoxW and OptionButtonW
    - FrameW does not contain a "HelpContextID"-Property
    - Bug in the TreeView, which on Node-Deletes (which contain Children) does not seem to delete the Children, not updating the "Count" properly

  22. #1422

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    EDIT:

    I found a solution to get the VB.PropertyPage. But that cannot be wrapped in a single function as a 'GetUserControlTopParent' As Object does not work. It must be set explicitly to VB.PropertyPage.

    So the function 'GetUserControlParentForm' will stay as currently is, instead the code in the UserControl itself will be enhanced.

    So the solution would be as following: (will be implemented soon)
    Code:
    On Error Resume Next
    With UserControl
    If .Extender.CausesValidation = True Then
        InProc = True
        GetUserControlParentForm(.Parent).ValidateControls
        If Err.Number = 91 Then
            Err.Clear
            Dim PropertyPage As VB.PropertyPage, TempObj As VB.PropertyPage
            CopyMemory TempObj, ObjPtr(.Parent), 4
            Set PropertyPage = TempObj
            CopyMemory TempObj, 0&, 4
            PropertyPage.ValidateControls
        End If
        InProc = False
        If Err.Number = 380 Then
            WindowProcControl = MA_NOACTIVATEANDEAT
        ' ...
    EDIT2:
    if a UserControl is nested in another UserControl and sited on a VB.PropertyPage. In that case it don't work.
    Thus beside 'GetUserControlParentForm' an additional function 'GetUserControlParentPropertyPage' is needed that walks up the UserControl chain first.
    Luckily there is no chain on VB.PropertyPage.
    Final solution will come soon.
    Last edited by Krool; May 13th, 2017 at 07:23 AM.

  23. #1423

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    I have renamed 'GetUserControlParentForm' to 'GetUserControlTopParent'.

    This is now the final solution to retrieve the top parent VB.Form of a UserControl:

    Code:
    Public Function GetUserControlTopParent(ByVal ParentControls As VBRUN.ParentControls) As VB.Form
    If ParentControls.Count = 0 Then Exit Function
    If TypeOf ParentControls(0) Is VB.Form Then
        Set GetUserControlTopParent = ParentControls(0)
    Else
        Dim OldParentControlsType As VBRUN.ParentControlsType
        OldParentControlsType = ParentControls.ParentControlsType
        ParentControls.ParentControlsType = vbExtender
        If TypeOf ParentControls(0) Is VB.VBControlExtender Then
            ParentControls.ParentControlsType = vbNoExtender
            Dim UserControl As VB.UserControl, TempUserControl As VB.UserControl
            CopyMemory TempUserControl, ObjPtr(ParentControls(0)), 4
            Set UserControl = TempUserControl
            CopyMemory TempUserControl, 0&, 4
            Dim TempParentControlsType As VBRUN.ParentControlsType
            Do
                With UserControl
                If .ParentControls.Count = 0 Then Exit Do
                If TypeOf .ParentControls(0) Is VB.Form Then
                    Set GetUserControlTopParent = .ParentControls(0)
                    Exit Do
                Else
                    TempParentControlsType = .ParentControls.ParentControlsType
                    .ParentControls.ParentControlsType = vbExtender
                    If TypeOf .ParentControls(0) Is VB.VBControlExtender Then
                        .ParentControls.ParentControlsType = vbNoExtender
                        CopyMemory TempUserControl, ObjPtr(.ParentControls(0)), 4
                        Set UserControl = TempUserControl
                        CopyMemory TempUserControl, 0&, 4
                        .ParentControls.ParentControlsType = TempParentControlsType
                    Else
                        .ParentControls.ParentControlsType = TempParentControlsType
                        Exit Do
                    End If
                End If
                End With
            Loop
        End If
        ParentControls.ParentControlsType = OldParentControlsType
    End If
    End Function
    It is now safe in every scenario.

    Because, before if the parent was not a VB.Form it was "assumed" to be a UserControl.
    And this resulted in a crash when the Control is sited on a non-VB6 environment, e.g. VBA, IE etc. (tested)

    Now trough the ParentControls it is possible to test if the Parent supports VB.VBControlExtender.
    Because every UserControl implements this, thus instead of "assuming", we now know for sure it is a UserControl. (Thus CopyMemory is safe)
    This check is repeated in the iteration for safety, because if the top parent is a VB.PropertyPage, it would cast the PropertyPage as UserControl...
    So if it goes up the UserControl chain and detects the top parent is not a VB.Form and there is no further UserControl it will exit and return Nothing. (e.g. in case the top parent would be a VB.PropertyPage)

    However, unfortunately there is no way to check if the top parent is a VB.PropertyPage or not. (if not a VB.Form of course)
    So, they will be no support for VB.PropertyPage. (of course only for .ValidateControls)

    An workaround would be to replace TextBoxW again to TextBox in every PropertyPage in the OCX version. (like it is in the Std-EXE version)
    Of course if somebody would use the OCX in their PropertyPage the problem for mouse activation and validation would be there again...
    Last edited by Krool; May 14th, 2017 at 06:52 PM.

  24. #1424
    Hyperactive Member
    Join Date
    May 2011
    Posts
    370

    Re: CommonControls (Replacement of the MS common controls)

    @Krool: There is no need to manually call `ValidateControl` when UC's in-place activation is implemented correctly IMHO. The internet floating IPAO implementation (based on `OLE Guid and interface definition` typelib) has this bug you are experiencing that I've been researching in the past. On my controls (hosting API created hwnds) I'm currently using something like this for API ctl WM_SETFOCUS handler (see pvSetFocus)
    Code:
    Private Type RECT
        Left                As Long
        Top                 As Long
        Right               As Long
        Bottom              As Long
    End Type
    
    Private Type IPAOHookStruct 'IOleInPlaceActiveObjectHook
        lpVTable            As Long                     'VTable pointer
        IPAOReal            As IOleInPlaceActiveObject  'Un-AddRefed pointer for forwarding calls
        TBEx                As ITranslateAccelerator    'Un-AddRefed native class pointer for making Friend calls
        ThisPointer         As Long
    End Type
    
    Private m_IPAOHookStruct        As IPAOHookStruct
    Private m_bMouseActivate        As Boolean
    
    Private Sub pvSetFocus()
        Dim pOleObject          As IOleObject
        Dim pOleInPlaceSite     As IOleInPlaceSite
        Dim pOleInPlaceFrame    As IOleInPlaceFrame
        Dim pOleInPlaceUIWindow As IOleInPlaceUIWindow
        Dim PosRect             As RECT
        Dim ClipRect            As RECT
        Dim FrameInfo           As OLEINPLACEFRAMEINFO
           
        On Error Resume Next
        Set pOleObject = Me
        Set pOleInPlaceSite = pOleObject.GetClientSite
        If Not pOleInPlaceSite Is Nothing Then
            pOleInPlaceSite.GetWindowContext pOleInPlaceFrame, pOleInPlaceUIWindow, VarPtr(PosRect), VarPtr(ClipRect), VarPtr(FrameInfo)
            'Get in-place frame and make sure it is set to our in-between
            'implementation of IOleInPlaceActiveObject in order to catch
            'TranslateAccelerator calls
            If m_IPAOHookStruct.ThisPointer <> 0 Then
                If Not pOleInPlaceFrame Is Nothing Then
                    pOleInPlaceFrame.SetActiveObject m_IPAOHookStruct.ThisPointer, vbNullString
                End If
                If m_bMouseActivate Then
                    pOleObject.DoVerb OLEIVERB_UIACTIVATE, 0, pOleInPlaceSite, 0, UserControl.hWnd, VarPtr(PosRect)
                End If
            End If
        End If
    End Sub
    The difference w/ your current impl (besides `ThisPointer` holding naked pointer As Long and correspondingly tweaked typelib) as far as I can see is that on `m_bMouseActivate` flag I'm calling `DoVerb OLEIVERB_UIACTIVATE` at which point control validation takes place (must be). I'm certainly not calling `ValidateControls` on top container manually and just confirmed that `Validate` is raised on source control both on keyb and mouse activation of such IPAO impl in UC.

    cheers,
    </wqw>

  25. #1425
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,605

    Re: CommonControls (Replacement of the MS common controls)

    @wqweto awesome. Thanks for clearing that up.
    It's great to have people with so much experience with user controls helping out.
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  26. #1426

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Thanks wqweto.

    Unfortunately does 'DoVerb OLEIVERB_UIACTIVATE' not solve the problem. It is actually only a SetFocus command to the UserControl.
    That 'DoVerb OLEIVERB_UIACTIVATE' does actually the same as in my WM_SETFOCUS handler:
    Code:
        Case WM_SETFOCUS
            If wParam <> UserControl.hWnd Then SetFocusAPI UserControl.hWnd: Exit Function
    If I do remove the WM_MOUSEACTIVATE handler, then the validation is working the "native good way".
    However, in order to have full functionaly I need to handle WM_MOUSEACTIVATE. (reason why see example below)

    Just do the following test in the CheckBoxW control:
    Remove the WM_MOUSEACTIVATE handler. Now when you click on it the check is not set, only when you click again.
    Only when I remove the 'DoVerb OLEIVERB_UIACTIVATE' (or SetFocusAPI UserControl.hWnd) in the WM_SETFOCUS handler the check is set on the first click.
    But then you have the issue of wrong TabIndex, ActiveControl not new one etc.

    So my conclusion is now that I keep the infrastructure as it is.
    Maybe at some point I manage to get the VB.PropertyPage to work. (manual .ValidateControls in WM_MOUSEACTIVATE)
    Last edited by Krool; May 16th, 2017 at 02:19 PM.

  27. #1427

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Update released. (quite important when using the TreeView control)

    Now the child node objects of a TreeView are removed when removing a parent node object.
    Thus the 'Nodes.Count' property returns the correct number after a parent node removal.

    Furthermore there was a minor error in the ListView control related to the filter edit. (UseColumnFilterBar = True)
    When the user clicks in a filter the whole text will be selected.
    If the user now clicks again at a specific character the caret will be positioned to that character. (this was not working before)

    And some other minor internal improvements.

    Quote Originally Posted by Schmidt View Post
    We also have detected a Bug in the TreeView, which on Node-Deletes (which contain Children)
    does not seem to delete the Children, not updating the "Count" properly - and then later
    (whilst collapsing/re-expanding Nodes) will run into an error.
    The "Count" problem is now solved. It should also fix the "then later" problem. However, please check.

    Quote Originally Posted by Schmidt View Post
    FrameW does not contain a "HelpContextID"-Property (as the VB-original)
    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.
    That's why I do not have a solution for this problem..

    Quote Originally Posted by Karl77 View Post
    Textbox, small problem

    This is an optical problem, no complaints about the functionality.
    When the CCBorderStyleSingle is set, the control loses the upper horizontal line of the border.
    It is ok when the textbox doesn't have the focus.

    To retrace:
    Start a fresh VB.
    Add the Krool controls.
    Set the font of the Form1 to Segoe UI, 11.
    Place a textbox on the form.
    Copy and paste this textbox, create a control array.
    Set the borderstyle CCBorderStyleSingle to the copied textbox.
    Run.
    Click into the textbox that has CCBorderStyleSingle.
    Now you should see this:
    Attachment 147067
    I now could replicate the problem. (according to chosk's example)
    However, the normal VB.TextBox control does also have the same "glitch" in that scenario.
    So I am afraid that this is a MS bug. (?)

    Quote Originally Posted by Schmidt View Post
    there's another thing with TextBoxes that we made use of in our old Forms - it's the DataChanged-Property,
    which (in case of the TextBoxW-replacements) never seems to be set (when content
    is changed that is different from the "initial Form-Designer-Value").
    I did a quick test with the VB.Data control and an access DB.
    When the record is loaded into the TextBoxW control the DataChanged property returns False. If I now change the text it returns True.
    So in my understanding it does work. (?)
    Edit: You can also try to use the TextBoxW.Modified property. (of course you need to set it to False manually after you load the data - as initial value)
    Last edited by Krool; May 16th, 2017 at 04:05 PM.

  28. #1428
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,211

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    The "Count" problem is now solved. It should also fix the "then later" problem. However, please check.
    I've checked, but it doesn't seem to work "fully" yet (tested with a larger Tree in one of our Forms -
    will try to post a reduced example for that...).
    Currently it looks, as if only the "first-level-children" will be removed - but not in a fully recursive manner -
    as said, will try to post more details on that later...

    Quote Originally Posted by Krool View Post
    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.
    That's why I do not have a solution for this problem..
    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.

    Quote Originally Posted by Krool View Post
    I did a quick test with the VB.Data control and an access DB.
    When the record is loaded into the TextBoxW control the DataChanged property returns False. If I now change the text it returns True.
    So in my understanding it does work. (?)
    Edit: You can also try to use the TextBoxW.Modified property. (of course you need to set it to False manually after you load the data - as initial value)
    The DataChanged-Prop seems related to DataBinding, but this is only *one* case where it applies -
    because it works (and is used by us) also without any DataBindings in some Forms...

    The behaviour is (quite similar to your .Modified-Prop), that the "initial FormDesigner-Value" of a Control
    will not cause the DataChange-Prop to go to True (when the Form is loading) - so far so good...

    However, *any* change of a Controls-Content that follows (be it "programmatically" or "by User-Input"),
    will set (in the VB.TextBox) the DataChanged-Prop to True - though one can "reset" it to False again after e.g.
    a "programmatical change" which was a "desired one" (e.g. when filled from a DB on Form-Load).

    The following Example shows the differences we stumbled over (all without any DataBinding)
    The Form needs:
    - a Timer1
    - a Text1 and a Label1 from VBs intrinsics
    - a TextBoxW1 and a LabelW1 from the CCR14-OCX
    Code:
    Private Sub Form_Load()
      Timer1.Interval = 100
      Text1.Text = "Initial-Value":     Debug.Print "Text1: "; Text1.DataChanged
      TextBoxW1.Text = "Initial-Value": Debug.Print "TextBoxW1: "; TextBoxW1.DataChanged
      
      'after setting the .Text-Prop programmatically, we reset the Flag (to be able to see new changes)
      Text1.DataChanged = False
      TextBoxW1.DataChanged = False
    End Sub
    
    Private Sub Timer1_Timer()
      Label1.Caption = Text1.DataChanged
      LabelW1.Caption = TextBoxW1.DataChanged
    End Sub
    From your description it sounds as if your TextBoxW.Modified Property shows the desired behaviour
    (working the same way as the .DataChanged-Prop in the old TextBox) - but since we currently "just replace the ProgID"
    in a loop over all our *.frm Files, it would be nice when the two (.Modified and .DataChanged) would be "synchronized".

    Thanks for working on fixing these things with such a short response-time BTW...

    Olaf

  29. #1429
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,211

    Re: CommonControls (Replacement of the MS common controls)

    Ok, here the promised example for the Tree-Node-Remove-Problem (I'm already using the recent CCR14 version) -
    accompanied by another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:

    The Form needs 3 freshly dropped Controls, all in their "virginal, unchanged state":
    VB.Label1, VBCCR14.LabelW1, and a VBCCR14.TreeView1
    Code:
    Private Sub Form_Load()
      With TreeView1
      
        .Nodes.Add , , "Node_0", "Node_0"
        
           .Nodes.Add "Node_0", TvwNodeRelationshipChild, "Node_0_0", "Node_0_0"
              .Nodes.Add "Node_0_0", TvwNodeRelationshipChild, "Node_0_0_0", "Node_0_0_0"
              .Nodes.Add "Node_0_0", TvwNodeRelationshipChild, "Node_0_0_1", "Node_0_0_1"
          
           .Nodes.Add "Node_0", TvwNodeRelationshipChild, "Node_0_1", "Node_0_1"
              .Nodes.Add "Node_0_1", TvwNodeRelationshipChild, "Node_0_1_0", "Node_0_1_0"
              .Nodes.Add "Node_0_1", TvwNodeRelationshipChild, "Node_0_1_1", "Node_0_1_1"
        
     
        Debug.Print "NodeCount should be 7:"; .Nodes.Count
        .Nodes.Remove "Node_0" '<- now we remove the Root-node
        Debug.Print "NodeCount should be 0:"; .Nodes.Count
        
      End With
      
      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
    HTH

    Olaf

  30. #1430

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Quote Originally Posted by Schmidt View Post
    I've checked, but it doesn't seem to work "fully" yet (tested with a larger Tree in one of our Forms -
    will try to post a reduced example for that...).
    Currently it looks, as if only the "first-level-children" will be removed - but not in a fully recursive manner
    Oh yes, of course a recursion needs to be done to get all children on each level.
    This should be now fixed, please check again.

    Quote Originally Posted by Schmidt View Post
    another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:
    This kind of issue we had "already" and was solved.
    However, when doing this in Form_Load it seems to not work. (else when Form is displayed this does already work)

    Your other points are noted and will be checked soon.

    Thanks Olaf for your reports anyhow, such a project 1:1 replacement conversion is always a good "trial of fire" test.

  31. #1431

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    I have detected a major important bug that needs to be fixed!

    Right ahead: I do have a solution in mind for this, later more.

    1. Start a fresh Std-EXE project

    2. Load VBCCR14.OCX components (or Std-EXE CommonControls, doesn't matter)

    3. Put first a TextBoxW1 and then a CommandButtonW1 on Form1.

    4. Add new Form (as Form2)

    5. Put a TextBoxW1 and a TextBoxW2 on Form2.

    6. put following code in Form1:
    Code:
    Private Sub CommandButtonW1_Click()
    Form2.Show vbModal
    End Sub
    
    Private Sub Form_Load()
    CommandButtonW1.Default = True
    End Sub
    7. Run project -> when on TextBoxW1 press Return key -> Form2 will be shown modally -> now press right arrow key

    The IOleInPlaceActiveObject seems to stuck on Form1 when Form2 is shown modally, thus the accelerator keys are not trapped in Form2 on the TextBoxW controls, resulting that instead of moving the caret on right arrow key the other TextBoxW2 is focused instead.

    The solution in mind is when ActivateIPAO is called on a new Form then re-subclass the VTable for IOleInPlaceActiveObject with a new ObjectPointer from Form2, this way it is not "stuck" on Form1.

    However, that solution is still in process and I need some time to find an optimal way. However, I do already want to make this bug public.

    What I do also find interesting is when "clicking" (by mouse) CommandButtonW1 the issue is not happening.
    Only when invoking by return key (via Default) the problem seems to appear. (I have a clue, but not sure..)

    Did somebody else already encountered this bug? Or is this new?
    Can everybody reproduce it?

    EDIT: On modeless Form2 this bug is of course not happening
    Last edited by Krool; May 18th, 2017 at 03:40 PM.

  32. #1432

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Quote Originally Posted by Krool View Post
    However, unfortunately there is no way to check if the top parent is a VB.PropertyPage or not. (if not a VB.Form of course)
    So, they will be no support for VB.PropertyPage. (of course only for .ValidateControls)
    Now VB.PropertyPage is supported for .ValidateControls (CausesValidation; mouse activation) when a Control is sited on such a VB.PropertyPage.
    There was indeed no VB native way to check if the top parent is a VB.PropertyPage or not. (TypeOf)
    However, with a manual IUnknown.QueryInterface for IPropertyPage it is possible to check for it.

    The 'GetUserControlTopParent' in Common.bas is removed and replaced by a generic 'GetTopUserControl' function.
    That generic GetTopUserControl function will return the current UserControl if there is no "upper" UserControl, else it will walk the chain up to the final UserControl.
    It is intended that such a generic function is placed in Common.bas as it can be used for many other purposes.

    Included 'VTableInterfaceSupported' function in VTableHandle.bas. This is a generic function that will do a IUnknown.QueryInterface on a given IID (as String) and returns a Boolean if it is supported or not.

    Included 'ComCtlsTopParentValidateControls' function in ComCtlsBase.bas. This is a specific wrapper function that will do following:
    Code:
    Public Sub ComCtlsTopParentValidateControls(ByVal UserControl As Object)
    With GetTopUserControl(UserControl)
    If TypeOf .Parent Is VB.Form Then
        Dim Form As VB.Form
        Set Form = .Parent
        Form.ValidateControls
    Else
        Const IID_IPropertyPage As String = "{B196B28D-BAB4-101A-B69C-00AA00341D07}"
        If VTableInterfaceSupported(.Parent, IID_IPropertyPage) = True Then
            Dim PropertyPage As VB.PropertyPage, TempPropertyPage As VB.PropertyPage
            CopyMemory TempPropertyPage, ObjPtr(.Parent), 4
            Set PropertyPage = TempPropertyPage
            CopyMemory TempPropertyPage, 0&, 4
            PropertyPage.ValidateControls
        End If
    End If
    End With
    End Sub
    So in each control it is just enough to make a 'Call ComCtlsTopParentValidateControls(Me)' and test for error code 380.

  33. #1433
    New Member
    Join Date
    Nov 2016
    Posts
    5

    Re: CommonControls (Replacement of the MS common controls)

    This set of controls would be 100% complete for me if it could have:

    > TreeView with columns (would need extending with columns and subitems for each node) - currently I use this but there are a few issues and keeping just one set of controls up to date and in the same place makes like easier
    > COM control (never expect this to happen, but I don't get on with MSCOMM and I hate dragging the ocx around)

    and then I would never need anything else

    Keep up the amazing work!

  34. #1434
    Hyperactive Member
    Join Date
    Sep 2012
    Posts
    459

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Sam_ View Post
    This set of controls would be 100% complete for me if it could have:

    > TreeView with columns (would need extending with columns and subitems for each node) - currently I use this but there are a few issues and keeping just one set of controls up to date and in the same place makes like easier
    > COM control (never expect this to happen, but I don't get on with MSCOMM and I hate dragging the ocx around)

    and then I would never need anything else

    Keep up the amazing work!
    I don't know what "COM control" means. Krool has released the pre-compiled VBCCR14.OCX:
    http://www.vbforums.com/showthread.p...55#post5129155

  35. #1435
    PowerPoster
    Join Date
    Oct 2013
    Posts
    2,917

    Re: CommonControls (Replacement of the MS common controls)

    Sam_ is referring to an alternative of the MSCOMM component which is used for accessing (serial) COM ports.

  36. #1436

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Issue described on post #1431 is now solved.

    The OCX is also updated, except the change concerning the default value of the WordWrap property for the LabelW control.
    This will be respected only in a future OCX release.

  37. #1437
    Member
    Join Date
    May 2016
    Location
    China
    Posts
    46

    Re: CommonControls (Replacement of the MS common controls)

    Can listview set the height of each item?
    QQ: 289778005

  38. #1438
    New Member
    Join Date
    Apr 2017
    Posts
    5

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    Please refer to my message #1363 and your reply message #1364 (related to the RichTextBox control).

    With respect to the solution you provided to fix one error at it's root cause, what happens now is that whenever my RichTextBox control (say, rtb1) becomes empty (i.e. having no text), the following error occurs:
    "Subscript out of range"

    The above-mentioned error occurs at the following line:
    Code:
    ReDim StreamStringIn(0 To StreamStringInLength - 1) As Byte
    This is because 'StreamStringInLength' is 0.

    So, at my end, I am keeping your old lines of code itself (i.e. without adding '-1') and hence I am still resorting to use my following line of code:
    Code:
    Value = Left$(Value, Len(Value))
    I, in fact, have one more line of code before the above line to tackle the issues related to VbCrLf. It is as follows:
    Code:
    Value = Replace(RtfStreamStringOut(), vbCrLf, vbCr)
    So far, everything has been working smoothly at my end with my above two lines of code. But, I would love to hear from you as to whether there is any other solution to fix the error at it's root cause.

    Best of all wishes to you, ever, for your wonderful work!

  39. #1439

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by softv View Post
    Please refer to my message #1363 and your reply message #1364 (related to the RichTextBox control).

    With respect to the solution you provided to fix one error at it's root cause, what happens now is that whenever my RichTextBox control (say, rtb1) becomes empty (i.e. having no text), the following error occurs:
    "Subscript out of range"
    Oops. Thank you.

    Update released.

    Fix was following change in RichTextBoxBase.bas:
    Code:
    Public Sub RtfStreamStringIn(ByVal Value As String)
    StreamStringInLength = LenB(Value)
    Erase StreamStringIn()
    If StreamStringInLength > 0 Then
        ReDim StreamStringIn(0 To (StreamStringInLength - 1)) As Byte
        CopyMemory StreamStringIn(0), ByVal StrPtr(Value), StreamStringInLength
    End If
    StreamStringInPos = 0
    End Sub

  40. #1440

    Thread Starter
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    861

    Re: CommonControls (Replacement of the MS common controls)

    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
    I pointed out this issue now.
    The problem is certainly that the auto sizing feature is dependent on the UserControl_Paint event, which is not being fired during Form_Load.
    Only solution which come into my mind is to remove the auto size calculation in UserControl_Paint and do it in a separate routine with a memory DC.
    I think that little overhead is reasonable and certainly the intrinsic Label control must be doing something similar..
    So I think that problem is worth solving in the near future.

Page 36 of 47 FirstFirst ... 263334353637383946 ... 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

Survey posted by VBForums.