Page 35 of 94 FirstFirst ... 25323334353637384585 ... LastLast
Results 1,361 to 1,400 of 3726

Thread: CommonControls (Replacement of the MS common controls)

  1. #1361
    Hyperactive Member
    Join Date
    Feb 2014
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    ...
    The LinkLabel is a different story, but there is no way I can see to have a Center Alignment.
    So I guess you need to "manually" center it with line breaks and spaces.
    Thanks for the reply.

    I wasn't hopeful with the LabelW queston. I was checking the LinkLabel in VS 2017 Form and there is center alignment so I tried my luck. Guess the only way for me now to adopt Win10 GUI is to bite the bullet and go UWP and accept the fact that I can only target Win10 and later.

    Thanks anyway.

  2. #1362

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Included the ShowTips property in the CoolBar control and the corresponding ToolTipText property of a Band.
    RBS_TOOLTIPS style is not working (according to MSDN "not yet supported"), so it was necessary to create a own internal tool tip control.

    The "hot region" for showing the ToolTipText is the caption/icon area in a Band.
    Last edited by Krool; Apr 14th, 2017 at 05:08 PM.

  3. #1363
    Addicted Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    234

    Re: CommonControls (Replacement of the MS common controls)

    This post - http://www.vbforums.com/showthread.p...=1#post5160309 - of mine, in the related ActiveX thread, is with regard to some problems encountered by me while using the RichTextBox control of the 'MS Common Controls Replacement' project. I realised today that there is not much activity in the related ActiveX thread. Hence, I am now re-posting my aforesaid reply-post in this thread, hereunder. Hope thats okay, Krool and others. Kindly please help.


    First and foremost, thanks a ton to Krool for this wonderful effort. This is absolutely marvelous and it is pretty exciting to go through the various aspects of this project (Replacement of the MS common controls). Though I am interested in all the controls, as of now, my primary interest is on the RichTexBox. So, I started experimenting with it and I encountered some problems.


    I am listing the problems below along with a code snippet to illustrate the problems. Please note that I am new to this forum and this is the first time I am writing here. So, in case I have not followed any protocols related to posting, kindly bear with me and please do guide me for later posts. Also, in case I have understood things completely wrongly about one or more aspects of either the RichTextBox control of this project or of this project itself and that is the reason for me facing the following problems, then kindly correct my understanding and kindly guide me as to what to do to set right the following problems.


    Problems:
    1. When I set some string (e.g. "a") for a RichTexBox control (say, named 'rtb1') and then compare the text with the same string (i.e. if rtb1.text = "a"), the comparison does not return true. Also, adding some string to the end of 'rtb1' results in characters not present in the string getting added (and displayed). I found that space in the original string was always getting replaced by a character whose Unicode value was U2000 (Decimal - 8192). Same with other characters, as far as I observed. A specific character (say 'a') was always getting replaced by one other specific character.


    2. 'Len' and 'Instr' consider "VbCrLf"s fully whereas 'SelStart' and 'Find' ignore the Lf in "VbCrLf"s. Because of this, inconsistencies arise.


    The code below illustrates what happens because of the above two problems. It needs a Form with a CommandButton (Command1) and a RichTextBox (named 'rtb1')
    Code:
    Private Sub Command1_Click()
      
      Dim s As String
      
      s = " a " & vbCrLf & vbCrLf & " ab"
      
      rtb1.Text = s
      If rtb1.Text = s Then
        MsgBox "yes"
      End If
      
      MsgBox "Length = " & Len(rtb1.Text) '10 is displayed
      rtb1.SelStart = Len(rtb1.Text)
      MsgBox "Selstart = " & rtb1.SelStart '8 is displayed
        
      MsgBox "Instr b = " & InStr(rtb1.Text, "b") '10 is displayed
      MsgBox "Find b = " & rtb1.Find("b") '7 is displayed
      
      rtb1.Text = rtb1.Text & s 'characters not present in string 's' get added (and displayed)
                                
    End Sub

    Note-1:
    After working on "problem 1" for around 6 hours - to find its cause and a possible solution, I finally set right the problem at my end by introducing a line of code in the following function of 'RichTextBox.ctl'.
    Code:
    Private Function StreamStringOut(ByRef Value As String, ByVal Flags As Long) As Long

    I added the following line
    Code:
    Value = Left$(Value, Len(Value))
    after the line
    Code:
    Value = RtfStreamStringOut()
    in the aforesaid 'StreamStringOut' function.


    I am not at all suggesting that the inclusion of the above line of code is the right thing to do. I am just mentioning what I did so that it can serve as a tip to Krool or any other member to find out the right thing to be done, eventually.


    Note-2:
    As of now, I do need VbCrLf in my programs. So, I would be happy if the eventual solution does consider VbCrLf fully so that it is consistent with the behavior of the normal RichTextBox (RICHTX32.OCX component, I mean).


    Note-3:
    I have tested with the latest version of the ocx control (1.4.11). My system is Windows 7, 64-bit.


    A few queries now:
    1. The links in the RichTextBox are not clickable. I have to set some property on or off to make them clickable? If so, what is that property? If not, is anything planned for making the links clickable in future?
    2. The normal RichTextBox wraps text around even if horizontal scroll bar is set. The RichTextBox of this project wraps text around only when the horizontal scroll bar is not set. Can the RichTextBox of this project also made to wrap text around even if horizontal scroll bar is set?


    Thanks.

  4. #1364

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Update released. (Thanks to softv)

    Quote Originally Posted by softv View Post
    Problems:
    1. When I set some string (e.g. "a") for a RichTexBox control (say, named 'rtb1') and then compare the text with the same string (i.e. if rtb1.text = "a"), the comparison does not return true.
    There was indeed an error in the RtfStreamCallbackStringOut and RtfStreamStringIn function in the RichTextBoxBase.bas module.

    Fix in RtfStreamCallbackStringOut
    Code:
    ReDim Preserve StreamStringOut(0 To (StreamStringOutUBound + BytesRequested - 1)) As Byte
    Fix in RtfStreamStringIn
    Code:
    ReDim StreamStringIn(0 To (StreamStringInLength - 1)) As Byte
    The Byte array is zero-based so the string was then in fact 11 bytes long for a 5 char (10 bytes) string.
    However, Len() still reports 10, but comparison did not return true as 11 bytes vs 10 bytes. That's why your workaround with Value = Left$(Value, Len(Value)) "solved" the issues as it cut of the 1 byte at the end. But now the error is solved at the root cause.

    The other issues concerning the 'SelStart' and 'Find' I don't have a solution. I have no influence of what EM_EXGETSEL/EM_EXSETSEL or EM_FINDTEXTEX does.
    Last edited by Krool; Apr 17th, 2017 at 03:51 PM.

  5. #1365
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: CommonControls (Replacement of the MS common controls)

    Krool, I've said it before but I'll say it again. You're INCREDIBLE to maintain this code to the level you do. I maintain substantial pieces of code myself, but I typically get paid for it. It's all GPLv3 open source, but I still get paid for improvements. On the beneficent side, I do try to throw generic chunks of it out onto these forums as often as I can when it seems appropriate.

    But what you've done here is truly remarkable.

    Best Regards,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  6. #1366
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: CommonControls (Replacement of the MS common controls)

    Just some thoughts regarding the InStr() and Find() not returning same value. Using the exact code 3 posts up and in IDE using the standard RTF ocx (not this project's RTF control), those functions do NOT return the same value. However, Len() and SelStart() do.

    I don't know what version VB's standard RTF is, but have read that RTF standards v1 used CrLf (internally) for /par markers and v2 uses Lf (internally). This appears to be the reason for the differences in this project's RTF? And if tested, if you added this text: "0123456789" & vbCrLf, 10 times, Len() should be 10 characters longer than SelStart after SelStart=Len()

    Note that when rtf is converted to standard text, /par is converted to CrLf. Am unsophisticated test is setting the control's text to: "a" & vbLF. Len() returns 3 not 2. Hence Len() which works on non-rtf returning more characters than SelStart which works on rtf.
    Last edited by LaVolpe; Apr 17th, 2017 at 08:54 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}

  7. #1367
    Addicted Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    234

    Re: CommonControls (Replacement of the MS common controls)

    Thanks for your very prompt multiple action (fixing the error at its root and also releasing a new update immediately), Krool. Great!

    This project is a phenomenal work, not only because of the complexity involved but for the immense benefit it is providing as well. 1000s of developers must be getting benefited through this work and as a consequence, millions of end-users must be getting benefited too. In that way, what a monumental contribution to the world society!

    Well, reg. 'SelStart' and 'Find', I will try to do something similar to what I did for "problem 1". If I succeed, I will share the lines of code here so that, if at all possible, you can give an eventual solution for the issues concerning 'SelStart' and 'Find' also.

    I will also try to study more about EM_EXGETSEL/EM_EXSETSEL and EM_FINDTEXTEX.

    Thanks.

  8. #1368
    Addicted Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    234

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    Just some thoughts regarding the InStr() and Find() not returning same value. Using the exact code 3 posts up and in IDE using the standard RTF ocx (not this project's RTF control), those functions do NOT return the same value.
    Actually, I had tested that same code at my end too, with the standard rtf ocx. I tested it again at my end after reading your above observation. Find() returned/returns the expected value (9), which is one lesser than the value (10) returned by InStr(). So, with standard rtf ocx, Find() does work correctly at my end, right? Kindly advise. My richtx32.ocx version is 6.1.97.82.

    Thanks.

  9. #1369
    New Member
    Join Date
    Apr 2017
    Posts
    1

    Re: CommonControls (Replacement of the MS common controls)

    Hi Kroll,

    Congratulations for your effort, first of all!!!
    There's no alternative for mscomctl.ocx 64bit and I'm struggling to find a solution for that since Microsoft doesn't seem to care. Could your replacement project be compiled for 64bit?

    Thanks and kind regards,
    Dan

  10. #1370
    PowerPoster
    Join Date
    Jun 2015
    Posts
    2,224

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by dan_p View Post
    Hi Kroll,

    Congratulations for your effort, first of all!!!
    There's no alternative for mscomctl.ocx 64bit and I'm struggling to find a solution for that since Microsoft doesn't seem to care. Could your replacement project be compiled for 64bit?

    Thanks and kind regards,
    Dan
    If you can find a 64bit VB6 compiler, Krool will make it happen!

  11. #1371

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    All internal tooltips are now as top-most. (effects all controls that have a internal tooltip control)
    When the tooltip was created by the common control itself it will be changed via SetWindowPos HWND_TOPMOST, otherwise (own tooltip) WS_EX_TOPMOST will be simply added on CreateWindowEx.

    I think it is not "unusual" to set the tooltip window as top-most, there are many tutorials/examples that suggest in doing so to ensure that the tooltip will always be shown.
    Reason that it could not be displayed would be for example when the form window is set to top-most, then the tooltip is displayed behind it. Now it will display correctly in that scenario.

  12. #1372
    Fanatic Member
    Join Date
    Apr 2015
    Posts
    524

    Re: CommonControls (Replacement of the MS common controls)

    Label problem:

    Place 2 labels on a form, both the same font and fontsize.
    1 standard label
    1 Krool label


    Then execute this:

    Code:
    With Label1
    .AutoSize = True
    .Caption = "abcdefg"
    Debug.Print "Label1: ", .Width
    End With
    
    With LabelW1
    .AutoSize = True
    .Caption = "abcdefg"
    Debug.Print "Labelw1: ", .Width
    End With
    The labels both appear correct, their width is ok.
    But the widths are different numbers:
    Name:  vbforums.jpg
Views: 1300
Size:  17.2 KB

    The width is 71 pixels.
    Screen.TwipsPerPixelX is 12.
    71 x 12 = 852

    Something is wrong so far...

    Next effect:
    When I execute the code the second time, the width is 852 for both labels.

    Thank you,
    Karl

  13. #1373

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Karl77 View Post
    The labels both appear correct, their width is ok.
    But the widths are different numbers:

    When I execute the code the second time, the width is 852 for both labels.
    When you set a new caption, then in LabelW a UserControl.Refresh is done. The effective autosizing is done in the UserControl_Paint event as there is a hDC available which is necessary for a DrawText DT_CALCRECT.
    However, it seems there is a "lag" from UserControl.Refresh to effective UserControl_Paint, kind of a PostMessage "effect". It is not immediately.
    I have no idea for the moment of how to solve it. Of course a "Call UserControl_Paint" instead of "UserControl.Refresh" seems to solve the issue, but actually that is not "allowed", or?

  14. #1374
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    Of course a "Call UserControl_Paint" instead of "UserControl.Refresh" seems to solve the issue, but actually that is not "allowed", or?
    With a windowless control, you need the host to initiate the paint event since it is what sends the UC a clipped hDC to draw on. The delay you are seeing is likely between your Refresh call, VB getting that call, and then deciding when to initialize a paint.

    One workaround in this case is to resize the control after setting the caption, when AutoSize is active. If you opt for this, it should be employed in the AutoSize property also when setting it to True.
    Code:
    Public Property Let Caption(ByVal Value As String)
    ...
    If Me.AutoSize Then
        UserControl.Extender.Width = UserControl.Extender.Width + Screen.TwipsPerPixelX \ 2 + 1
    Else
        Me.Refresh
    End If
    ...
    This should force VB to call a repaint immediately, before your property returns, and the resizing above doesn't matter because your AutoSize will resize the control anyway. Just a thought. Personally, I don't necessarily like using TwipsPerPixelX as the offset because that can be quite large if the container's scalemode is say vbInches. A better approach would be to determine the container's scalemode. TwipsPerPixelX is likely the largest unit which should guarantee a resize. If scalemode was twips and we increased size by just +1, no resize event occurs.

    Another workaround is to invalidate the rect of your usercontrol within the host and force a redraw via API. But that may be more difficult for windowless controls than the suggestion above.

    Edited: The downside is that when a border is visible, you may see a flash between the resizing. Maybe the Extender left,top should be used in an Invalidate call after all. But you'll have to find the container's hWnd because your control's container could feasibly be another windowless usercontrol (no hWnd to be used with RedrawWindow)
    Last edited by LaVolpe; Apr 20th, 2017 at 05:12 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}

  15. #1375
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by LaVolpe View Post
    But you'll have to find the container's hWnd because your control's container could feasibly be another windowless usercontrol (no hWnd to be used with RedrawWindow)
    FYI, windowless controls cannot be controls containers per se and this makes ContainerHwnd property always available I guess.

    Btw, this project needs a github repo since long time ago (and probably has been suggested numerous times already).

    cheers,
    </wqw>

  16. #1376
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: CommonControls (Replacement of the MS common controls)

    FYI, windowless controls cannot be controls containers per se
    Actually, that's the only type of control a windowless control can contain. I'm just not sure (have never tried it) if a VB windowless UC can have the ControlContainer property set to True and be assigned as a container for another windowless control that way. However, while the UC is being designed, this is doable with/without the ControlContainer property. I sure hope my memory is good here; not near a VB box prove myself wrong

    Edited: Just a follow up now that I have access to VB again. I created a windowless, transparent, UC and simply placed Krools LabelW inside it & set its backstyle to transparent. When that UC was placed on a form, both the UC & LabelW remained transparent. But your 2nd point appears to 100% valid: The LabelW control reported the UC's container hWnd as its own ContainerHwnd. But, subclassing was a bit messed up in that scenario.
    Last edited by LaVolpe; Apr 21st, 2017 at 12:46 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}

  17. #1377
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: CommonControls (Replacement of the MS common controls)

    My bad. I thought the point was about control containers (like PictureBox) not UserControls with constituent controls.

    cheers,
    </wqw>

  18. #1378

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Update released for the LabelW control. (thanks to Karl77 to bring this issue up)

    It got now two internal improvements.

    Explanation/Solution:

    The first improvement concerns the AutoSize property when the Alignment is <> Left and/or the VerticalAlignment is <> Top.
    Now the glitch as can be seen in the screen below will not happen anymore.
    Name:  LabelGlitch.png
Views: 1262
Size:  19.3 KB
    This was solved by making an "InvalidateRect .ContainerHwnd, RC, 1" after the resizing and reposition of the control, where RC is the old bounding rectangle.

    The second improvement concerns also the AutoSize property. Problem was that after property returns the new state is not reflected immediately, because we needed to wait for a UserControl_Paint to occur in order to do the resizing and reposition. (auto sizing)

    That issue was solved by modifying the Refresh method as following:
    Code:
    Public Sub Refresh()
    If LabelAutoSizeFlag = False Then
        UserControl.Refresh
    Else
        Dim RC As RECT
        With UserControl
        RC.Left = .ScaleX(.Extender.Left, vbContainerPosition, vbPixels)
        RC.Top = .ScaleY(.Extender.Top, vbContainerPosition, vbPixels)
        RC.Right = RC.Left + .ScaleWidth
        RC.Bottom = RC.Top + .ScaleHeight
        InvalidateRect .ContainerHwnd, RC, 1
        UpdateWindow .ContainerHwnd
        ' In UserControl_Paint the bounding rectangle will be invalidated again.
        ' That's why two times UpdateWindow is necessary.
        UpdateWindow .ContainerHwnd
        End With
    End If
    End Sub
    So only when LabelAutoSizeFlag is True the redrawing is done immediately. (and thus the auto sizing)
    And that is necessary to have the new bounding dimensions set before the property returns in order to work with.
    However, when LabelAutoSizeFlag is False the normal .Refresh method is used as no immediate redraw is necessary and also not wanted.
    Because else when you set 10x Caption in a row it would be redrawn 10x, but with UserControl.Refresh it will be consolidated to 1x redraw, which is common behavior all over to improve performance.
    So in fact when you have AutoSize set to True and change the Caption 10x it will be redrawn 10x. But in that special case it is actually wanted because maybe you want to check on each Caption change the resulting Width etc.
    Last edited by Krool; Apr 21st, 2017 at 05:23 PM.

  19. #1379
    Lively Member
    Join Date
    Sep 2016
    Location
    Texas panhandle
    Posts
    64

    Re: CommonControls (Replacement of the MS common controls)

    Krool thanks for so much hard work.
    One little change/addition I made to the
    PPImageListImages.CommandInsert routine
    to save some user drudgery:

    Code:
    Dim Path As String, FileNames() As String
    Dim OpenFileDialog As CommonDialog
    Set OpenFileDialog = New CommonDialog
    With OpenFileDialog
    .Flags = CdlOFNExplorer Or CdlOFNPathMustExist Or CdlOFNFileMustExist Or CdlOFNAllowMultiSelect
    .MaxFileSize = .MaxFileSize * 5000
    .Filter = "All Picture Files|*.ICO;*.CUR;*.BMP;*.GIF;*.JPG|Icons & Cursors (*.ICO;*.CUR)|*.ICO;*.CUR|Bitmaps (*.BMP;*.DIB)|*.BMP;*.DIB|GIF Images (*.GIF)|*.GIF|JPEG Images (*.JPG)|*.JPG|All Files (*.*)|*.*"
    .DialogTitle = "Select Picture"
    .InitDir = GetSetting("VBCCR14", "ImageList", "File", App.Path)
    End With
    If OpenFileDialog.ShowOpen = True Then
        With OpenFileDialog
        If InStr(.FileName, vbNullChar) <> 0 Then
            Path = Left$(.FileName, .FileOffset - 1)
            If Not Right$(Path, 1) = "\" Then Path = Path & "\"
            FileNames() = Split(Mid$(.FileName, .FileOffset + 1), vbNullChar)
        Else
            Path = Left$(.FileName, .FileOffset)
            ReDim FileNames(0) As String
            FileNames(0) = .FileTitle
        End If
        End With
        
        If Not Path = vbNullString Then
            SaveSetting "VBCCR14", "ImageList", "File", Path
    Last edited by VBClassic04; Apr 22nd, 2017 at 07:15 AM.

  20. #1380
    Lively Member
    Join Date
    Oct 2016
    Posts
    108

    Re: CommonControls (Replacement of the MS common controls)

    is there a way to manipulate the width of the combo/list box scrollbar?
    not sure this is the right place for this question, but it would sure be a very useful addition to the controls.
    thanks

  21. #1381
    Fanatic Member
    Join Date
    Apr 2015
    Posts
    524

    Re: CommonControls (Replacement of the MS common controls)

    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:
    Name:  vbforums.jpg
Views: 1295
Size:  6.3 KB

  22. #1382

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    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:
    Name:  vbforums.jpg
Views: 1295
Size:  6.3 KB
    I cannot replicate the problem, at least on win 7.
    Somebody else has this issue?

  23. #1383
    Hyperactive Member
    Join Date
    Feb 2014
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    When the TextBoxW height is not "tall" enough. Depending on the height, either the top border or both top and bottom border do not show. The solution is to set the height tall enough.

    Tested on Win7.

  24. #1384

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chosk View Post
    When the TextBoxW height is not "tall" enough. Depending on the height, either the top border or both top and bottom border do not show. The solution is to set the height tall enough.

    Tested on Win7.
    But normally that should not appear as the edit has its margin from border to content. The content should be clipped then.

  25. #1385
    Hyperactive Member
    Join Date
    Feb 2014
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    Only when CCBorderStyleSingle is applied and the TextBoxW is not "tall" enough. I just did some quick sample. Actually don't have to create a control array. Also no need to be Segoe UI.

    Name:  textboxw.jpg
Views: 1153
Size:  65.8 KB

  26. #1386
    Hyperactive Member
    Join Date
    Feb 2014
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    Earlier I ran the project from the IDE. I just compiled and run the exe. Now no need to have the focus. Note in the screenshot, the focus is on the left.

    Name:  project1.jpg
Views: 1187
Size:  36.8 KB

  27. #1387
    New Member
    Join Date
    Apr 2017
    Posts
    8

    Re: CommonControls (Replacement of the MS common controls)

    Hello Krool ,

    Thanks for offer the CommonControls. That I can use controls in Unicode.

    Something need to help.

    I use the "Listview" control, attachment show we can change the subItem data when we click the data.

    And double Click the data to show some dialog to choose.

    How to do that ? Need your help.

    Thanks
    Attached Images Attached Images  

  28. #1388

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chenfrank_1 View Post
    Hello Krool ,

    Thanks for offer the CommonControls. That I can use controls in Unicode.

    Something need to help.

    I use the "Listview" control, attachment show we can change the subItem data when we click the data.

    And double Click the data to show some dialog to choose.

    How to do that ? Need your help.

    Thanks
    Your image shows kind of a flex grid control and not a ListView control.
    The ListView control is intended to represent data and not to edit data, thus without additional custom code there is no sub item edit available out of the box.

  29. #1389
    Junior Member
    Join Date
    Nov 2015
    Posts
    30

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    Update released.
    Thanks
    Referring to post #1187...

    Just wanted to reply to this update regarding the .FilterIndex property - I can confirm now that in my original scenario which had the problem, the issue is now fixed. I substituted the most recent VBCCR14 in place of what we had been using (VBCCR12) and the problem was resolved. Thanks!

  30. #1390
    New Member
    Join Date
    Apr 2017
    Posts
    8

    Re: CommonControls (Replacement of the MS common controls)

    Delete this quiz...
    Last edited by chenfrank_1; May 4th, 2017 at 11:32 AM.

  31. #1391
    Frenzied Member
    Join Date
    Jan 2010
    Posts
    1,103

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chenfrank_1 View Post
    Attachment is the file for your reference. I am poor for that. But is it similar to "Listview" ?

    We never
    dare to open your attachment. You may open a new thread for your question instead of disturbing this thread.
    Last edited by Jonney; May 2nd, 2017 at 07:27 PM.

  32. #1392

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Improved the "DPI Awareness" in the controls.
    The pixel dimensions of the StdPicture objects were retrieved via UserControl.ScaleX/Y and vbHimetric/vbPixel.
    According to LaVolpe's latest addition in his "Being DPI Aware" Tutorial he reported that VB's ScaleX/Y is broken on exocit or very large DPI settings.
    And indeed, in my testings a 16x16 icon got reported 17x17 at 175% DPI.
    With the new included internal functions CHimetricToPixel_X/Y in Common.bas the correct value 16x16 will be retrieved. (16x16 is just an example)

  33. #1393
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    Update released.

    Improved the "DPI Awareness" in the controls.
    The pixel dimensions of the StdPicture objects were retrieved via UserControl.ScaleX/Y and vbHimetric/vbPixel.
    According to LaVolpe's latest addition in his "Being DPI Aware" Tutorial he reported that VB's ScaleX/Y is broken on exocit or very large DPI settings.
    And indeed, in my testings a 16x16 icon got reported 17x17 at 175% DPI.
    With the new included internal functions CHimetricToPixel_X/Y in Common.bas the correct value 16x16 will be retrieved. (16x16 is just an example)
    AFAIK the problem is that VB handles the TwipsPerPixelX/Y for the screen (unlike the printer object) with integers, so if the actual value of TwipsPerPixelX/Y is not an integer, there will be problems.

    At 96 DPI: for Windows it is 100%, there are 15 TwipsPerPixelX/Y, an integer.
    At 120 DPI: for Windows it is 125%, there are 12 TwipsPerPixelX/Y, an integer.
    At 144 DPI: for Windows it is 150%, there are 10 TwipsPerPixelX/Y, an integer.

    The following preset option that Windows has is 192 DPI, 200%, and the TwipsPerPixelX real value for that is 7.5, a non integer, and there are problems in VB at that DPI setting because VB threat the TwipsPerPixelX/Y as being 7 (or 8, i don't remember now how it rounds).

    At 175%, it is 168 DPI, and the value for TwipsPerPixelX/Y is 8.5714285714285714285714285714286, a non integer, probably rounded to 9 in VB. And there will be problems at that DPI in VB.

    The problems are not limited to the ScaleX/Y functions and the Screen.TwipsPerPixelsX/Y properties, the position and size of the controls that VB handles automatically are also affected.

    For high DPI that can work on VB, we need to chose an integer for TwipsPerPixelX/Y, for example:

    8 TwipsPerPixelX/Y: 180 DPI -> 187.5%
    6 TwipsPerPixelX/Y: 240 DPI -> 250%

    TwipsPerPixelX/Y= 1440/DPI
    DPI= 1440/TwipsPerPixelX/Y

  34. #1394

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Eduardo- View Post
    The problems are not limited to the ScaleX/Y functions and the Screen.TwipsPerPixelsX/Y properties, the position and size of the controls that VB handles automatically are also affected.
    I know. The size will be "corrected" already within UserControl_Resize. In a way that afterwards .ScaleWidth etc. will report correct.
    That point with himetric conversion was only an additional issue.

  35. #1395
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    I know. The size will be "corrected" already within UserControl_Resize. In a way that afterwards .ScaleWidth etc. will report correct.
    That point with himetric conversion was only an additional issue.
    Yes, you can make the controls to work properly on non integer TwipsPerPixelsX/Y values and that's very nice, and for some projects it will be a solution, but in most cases VB still won't work properly, because it will position and size the forms wrongly, and if the program uses Screen.TwipsPerPixelsX/Y to position controls (or for other purposes) it will report a wrong value. Also ScaleX/Y of the forms will fail.

    Unfortunately, we'll need a fix on VB itself to solve that.

  36. #1396

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    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

  37. #1397
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: CommonControls (Replacement of the MS common controls)

    Congratulations, Krool. I am extremely interested in your new VBFlexGrid.

    I have used the Farpoint Spread control for many years. IMO, the new VBFlexGrid should be separated into a independent control, because the Grid control is too complicated, the size of a fully functional Grid control will eventually reach 2-5M, or even greater.

    In addition, separating VBFlexGrid as a stand-alone control makes it easier for users to use it.

    Look forward to seeing your new control as soon as possible.


    Added:
    The size of the VBFlexGrid 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.
    Last edited by dreammanor; May 8th, 2017 at 05:03 AM.

  38. #1398
    Hyperactive Member
    Join Date
    Feb 2014
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    Will there be an option for new VBFlexGrid be Std-Exe? Or will it just be OCX only?

  39. #1399

    Thread Starter
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,373

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chosk View Post
    Hi Krool,

    Will there be an option for new VBFlexGrid be Std-Exe? Or will it just be OCX only?
    It will be first Std-EXE and after a certain trial period also OCX.

  40. #1400
    Hyperactive Member
    Join Date
    Feb 2014
    Posts
    278

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    Thank you.

Page 35 of 94 FirstFirst ... 25323334353637384585 ... 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
  •  



Click Here to Expand Forum to Full Width