dcsimg
Page 67 of 71 FirstFirst ... 175764656667686970 ... LastLast
Results 2,641 to 2,680 of 2831

Thread: CommonControls (Replacement of the MS common controls)

  1. #2641

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

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Internal improvement for ShowPrinter/ShowPrinterEx/ShowPageSetup dialog in the CommonDialog class.
    The DevMode plays now by the rules. (https://support.microsoft.com/en-us/...rties-function)
    Which means the long run:
    1. Determine DevMode size (fMode = 0)
    2. Prepare DevMode (fMode = DM_OUT_BUFFER)
    3. Adjust DevMode for Orientation, PaperSize, ColorMode, and so on... (CommonDialog properties)
    4. Finalize/Merge DevMode (fMode = DM_IN_BUFFER OR'ing DM_OUT_BUFFER)

    Quote Originally Posted by Simos View Post
    1. Trim out not supported flags. e.e. CdlPDNoNetworkButton and cdlPDPrintSetup not supported in ShowPrinterEx and the error returned is generic
    2. Maybe propFlags should be set to zero on exit of all Show functions. (After ShowPrinter I called ShowColor without setting any flags and I got an error)
    1. CdlPDNoNetworkButton and cdlPDPrintSetup are supported in ShowPrinter. How should I trim them out for ShowPrinterEx ? An error is already returned by PrintDlgEx in such case with the error code E_FAIL.
    2. No, sometimes propFlags are different after dialog return, which can be evaluated. So it makes no sense to cut this feature off. It's an easy thing to set .Flags = 0 yourself in your app. The MS CommonDialog control behaves the same. So no change here.

    Quote Originally Posted by Simos View Post
    1.200 should be sufficient enough to cover long Network Printer names and PortNames like OneNote. Just in case don't remove the last "& vbNullChar"
    Done. CCHDEVNAMESEXTRA has been increased now from 100 to 200.
    Last edited by Krool; Mar 3rd, 2020 at 05:04 PM.

  2. #2642
    Member
    Join Date
    Feb 2014
    Posts
    32

    Re: CommonControls (Replacement of the MS common controls)

    Perfect.
    Just curious: why bother to set DMODE if dwBytes=0? If OpenPrinter Or DocumentProperties failed PrintDialog should fail also or not ?
    Sorry. Forget it. PrintDialog drops with the Default Printer if the PrinterName provided does not exist
    Last edited by Simos; Mar 3rd, 2020 at 06:48 PM.

  3. #2643

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Simos View Post
    Just curious: why bother to set DMODE if dwBytes=0? If OpenPrinter Or DocumentProperties failed PrintDialog should fail also or not ?
    Sorry. Forget it. PrintDialog drops with the Default Printer if the PrinterName provided does not exist
    Exactly. I just did a minor modification in code so it's more clear to read and to not bother manually with initializing DevMode in case user-defined printer is invalid.
    If all fails then (red marked) dwBytes is 0 and so will hDevMode (and hDevNames) be NULL, which signals the PrintDlg(Ex) to initialize on their own.

    Code:
    If PropPrinterDefaultInit = False And Not (PropPrinterDriver = vbNullString Or PropPrinterName = vbNullString Or PropPrinterPort = vbNullString) Then
        DeviceName = PropPrinterName
        dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
        If dwBytes = 0 Then
            ' Fallback to default printer as user-defined printer name is invalid.
            DeviceName = GetPrinterDefault()
            dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
        End If
    Else
        DeviceName = GetPrinterDefault()
        dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
    End If
    If dwBytes > 0 Then
        [...]
    End If
    Last edited by Krool; Mar 4th, 2020 at 01:02 PM.

  4. #2644
    Member
    Join Date
    Feb 2014
    Posts
    32

    Re: CommonControls (Replacement of the MS common controls)

    Yes. This is the perfect logic.
    Did you test the Generic / Text Only ?

  5. #2645

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

    Re: CommonControls (Replacement of the MS common controls)

    Update released.
    Sorry for the ongoing updates with CommonDialog.cls
    Hopefully this is now final.

    Quote Originally Posted by Simos View Post
    Yes. This is the perfect logic.
    Almost. Now only the PropPrinterName is used to select a non-default printer on initialization.
    Also the DEVNAMES structure is now always filled according to the DeviceName. (which can be GetPrinterDefault() or PropPrinterName)
    DEVNAMES is important if the printer name is > 32 chars. (if less 32 then DMDeviceName will be read)
    Also PropPrinterDriver and PropPrinterPort are not needed actually, so there are ignored on input.
    On output (dialog function returns) of course the DEVNAMES will be read and all PropPrinterName/PropPrinterDriver/PropPrinterPort will be set.
    I played around very extensively now and this logic must be the "correct" one.

    In code this means following: (changes marked as red)
    Code:
    Dim hPrinter As Long, DeviceName As String, DMODE_B() As Byte, dwBytes As Long
    If PropPrinterDefaultInit = False And Not PropPrinterName = vbNullString Then
        DeviceName = PropPrinterName
        dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
        If dwBytes = 0 Then
            ' Fallback to default printer as user-defined printer name is invalid.
            DeviceName = GetPrinterDefault()
            dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
        End If
    Else
        DeviceName = GetPrinterDefault()
        dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
    End If
    If dwBytes > 0 Then
        [...]
    Code:
        [...]
        If Not DeviceName = vbNullString Then
            ' wDeviceOffset will only be used on input when DMDeviceName got truncated due to the 32 characters limit.
            ' wDriverOffset and wOutputOffset are ignored on input.
            DNAMES.wDriverOffset = 4
            DNAMES.wDeviceOffset = DNAMES.wDriverOffset + 1
            DNAMES.wOutputOffset = DNAMES.wDeviceOffset + Len(DeviceName) + 1
            DNAMES.wDefault = 0
            Buffer = Left$(vbNullChar & DeviceName & vbNullChar & vbNullChar, CCHDEVNAMESEXTRA)
            CopyMemory DNAMES.wExtra(0), ByVal StrPtr(Buffer), LenB(Buffer)
            PDLG.hDevNames = GlobalAlloc(GMEM_MOVEABLE Or GMEM_ZEROINIT, LenB(DNAMES))
            lpDevNames = GlobalLock(PDLG.hDevNames)
            CopyMemory ByVal lpDevNames, DNAMES, LenB(DNAMES)
            GlobalUnlock PDLG.hDevNames
        End If
    End If
    Quote Originally Posted by Simos View Post
    Did you test the Generic / Text Only ?
    No. Why?

    EDIT:
    Another gotcha fixed. (potential memory issue)
    On return, when reading hDevNames, the size is flexible. So instead using LenB(DNAMES) now use GlobalSize().
    I defined CCHDEVNAMESEXTRA as 200 to ensure big enough buffer. However, it may be smaller when not necessary.
    And therefore using LenB(DNAMES) could CopyMemory too much, out of scope of the allocated memory block.
    So GlobalSize() should be the safe way.
    Code:
    If PDLG.hDevNames <> 0 Then
        ' DEVNAMES is a variable length memory block.
        Dim dwMemSize As Long
        dwMemSize = GlobalSize(PDLG.hDevNames)
        If dwMemSize > LenB(DNAMES) Then dwMemSize = LenB(DNAMES)
        Erase DNAMES.wExtra()
        lpDevNames = GlobalLock(PDLG.hDevNames)
        CopyMemory DNAMES, ByVal lpDevNames, dwMemSize
        GlobalUnlock PDLG.hDevNames
        GlobalFree PDLG.hDevNames
        [...]
    Last edited by Krool; Mar 4th, 2020 at 04:39 PM.

  6. #2646
    Member
    Join Date
    Feb 2014
    Posts
    32

    Re: CommonControls (Replacement of the MS common controls)

    Just curious to see if it exist on your pc.
    If it does then call ShowPrinter before the loop. The problem should be fixed.

  7. #2647
    PowerPoster
    Join Date
    Feb 2017
    Posts
    2,215

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    With today's update the sync between Std-EXE and OCX version is broken.

    It's intended to be. It's necessary to fix some problems and also an opportunity to include new features or to solve deficits.

    So when somebody has a wish, now it's the time.
    I don't know whether it is still "the time", what I would like is the Err object information to be preserved.

    I'm already doing this on my own, but that means that I won't be able to update to new versions of the CC (at least not without manually addding that code).

    As a second wish I would like the code of the common controls not to use standard naming for public members that can interfere with already existent public members on the host project, that on other hand, might not be totally compatible one with the other.

    Examples:
    ISubclass interface.
    InIDE function

    Remember, you invited to send "wishes".

  8. #2648

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Eduardo- View Post
    I don't know whether it is still "the time", what I would like is the Err object information to be preserved.

    I'm already doing this on my own, but that means that I won't be able to update to new versions of the CC (at least not without manually addding that code).

    As a second wish I would like the code of the common controls not to use standard naming for public members that can interfere with already existent public members on the host project, that on other hand, might not be totally compatible one with the other.

    Examples:
    ISubclass interface.
    InIDE function

    Remember, you invited to send "wishes".
    What do you mean with Err object?

  9. #2649
    PowerPoster
    Join Date
    Feb 2017
    Posts
    2,215

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    What do you mean with Err object?
    Forget about that. That seems to be a problem only when an OCX is not compiled (it seems to share the same Err object for both projects, exe and ocx in that case).
    I mean, any 'On Error' statement in the OCX project will erase the error information of the Err object of the host program, but that only happens when the OCX is not compiled.
    So it seems not necessary to preserve that information.

  10. #2650
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,226

    Re: CommonControls (Replacement of the MS common controls)

    Ok, I've now found a bug that I need a fix (or work-around) for.

    The TreeView ... when you examine the TreeView1.SelectedItem in either the TreeView1_Click or TreeView1_DoubleClick event, it's the previously selected item, and not the currently selected item.

    It does get changed, but AFTER the TreeView1_Click or TreeView1_DoubleClick events are completed.

    Krool, I can put together a demo if you like, but I think that's pretty clear.

    I just need to find a way of figuring out which node was clicked in both of these events. I suppose I could set a timer in the events, and do my work in the timer ... but that's ugly.

    Am I missing something?

    Thanks,
    Elroy

    EDIT2: Correction ... Apparently, it's only the Click event, and not the DblClick event.

    EDIT: I went ahead and made a demo and a video. Here's the demo code in a Form1:

    Code:
    
    Option Explicit
    
    Private Sub Form_Load()
        TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "aaaaaa"
        TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "bbbbbb"
        TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "cccccc"
        TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "dddddd"
    End Sub
    
    Private Sub TreeView1_Click()
        Debug.Print TreeView1.SelectedItem.Text
        MsgBox TreeView1.SelectedItem.Text
    End Sub
    
    
    And a video:


    And the little demo is attached:
    Attached Files Attached Files
    Last edited by Elroy; Mar 5th, 2020 at 09:44 PM.
    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. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  11. #2651
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    512

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Elroy View Post
    Ok, I've now found a bug that I need a fix (or work-around) for.

    The TreeView ... when you examine the TreeView1.SelectedItem in either the TreeView1_Click or TreeView1_DoubleClick event, it's the previously selected item, and not the currently selected item.

    It does get changed, but AFTER the TreeView1_Click or TreeView1_DoubleClick events are completed.

    Krool, I can put together a demo if you like, but I think that's pretty clear.

    I just need to find a way of figuring out which node was clicked in both of these events. I suppose I could set a timer in the events, and do my work in the timer ... but that's ugly.

    Am I missing something?

    Thanks,
    Elroy
    I found this out earlier Elroy and I raised it with Krool.

    The old MSCOMCTL treeview, when you click on a node in the tree, the click captured using

    folderTreeView_Click()

    - then the returned node is the one you just clicked on as you would expect.

    eg. folderTreeView.SelectedItem.Key is the current node in the tree

    It would seem that using Krool's TreeView that is not the case.

    eg. folderTreeView.SelectedItem.Key is now always the previously selected node in the tree and not the one you think you have just selected. The treeview click is now merely registering the click on the treeview and not on the node itself.

    Instead of this event:
    Private Sub folderTreeView_Click()

    you now have to create a new event:
    Private Sub folderTreeView_NodeSelect(ByVal Node As CCRTreeView.TvwNode)

    This catches a click on the actual node and not just the treeview as a whole.

    - and where using the old MSCOM treeview you might have wanted to call that event to cause a click on the selected node:

    folderTreeView_Click ' this causes the node to expand

    instead you need to add:
    folderTreeView.SelectedItem.Expanded = True

    This seems to somewhat operate in a similar manner to the .NET treeview where the click event selects the previous node and not the current one, in .NET you have to use the after event to select the currently clicked node.
    Hope that is useful to you. It seems that the treeview click operation in Krool's version is different from the original, I had suggested to Krool that some documentation might be sensible explaining the differences between the two. I offered my quote above as part of that documentation. In response Krool has created the Wiki and I will add my penn'orth to the wiki but life has prevented me from doing so for the moment (sick parents) - so just a quick word here.
    Last edited by yereverluvinuncleber; Mar 5th, 2020 at 09:26 PM.

  12. #2652
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,226

    Re: CommonControls (Replacement of the MS common controls)

    Ahhh, ok. This will work for me.
    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. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  13. #2653
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    512

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Elroy View Post
    Ahhh, ok. This will work for me.
    You have helped me several times, so it is nice to be able to return the favour.

    I will do that bit of documentation - perhaps you could add your penn'orth? If you find any more differences do present them to me and I'll add them to the Wiki.

  14. #2654
    Lively Member
    Join Date
    Aug 2006
    Posts
    84

    Exclamation Bug found in VBCCR CommonControls

    Good evening. Krool I believe I found a strange bug in your controls, my guess is it's the ImageList control but it may also be the ListView. I've attached a sample project that shows the bug in action.

    Essentially, I have a project that adds a configurable amount items to a ListView and loads a small 32x32 image file with LoadPicture to serve as the icon which gets added to the associated imagelist. In the IDE this works correctly 100% of the time, but in the compiled .exe the icons sometimes simply do not get loaded at random. Sometimes you'll open the .exe and all 3 included icons will load no problem, other times they will just be blank for all the items.

    And if they do fail to load, it will keep failing to load them forever, until the program is reopened. Sometimes it will fail immediately upon launching too, and the only way around it is to launch the .EXE again. Again, in the IDE this never happens, they load correctly 100% of the time.

    Moreover, if you try adding many items to the listview, you will crash (typically around 5k to 10k is when it will crash). This crashes both in the IDE and in the compiled EXE. Without the icons the listview works fine, I can add tens of thousands of items with no issues, but as soon as there are icons it crashes around that mark. This particularly is the issue I really need fixed most.

    Attached is the source of the project that displays this bug. It's a very simple one that should be easy to understand. If you could please review it and fix this issue, I'd be incredibly grateful, as it's actually preventing me from developing another application that's suffering from the same problem.

    Thank you very much for your time and thank you for breathing life into this otherwise forgotten language with your excellent work!

    P.S. I should add, this happens both using the OCX and the user controls directly in the project.

    Name:  screenshot.jpg
Views: 382
Size:  41.5 KB
    VBCCR Problem.zip
    Last edited by LinkFX; Mar 7th, 2020 at 02:28 PM. Reason: Readded attachment without compiled code.

  15. #2655
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    512

    Re: Bug found in VBCCR CommonControls

    Crashing with thousands of icons certainly sounds like a memory issue. Without knowing Krool's code I imagine that it may be trying to cache the icons and hence the problem. I recently rolled my own image list to get round a similar problem. On the icon display my own control had an option to display and cache just the icons that were being shown on the panel. It sounds like Krool needs to do the same. This will make the icon display markedly slower each time the icon view is moved onto another page' but it might resolve the crash.
    Last edited by yereverluvinuncleber; Mar 6th, 2020 at 12:20 PM. Reason: typo.

  16. #2656
    New Member
    Join Date
    Mar 2020
    Posts
    2

    Re: Bug found in VBCCR CommonControls

    Hello,

    First of all i want to thank you for your continuous effort.

    are there any plans to develop a new COMCTL32.OCX compatible with Windows touch screen? I know that MSCOMCTL.OCX solves the issue, but we are hoping not to have to replace the executable in our code, but only register the OCX in the system.

    Thank you.

  17. #2657
    New Member
    Join Date
    Mar 2020
    Posts
    2

    Re: Bug found in VBCCR CommonControls

    Hello,

    First of all i want to thank you for your continuous effort.

    are there any plans to develop a new COMCTL32.OCX compatible with Windows touch screen? I know that MSCOMCTL.OCX solves the issue, but we are hoping not to have to replace the executable in our code, but only register the OCX in the system.

    Thank you.

  18. #2658
    Lively Member
    Join Date
    Aug 2006
    Posts
    84

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by yereverluvinuncleber View Post
    Crashing with thousands of icons certainly sounds like a memory issue. Without knowing Krool's code I imagine that it may be trying to cache the icons and hence the problem. I recently rolled my own image list to get round a similar problem. On the icon display my own control had an option to display and cache just the icons that were being shown on the panel. It sounds like Krool needs to do the same. This will make the icon display markedly slower each time the icon view is moved onto another page' but it might resolve the crash.
    I've briefly looked at alternate image list controls but sadly couldn't find any that both supported 32 bit with alpha and were compatible with Krool's Listview control. I don't suppose yours could do it? If so I'd love to give it a shot.

  19. #2659
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    512

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by LinkFX View Post
    I've briefly looked at alternate image list controls but sadly couldn't find any that both supported 32 bit with alpha and were compatible with Krool's Listview control. I don't suppose yours could do it? If so I'd love to give it a shot.
    I'm sorry, I have just had a look at the code and it isn't in a fit state to even extract at the moment. I'm unsure if I could even do it. I used LaVolpe's alpha image code and hacked together something that is inseparable from the rest of my application rather than doing it properly as a real control. It would be unusable to you. However, I will try and extricate the code and build a proper control from it and I'll let you have it when done. I had previously intended to do that. Don't hang around though as I am rather busy with real life so I only get to code for an hour per day if I am lucky. Apologies for raising your hopes. Rather wait for Krool to respond, he is good.

  20. #2660
    Lively Member
    Join Date
    Aug 2006
    Posts
    84

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by yereverluvinuncleber View Post
    I'm sorry, I have just had a look at the code and it isn't in a fit state to even extract at the moment. I'm unsure if I could even do it. I used LaVolpe's alpha image code and hacked together something that is inseparable from the rest of my application rather than doing it properly as a real control. It would be unusable to you. However, I will try and extricate the code and build a proper control from it and I'll let you have it when done. I had previously intended to do that. Don't hang around though as I am rather busy with real life so I only get to code for an hour per day if I am lucky. Apologies for raising your hopes. Rather wait for Krool to respond, he is good.
    No worries man, thanks for considering it though and best of luck with your control! ^-^

  21. #2661
    PowerPoster Arnoutdv's Avatar
    Join Date
    Oct 2013
    Posts
    3,826

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by happyubuntu View Post
    Hello,

    First of all i want to thank you for your continuous effort.

    are there any plans to develop a new COMCTL32.OCX compatible with Windows touch screen? I know that MSCOMCTL.OCX solves the issue, but we are hoping not to have to replace the executable in our code, but only register the OCX in the system.

    Thank you.
    Even if a new control is compatible with an already used control you need the recompile the application.
    It has to do with references, they have of course different IDs.

  22. #2662

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

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by LinkFX View Post
    Essentially, I have a project that adds a configurable amount items to a ListView and loads a small 32x32 image file with LoadPicture to serve as the icon which gets added to the associated imagelist. In the IDE this works correctly 100% of the time, but in the compiled .exe the icons sometimes simply do not get loaded at random. Sometimes you'll open the .exe and all 3 included icons will load no problem, other times they will just be blank for all the items.

    And if they do fail to load, it will keep failing to load them forever, until the program is reopened. Sometimes it will fail immediately upon launching too, and the only way around it is to launch the .EXE again. Again, in the IDE this never happens, they load correctly 100% of the time.

    Moreover, if you try adding many items to the listview, you will crash (typically around 5k to 10k is when it will crash). This crashes both in the IDE and in the compiled EXE. Without the icons the listview works fine, I can add tens of thousands of items with no issues, but as soon as there are icons it crashes around that mark. This particularly is the issue I really need fixed most.

    Attached is the source of the project that displays this bug. It's a very simple one that should be easy to understand. If you could please review it and fix this issue, I'd be incredibly grateful, as it's actually preventing me from developing another application that's suffering from the same problem.
    I think the bottleneck are the GDI object count. (which I can't fix)
    GDI objects represent graphical device interface resources like fonts, bitmaps, brushes, pens, and device contexts (drawing surfaces). As it does for USER objects, the window manager limits processes to at most 10,000 GDI objects
    Why you want to load 5k to 10k unique picture handles ?
    Cannot you use, let's say 10 unique pictures, and re-use them for all the list items? Then it is no problem to have 20k list items having pictures which rely on 10 picture handles.
    Please provide more info on your use-case. Because this is not a good design you have chosen..

  23. #2663
    Lively Member
    Join Date
    Aug 2006
    Posts
    84

    Re: Bug found in VBCCR CommonControls

    Bingo! Thank you very much for the tip! I was not aware of this limit! Following the instructions on this page, I was able to raise that GDI limit further which completely solved that issue!

    The sample project I posted only loads a single individual icon which of course doesn't make sense to make new picture handles from, but the actual application I'm having this issue in does in fact load thousands of individual icons was my point. Now that's fixed and I can load them all without problems though.

    However, the issue of the icons randomly not loading still persists. Could you perhaps take a look at the sample project and see if you can figure out what's wrong and if it's somehow related to your controls? The fact that it works correctly in the IDE but randomly fails in the compiled .EXE mystifies me.

    Thanks a ton for your assistance so far Krool!
    Last edited by LinkFX; Mar 7th, 2020 at 02:25 PM.

  24. #2664
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    34,924

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by LinkFX View Post
    Good evening. Krool I believe I found a strange bug in your controls, my guess is it's the ImageList control but it may also be the ListView. I've attached a sample project that shows the bug in action.

    Essentially, I have a project that adds a configurable amount items to a ListView and loads a small 32x32 image file with LoadPicture to serve as the icon which gets added to the associated imagelist. In the IDE this works correctly 100% of the time, but in the compiled .exe the icons sometimes simply do not get loaded at random. Sometimes you'll open the .exe and all 3 included icons will load no problem, other times they will just be blank for all the items.

    And if they do fail to load, it will keep failing to load them forever, until the program is reopened. Sometimes it will fail immediately upon launching too, and the only way around it is to launch the .EXE again. Again, in the IDE this never happens, they load correctly 100% of the time.

    Moreover, if you try adding many items to the listview, you will crash (typically around 5k to 10k is when it will crash). This crashes both in the IDE and in the compiled EXE. Without the icons the listview works fine, I can add tens of thousands of items with no issues, but as soon as there are icons it crashes around that mark. This particularly is the issue I really need fixed most.

    Attached is the source of the project that displays this bug. It's a very simple one that should be easy to understand. If you could please review it and fix this issue, I'd be incredibly grateful, as it's actually preventing me from developing another application that's suffering from the same problem.

    Thank you very much for your time and thank you for breathing life into this otherwise forgotten language with your excellent work!

    P.S. I should add, this happens both using the OCX and the user controls directly in the project.

    Name:  screenshot.jpg
Views: 382
Size:  41.5 KB
    The attachment you had in this post included compiled code. This site does not allow that due to the potential for the inclusion of harmful items. Please remove the compiled parts and re-attach.
    My usual boring signature: Nothing

  25. #2665

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

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by LinkFX View Post
    Bingo! Thank you very much for the tip! I was not aware of this limit! Following the instructions on this page, I was able to raise that GDI limit further which completely solved that issue!

    The sample project I posted only loads a single individual icon which of course doesn't make sense to make new picture handles from, but the actual application I'm having this issue in does in fact load thousands of individual icons was my point. Now that's fixed and I can load them all without problems though.

    However, the issue of the icons randomly not loading still persists. Could you perhaps take a look at the sample project and see if you can figure out what's wrong and if it's somehow related to your controls? The fact that it works correctly in the IDE but randomly fails in the compiled .EXE mystifies me.
    Whenever you clear the imagelist (.ListImages.Clear) the hImageList changes.
    The internal reason for the hImageList change is that ImageWidth/ImageHeight are "free" again. And that ultimately needs always a re-creation of the hImageList.

    Therefore at end of your routine a simple re-assignment fixes the issue.
    Code:
    Set lvwTest.Icons = lvwTest.Icons
    lvwTest.Redraw = True
    EDIT:

    The behavior of the original MS ImageList is more strict. It just throws out an error if you attempt to make .ListImages.Clear when it is already bound to a control:
    Name:  MSImageListBound.png
Views: 293
Size:  20.0 KB

    However, I don't want to be so strict. With the possibility of mis-use, like you did. However, it's fix-able with a simple re-assignment.
    Last edited by Krool; Mar 8th, 2020 at 10:03 AM.

  26. #2666
    Lively Member
    Join Date
    Aug 2006
    Posts
    84

    Re: Bug found in VBCCR CommonControls

    Quote Originally Posted by Krool View Post
    Whenever you clear the imagelist (.ListImages.Clear) the hImageList changes.
    The internal reason for the hImageList change is that ImageWidth/ImageHeight are "free" again. And that ultimately needs always a re-creation of the hImageList.

    Therefore at end of your routine a simple re-assignment fixes the issue.
    Code:
    Set lvwTest.Icons = lvwTest.Icons
    lvwTest.Redraw = True
    EDIT:

    The behavior of the original MS ImageList is more strict. It just throws out an error if you attempt to make .ListImages.Clear when it is already bound to a control:
    Name:  MSImageListBound.png
Views: 293
Size:  20.0 KB

    However, I don't want to be so strict. With the possibility of mis-use, like you did. However, it's fix-able with a simple re-assignment.
    Thank you very much for looking into my case! That makes a ton of sense.

  27. #2667
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Exclamation Run-time error '0'

    VBCCR v1.6.72 (Side-by-side)
    VB6sp6 (win7x64 developing machine)

    i get the VBCCR16 messagebox "Run-time error '0'" when testing my compiled app on some non-developing-pc's (WinXP(sp3), WinXPx64, Vista or Win8.1x64) and the app crashes.
    Some forms of the app are working fine using the VBCCR-controls, some show up the error message box.

    The same compiled app runs without any error on my developer-pc (Win7x64) and on a test-machine with Win10x64

    Does anyone have some expierence with this error message when loading & displaying a form?

    Any ideas how to debug this problem?

    SOLUTION:

    the problem was the 32bit icons of some buttons and a image-list with 32bit icons!
    After changing the icons to 24bit everythings runs fine again!
    Last edited by Mith; Mar 20th, 2020 at 10:06 PM. Reason: added the solution

  28. #2668
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: CommonControls (Replacement of the MS common controls)

    Does anyone have a clue why you can use 32-bit icons with Win7 and Win10 but the app crashes using WinXP, Vista and Win8!
    First i thought WinXP and Vista are too old but Win7 is older than Win8, i dont get it...

    for example:

    Windows XP supports 32-bit icons, which are 24-bit images with an 8-bit alpha channel.
    is it vb6 that not support 32bit icons on some OS version?
    or maybe you use a icon/image api that is not supported by some older OS?
    Last edited by Mith; Mar 20th, 2020 at 10:10 PM.

  29. #2669
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Exclamation LabelW caption text is truncated under WinXP

    VBCCR v1.6.72 (Side-by-side)
    VB6sp6 (win7x64 developing machine)

    The caption text of some LabelW-Controls is truncated when using the app under WinXP (SP3).
    Many other Label-Controls at my app are not truncated.


    The form with the Label at the IDE at Win7:

    Name:  VB6 IDE Win7.png
Views: 187
Size:  9.7 KB

    This is how the form looks using the app under WinXP:

    Name:  EXE WinXP.jpg
Views: 183
Size:  21.8 KB
    Last edited by Shaggy Hiker; Mar 21st, 2020 at 10:16 AM.

  30. #2670

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

    Re: LabelW caption text is truncated under WinXP

    Quote Originally Posted by Mith View Post
    VBCCR v1.6.72 (Side-by-side)
    VB6sp6 (win7x64 developing machine)

    The caption text of some LabelW-Controls is truncated when using the app under WinXP (SP3).
    Many other Label-Controls at my app are not truncated.
    Nobody can test, when you just attach an exe file (which is NOT allowed) and no source code (Project1.vbp)
    Please re-do.

    Quote Originally Posted by Mith View Post
    Does anyone have a clue why you can use 32-bit icons with Win7 and Win10 but the app crashes using WinXP, Vista and Win8!
    First i thought WinXP and Vista are too old but Win7 is older than Win8, i dont get it...

    for example:

    Windows XP supports 32-bit icons, which are 24-bit images with an 8-bit alpha channel.
    is it vb6 that not support 32bit icons on some OS version?
    or maybe you use a icon/image api that is not supported by some older OS?
    The problem is here OleAut32.lib and it's various OleLoadPicture API's. So it's MS fault, as so often. And it also doesn't matter if creating the IPicture by an byte stream or by an Path.

    What surprises me now is that Win8 also encounter the issue? (I can't test Win8)
    Can you try to to make the following quick and dirty test and try to load a 32-bit icon via VB's LoadPicture ?
    Code:
    Set Pic = LoadPicture("YourPath\test.ico")
    Your "run-time error 0" comes by following:
    You load and persist successfully the 32-bit icon in a "good" OS.
    The error comes then on an "bad" OS when you let VB creating the IPicture from the property bag. (design time usage in ImageList)
    When you would do it only at run-time you would receive the "invalid picture" error.

    I still don't know how to circumvent the issue, because since years the same question over and over re-appears.
    Last edited by Krool; Mar 21st, 2020 at 09:08 AM.

  31. #2671
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: LabelW caption text is truncated under WinXP

    VB example project for testing the LabelW caption text bug:
    Label-Test-WinXP-sourcecode.zip

    I've done a 32bit icon test with the following code under Win8.1 x64:

    Code:
    Dim pic As Variant
    Set pic = LoadPicture(App.Path & "\32bit.ico")
    Error message:

    Name:  Screenshot - 21.03.2020 , 21_44_33.png
Views: 179
Size:  7.3 KB

  32. #2672

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

    Re: LabelW caption text is truncated under WinXP

    Quote Originally Posted by Mith View Post
    VB example project for testing the LabelW caption text bug:
    Label-Test-WinXP-sourcecode.zip

    I've done a 32bit icon test with the following code under Win8.1 x64:

    Code:
    Dim pic As Variant
    Set pic = LoadPicture(App.Path & "\32bit.ico")
    Error message:

    Name:  Screenshot - 21.03.2020 , 21_44_33.png
Views: 179
Size:  7.3 KB
    For me the LabelW I see no bug. It's behaving the same as VB.Label.
    Somehow your Win7 gives for the same font (Arial, Bold, 11pt) a width of 1500 twips and on your WinXP 1560. (Caption "Dateivergleich")
    For me it returns both 1560 on Win7 and WinXP.

    Anyhow, the safest approach is to make an "LabelW1.AutoSize = True" at run-time. (even if already True, re-applying with True will trigger a re-calculation)

    Concerning your icon test. How to avoid this dilemma? Maybe a warning sign when defining 32-bit color depth for an image list at design time. Because that would explain some users up front of an potential "run time error 0". (?)

  33. #2673
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    34,924

    Re: CommonControls (Replacement of the MS common controls)

    Thank you for attaching the source. I removed the attachment with the exe. The forum doesn't allow including compiled code because of things that have happened in the past. Source is always better anyways.
    My usual boring signature: Nothing

  34. #2674
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: LabelW caption text is truncated under WinXP

    Quote Originally Posted by Krool View Post
    For me the LabelW I see no bug. It's behaving the same as VB.Label.
    Somehow your Win7 gives for the same font (Arial, Bold, 11pt) a width of 1500 twips and on your WinXP 1560. (Caption "Dateivergleich")
    For me it returns both 1560 on Win7 and WinXP.
    Are you sure you tested the compiled exe (SxS) or just the test project inside the IDE?

    I did another test with the compiled exe using a fresh installed WinXP 64bit and the caption text is here truncated too:

    Name:  Screenshot - 21.03.2020 , 23_22_18.png
Views: 175
Size:  114.7 KB

    Concerning your icon test. How to avoid this dilemma? Maybe a warning sign when defining 32-bit color depth for an image list at design time. Because that would explain some users up front of an potential "run time error 0". (?)
    I had a lot of command buttons with 32-bit icons at the picture property.
    It was a pain in the ass to find all these controls with 32-bit icons...
    i guess a warning would be very nice to avoid such problems in the future.
    If someone develops a app that must also run with WinXP, Vista or Win8 he cannot use 32bit icons anywhere at the VBCCR controls.
    Im not sure how & where to implement such a warning if the dev adds somewhere a 32bit icon....

  35. #2675
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: LabelW caption text is truncated under WinXP

    Some news about the caption text bug:

    1. the labels use the font "Segoe UI" and this font is not installed under WinXP!
    2. i added some MS-Labels with the same text, font, font size and background color to the test project

    1&3. row is VBCCR and 2&4. row is MS:

    Name:  Screenshot - 21.03.2020 , 23_36_19.png
Views: 172
Size:  102.0 KB

    As you can see the autosize works correct with the MS-Labels.
    Only the autosize of the background color is not correct.

    Maybe the font fallback causes the problem with the incorrect autosizing?

    New test project: Label-Test-WinXP-sourcecode.zip
    Last edited by Mith; Mar 21st, 2020 at 11:52 AM. Reason: added a new test project

  36. #2676

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

    Re: LabelW caption text is truncated under WinXP

    Quote Originally Posted by Mith View Post
    Are you sure you tested the compiled exe (SxS) or just the test project inside the IDE?

    I did another test with the compiled exe using a fresh installed WinXP 64bit and the caption text is here truncated too:
    I don't test ever a compiled exe. Did you read my suggestion to put a LabelW.AutoSize = True at run-time, e.g. at Form_Load.

    The VB.Label behaves the same, means no automatic autosizing.
    The VB.Label and LabelW will for example also do autosizing when you change the .Caption property.

  37. #2677
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: LabelW caption text is truncated under WinXP

    Quote Originally Posted by Krool View Post
    I don't test ever a compiled exe.
    Why not? A compiled exe reacts different than a vb project inside the IDE!

    Did you read my suggestion to put a LabelW.AutoSize = True at run-time, e.g. at Form_Load.
    Yes, but is impractical for large projects...

    The VB.Label behaves the same, means no automatic autosizing.
    At my test with compiled exe the VB-Label does a correct autosizing of the the caption and the LabelW-control not!
    The VB-Label shows the complete text and the LabelW-Control truncates the text at the end...
    Look at the last screenshot again...

  38. #2678
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: CommonControls (Replacement of the MS common controls)

    i tried your suggestion with LabelW.AutoSize = True

    Before:

    Name:  Screenshot - 22.03.2020 , 00_24_19.png
Views: 172
Size:  12.6 KB

    After:

    Name:  Screenshot - 22.03.2020 , 00_24_39.png
Views: 170
Size:  14.4 KB

    It gets better but the letter 'e' of the word 'Profile' is still cutted at the end...

  39. #2679

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

    Re: CommonControls (Replacement of the MS common controls)

    Update released.
    Important for all controls.

    Quote Originally Posted by Mith View Post
    It gets better but the letter 'e' of the word 'Profile' is still cutted at the end...
    I could now replicate the issue. Yes, the font you selected 'Segoe UI Semibold' does not exist in Windows XP.
    It fallbacks to Arial, as Bold. But not with a Weight of 700, instead it is 600.
    When you open the IDE first time and the fallback occurs, it happens. When you then save the project and re-open it does not happen again as the Weight was corrected by the property bag from 600 back to 700.

    The problem is that the LabelW uses for display the UserControl.Font. However, for auto-sizing it creates a temporary hDC and selects a temporary hFont into it.
    The fix for the LabelW was now to use 'GDIFontFromOLEFont' instead of 'CreateGDIFontFromOLEFont'. (GDIFontFromOLEFont is a small wrapper function which returns the hFont from a StdFont object via it's hidden IFont)
    This approach is also better for the LabelW to have less overhead. (get the temporary hFont from the already existing IFont, instead of creating a new one and delete right after auto-size)

    However, for the other controls (where a permanent hFont is needed) it could be an cosmetic issue. (though hard to see, because in your example a Weight of 600 vs 700 is not noticed easily)
    The fix for the others was to change the CreateGDIFontFromOLEFont function.
    (red marked text was old code and blue marked text is new code)
    Code:
    Public Function CreateGDIFontFromOLEFont(ByVal Font As IFont) As Long
    [...]
    If Font.Bold = True Then .LFWeight = FW_BOLD Else .LFWeight = FW_NORMAL
    .LFWeight = Font.Weight
    [...]
    CreateGDIFontFromOLEFont = CreateFontIndirect(LF)
    End Function
    So, thanks for your report. It took a while to re-construct and find the cause.
    Last edited by Krool; Mar 22nd, 2020 at 08:51 AM.

  40. #2680
    Lively Member
    Join Date
    Jul 2017
    Posts
    103

    Re: CommonControls (Replacement of the MS common controls)

    i tested the new version .74 and i can cofirm that manual resizing (turning autosize off and on) fixes now the problem with the truncated text.

    But why does the autosize feature of the MS label control works correct without manual resizing?
    it looks like there is still something to improve/fix...

Page 67 of 71 FirstFirst ... 175764656667686970 ... 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