Page 81 of 82 FirstFirst ... 31717879808182 LastLast
Results 3,201 to 3,240 of 3247

Thread: CommonControls (Replacement of the MS common controls)

  1. #3201
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,497

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chrislong2 View Post
    Anyway, it's fine. In line with what Krool pointed to, I've modified the RTB to just change the StreamStringIn and StreamFileIn functions to call EM_EXLIMITTEXT with PropMaxLength instead of 0 and it works fine now.
    The developers of Notepad probably did something similar. Would have been nice if Controls came out of the box with these things set. Oh well. World isn't perfect.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  2. #3202

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chrislong2 View Post
    1) Ok, so I set MaxLength to a really high number and it works for the initial load of text (I can now type beyond 65k), however, as soon as I change scrollbars (to control word wrapping) or otherwise refresh the control, it loses the maxlength and goes back to 65k. So there still seems to be a bug with how MaxLength is handled where it is not always honored.
    I cannot replicate this bug. Can you provide a demo ?

    Quote Originally Posted by chrislong2 View Post
    Anyway, it's fine. In line with what Krool pointed to, I've modified the RTB to just change the StreamStringIn and StreamFileIn functions to call EM_EXLIMITTEXT with PropMaxLength instead of 0 and it works fine now. That really I think is the way it should be anyway as it should always be using the PropMaxLength value (if a value is not set, then it will default to 0 anyway so it should just call it with PropMaxLength instead of a hardcoded 0 val). Then if anyone cares about >65k, they can just set the PropMaxLength to whatever they want. I would argue that PropMaxLength should even be set by default to a much higher value (like 1MB). I just tested and 1MB file was opened quick and worked with quickly on my 10yo machine. I tried a 30MB file and that also worked but was much more sluggish a la what Notepad does.
    Your true. I don't know why I added those hardcoded 0&. And also calling twice on StreamFileIn.

    Can you make a test and just remove all those red lines in the code and test if everything is OK ? If you report success I will initiate an update. Thanks

    Code:
    Private Function StreamStringIn(ByVal Value As String, ByVal Flags As Long) As Long
    If RichTextBoxHandle <> 0 Then
    [...]
        If (Flags And SF_RTF) <> 0 Then SendMessage RichTextBoxHandle, EM_EXLIMITTEXT, 0, ByVal 0&
        StreamStringIn = SendMessage(RichTextBoxHandle, EM_STREAMIN, Flags, ByVal VarPtr(REEDSTR))
        If (Flags And SF_RTF) <> 0 Then SendMessage RichTextBoxHandle, EM_EXLIMITTEXT, 0, ByVal PropMaxLength
        Call RtfStreamStringInCleanUp
    End If
    End Function
    
    Private Function StreamFileIn(ByVal FileName As String, ByVal Flags As Long) As Long
    If RichTextBoxHandle <> 0 Then
    [...]
            If (Flags And SF_RTF) <> 0 Then SendMessage RichTextBoxHandle, EM_EXLIMITTEXT, 0, ByVal 0&
            StreamFileIn = SendMessage(RichTextBoxHandle, EM_STREAMIN, Flags, ByVal VarPtr(REEDSTR))
            If (Flags And SF_RTF) <> 0 Then SendMessage RichTextBoxHandle, EM_EXLIMITTEXT, 0, ByVal 0&
            CloseHandle hFile
        End If
    End If
    End Function
    Last edited by Krool; Aug 9th, 2021 at 03:32 AM.

  3. #3203

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

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Removal of EM_EXLIMITTEXT (Flags = SF_RTF) in internal StreamStringIn/StreamFileIn in the RichTextBox control.
    It was probably put there by error or by misunderstanding of the MSDN documentation.

    I could not find any reason why it should be in that function... strange.. However, now it's erased..

  4. #3204
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    Update released.
    I tested the new update (.25) of the RichTextBox control with text files in several sizes using this code:

    Code:
    10 rtfTest.LoadFile sFilePath, RtfLoadSaveFormatText
    20 rtfTest.SelStart = 0
    30 rtfTest.SelLength = Len(rtfTest.Text)
    40 rtfTest.SelColor = vbBlack
    50 rtfTest.SelLength = 0
    14,6 MB -> OK
    17,2 MB -> OK
    20,0 MB -> OK
    32,0 MB -> OK
    68,0 MB -> loading ok, but "no memory" error at line 30

    after removing line 20 to 50 everything is working well:

    109 MB -> OK
    172 MB -> OK

    Loading the files is very fast.
    Should i use the command .clear before loading a file to reset the current style of the RTB?
    Last edited by Mith; Aug 10th, 2021 at 09:25 PM.

  5. #3205

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Mith View Post
    I tested the new update (.25) of the RichTextBox control with text files in several sizes using this code:

    Code:
    10 rtfTest.LoadFile sFilePath, RtfLoadSaveFormatText
    20 rtfTest.SelStart = 0
    30 rtfTest.SelLength = Len(rtfTest.Text)
    40 rtfTest.SelColor = vbBlack
    50 rtfTest.SelLength = 0
    14,6 MB -> OK
    17,2 MB -> OK
    20,0 MB -> OK
    32,0 MB -> OK
    68,0 MB -> loading ok, but "no memory" error at line 30

    after removing line 20 to 50 everything is working well:

    109 MB -> OK
    172 MB -> OK

    Loading the files is very fast.
    Should i use the command .clear before loading a file to reset the current style of the RTB?
    Retrieving the Text makes again an stream out. And when you do it in the IDE the memory limit is quickly hit.

    Better is just to extract the length, e.g.
    Code:
    Dim Length As Long, REGTLEX As REGETTEXTLENGTHEX
    REGTLEX.Flags = GTL_PRECISE Or GTL_NUMCHARS
    REGTLEX.CodePage = CP_UNICODE
    Length = SendMessage(RichTextBoxHandle, EM_GETTEXTLENGTHEX, VarPtr(REGTLEX), ByVal 0&)

  6. #3206
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    Retrieving the Text makes again an stream out. And when you do it in the IDE the memory limit is quickly hit.

    Better is just to extract the length, e.g.
    Code:
    Dim Length As Long, REGTLEX As REGETTEXTLENGTHEX
    REGTLEX.Flags = GTL_PRECISE Or GTL_NUMCHARS
    REGTLEX.CodePage = CP_UNICODE
    Length = SendMessage(RichTextBoxHandle, EM_GETTEXTLENGTHEX, VarPtr(REGTLEX), ByVal 0&)
    Thanks for the feedback!

    How about we add a new function called GetTextLength to the RTB control?

  7. #3207
    Frenzied Member
    Join Date
    Jan 2020
    Posts
    1,621

    Re: CommonControls (Replacement of the MS common controls)

    SOME TIMES ,I ONLY NEED TextboxW CONTROL,IT'S maked 210kb
    TextboxW.OCX

    only use listview control,it's used 1MB
    VBCCR16.OCX 5mb size

    The overall volume of an OCX is a bit larger. It is very difficult to disassemble the various controls to reduce the size of the compiled EXE.

  8. #3208
    Lively Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    80

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    Bug is fixed in PPCoolBarBands. It shouldn't list anymore "valid but windowless" controls. Now it lists only "valid with window handle".
    Problem was that the internal window handle variable in the enumeration was not cleared. ... .. .
    Thanks a TON for the update. And, once again, thanks a TON for your beautiful and immensely beneficial controls.

    One observation, my dear krool, regarding CoolBars.

    Inside any Band of a CoolBar control:
    --
    Case 1. If I have a FrameW in the Band and if I place a normal Label or LabelW(yours) inside that FrameW, the labels do not display their ToolTipText.

    Case 2. If I have a Frame or Picture in the band and if I place a normal Label or LabelW(yours) inside that Picture/Frame, the labels do display their ToolTipText. No issues.
    --

    If my observation in Case 1 is correct, then, what should I do to have the ToolTipText get displayed by Label and LabelW in Case 1.
    If my observation in Case 1 is incorrect, then, what mistake am I doing? Kindly guide me.

    Kind regards.

  9. #3209

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by softv View Post
    Thanks a TON for the update. And, once again, thanks a TON for your beautiful and immensely beneficial controls.

    One observation, my dear krool, regarding CoolBars.

    Inside any Band of a CoolBar control:
    --
    Case 1. If I have a FrameW in the Band and if I place a normal Label or LabelW(yours) inside that FrameW, the labels do not display their ToolTipText.

    Case 2. If I have a Frame or Picture in the band and if I place a normal Label or LabelW(yours) inside that Picture/Frame, the labels do display their ToolTipText. No issues.
    --

    If my observation in Case 1 is correct, then, what should I do to have the ToolTipText get displayed by Label and LabelW in Case 1.
    If my observation in Case 1 is incorrect, then, what mistake am I doing? Kindly guide me.
    Looks for me like a VB6 bug in the FrameW control, which is an ordinary ControlContainer UserControl. It does not recognize the ToolTipText from windowless contained controls.
    I don't know how to fix.

  10. #3210
    Lively Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    80

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    1)
    The RTB initial limit is 32k. EM_EXLIMITTEXT will be called at creation with 0 (default) which sets the RTB limit to 65k.
    So I would suggest you calc the length of your source and set it accordingly. Or just set an crazy high value.

    2)
    I know this quirk and have no idea how to solve. I need help in this.
    Krool had written to me on the above as early as 2017 itself. Since that time, I have been waiting to see whether anyone can come with a solution for the quirk mentioned in the 2nd point.

    Anyway, based on Krool's valuable advice (as in his 1st point), I always remember to set my RichTextBox controls' MaxLength to 2147483647 (the maximum limit) so that I do not ever need to worry about the text length limits of my RichTextBoxes. I also set the ScrollBar to Vertical (in order to address one issue, which I am not able to recall, as of now).

    And, reg. the 2nd point, after writing very many lines of code of my own, to somehow take care of the issues related to vbCrLf (but eventually unable to take care of the issues 100% correctly), I finally decided to drop all those lines of code and just do the following alone so that I need not have to worry about those vbCrLF-related issues at all ever after. What I did was:

    In the function "Private Function StreamStringOut(ByRef Value As String, ByVal Flags As Long) As Long", I made the following changes
    --
    '''''Value = StrConv(RtfStreamStringOut(), vbUnicode)
    Value = Replace$(StrConv(RtfStreamStringOut(), vbUnicode), vbCrLf, vbCr)


    '''''Value = RtfStreamStringOut()
    Value = Replace$(RtfStreamStringOut(), vbCrLf, vbCr)
    --

    In other words, in the abovementioned function, I commented out two lines (as shown above) and replaced them with my own lines (as above). In effect, I just replaced all vbCrLf with vbCr. For my freeware's requirements, dealing with VbCr alone was not any big problem. So, with the above changes, for the past 4 years, the vbCrLf-related issues are not present.

    Just thought of sharing the above info so that it is of help to someone. Nothing else.

    Thanks Krool once again, for your monumental efforts and such a stupendous service to the world society.

    Kind Regards.

  11. #3211
    Lively Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    80

    Re: CommonControls (Replacement of the MS common controls)

    Thanks a TON for your prompt reply, Krool. At present, as a workaround, I am placing the Labels again inside another Picture or Frame control (normal one).

    Kind Regards.

  12. #3212
    Lively Member
    Join Date
    Apr 2017
    Location
    India
    Posts
    80

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by softv View Post
    ... .. . In other words, in the abovementioned function, I commented out two lines (as shown above) and replaced them with my own lines (as above). In effect, I just replaced all vbCrLf with vbCr. For my freeware's requirements, dealing with VbCr alone was not any big problem. So, with the above changes, for the past 4 years, the vbCrLf-related issues are not present. ... .. .
    In connection with the experience I have shared above, I was just wondering whether a new property can be added to the RichTextBox control (say, "Only vbCr") so that based on its value, you can include my lines of code too in the StreamStringOut function. Thanks, Krool.

    Kind Regards.

  13. #3213
    Member
    Join Date
    Oct 2007
    Posts
    45

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    Sorry for the late reply.

    1) Tes, I can confirm that the Aug 10th update fixes the amount of text allowed issues (including where changing scrollbars would reset).

    2) Regarding the internal only CR's, it's just a giant pain - it irritates me to no end that MS made that change starting with RichEdit 2.0 without considering the ramifications of doing so. Anyway I've worked around it (in a different way to softv but similar idea - I just did the reverse where I kept the control as-is but created a string copy of the text with only CR's to use for figuring things out. Horribly inefficient but the easiest way for me to deal with with my particular situation. I do think having an option like softv mentions could be helpful.

    3) I have a new 3rd issue for you. The margin settings are set incorrectly in the CreatePrintJob sub.

    The code you have as:

    Code:
        
     .Left = PhysOffsetCX + LeftMargin
     .Right = PhysOffsetCX + PhysCX - RightMargin
     .Top = PhysOffsetCY + TopMargin
     .Bottom = PhysOffsetCY + PhysCY - BottomMargin
    should instead be

    Code:
        If (LeftMargin - PhysOffsetCX) > 0 Then
            .Left = LeftMargin - PhysOffsetCX
        Else
            .Left = PhysOffsetCX
        End If
        If (RightMargin - PhysOffsetCX) > 0 Then
            .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
        Else
            .Right = (PhysCX - .Left) - PhysOffsetCX
        End If
        If (TopMargin - PhysOffsetCY) > 0 Then
            .Top = TopMargin - PhysOffsetCY
        Else
            .Top = PhysOffsetCY
        End If
        If (BottomMargin - PhysOffsetCY) > 0 Then
            '.Bottom = (PhysCY - .Top) - (BottomMargin - PhysOffsetCY)
            .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
        Else
            '.Bottom = (PhysCY - .Top) - PhysOffsetCY
            .Bottom = PhysCY - PhysOffsetCY
        End If
    The bottom one SHOULD be the commented out lines in theory I believe where .top is subtracted also, but in practice there must be some other issue going on with the PhysCY or PhysOffsetCY that doesn't also happen with PhysCX or PhysOffsetCX because subtracting the top offset (margin) doesn't work like it does for the right offset and is only correct when NOT subtracting the top offset.

    In any event, the original margin calculations were incorrect and resulted in noticeably wrong printed margins.

    Thanks again for all your hard work with these!
    Last edited by chrislong2; Aug 17th, 2021 at 12:09 PM.

  14. #3214
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Re: CommonControls (Replacement of the MS common controls)

    VBCCR 1.7.25

    I use the ListView control (report mode) with 6 columns and need to detect double clicks on ListSubItems.

    I can do this with the function "HitTest" but all the DblClick-events dont provide the necessary X/Y coordinates for the HitTest-function.

    Can you add the missing X/Y coordinates to all DblClick-events?

  15. #3215

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Mith View Post
    VBCCR 1.7.25

    I use the ListView control (report mode) with 6 columns and need to detect double clicks on ListSubItems.

    I can do this with the function "HitTest" but all the DblClick-events dont provide the necessary X/Y coordinates for the HitTest-function.

    Can you add the missing X/Y coordinates to all DblClick-events?
    I can't due to compatibility. But it's easy doable as below code.

    Code:
    Private Declare Function GetMessagePos Lib "user32" () As Long
    
    Dim Pos As Long
    Pos = GetMessagePos()
    
    Debug.Print Get_X_lParam(Pos) & "/" & Get_Y_lParam(Pos)
    
    Public Function Get_X_lParam(ByVal lParam As Long) As Long
    Get_X_lParam = lParam And &H7FFF&
    If lParam And &H8000& Then Get_X_lParam = Get_X_lParam Or &HFFFF8000
    End Function
    
    Public Function Get_Y_lParam(ByVal lParam As Long) As Long
    Get_Y_lParam = (lParam And &H7FFF0000) \ &H10000
    If lParam And &H80000000 Then Get_Y_lParam = Get_Y_lParam Or &HFFFF8000
    End Function

  16. #3216
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    I can't due to compatibility. But it's easy doable as below code.

    Code:
    ...
    Your code doesnt work for me. The X/Y coordinates are always wrong.

    I use now the APIs GetCursorPos & ScreenToClient to get the correct X/Y coordinates!

  17. #3217

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Mith View Post
    Your code doesnt work for me. The X/Y coordinates are always wrong.

    I use now the APIs GetCursorPos & ScreenToClient to get the correct X/Y coordinates!
    It's in pixel and already in client coords.

  18. #3218
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    It's in pixel and already in client coords.
    Yes, its in pixel, same as GetCursorPos.
    But the X/Y-coordinates are wrong after multiplying the return values from your function with Screen.TwipsPerPixelX/Y.
    I only get the correct X/Y-coordinates using GetCursorPos & ScreenToClient & multiplying with Screen.TwipsPerPixelX/Y.

  19. #3219

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chrislong2 View Post
    3) I have a new 3rd issue for you. The margin settings are set incorrectly in the CreatePrintJob sub.

    The code you have as:

    Code:
        
     .Left = PhysOffsetCX + LeftMargin
     .Right = PhysOffsetCX + PhysCX - RightMargin
     .Top = PhysOffsetCY + TopMargin
     .Bottom = PhysOffsetCY + PhysCY - BottomMargin
    should instead be

    Code:
        If (LeftMargin - PhysOffsetCX) > 0 Then
            .Left = LeftMargin - PhysOffsetCX
        Else
            .Left = PhysOffsetCX
        End If
        If (RightMargin - PhysOffsetCX) > 0 Then
            .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
        Else
            .Right = (PhysCX - .Left) - PhysOffsetCX
        End If
        If (TopMargin - PhysOffsetCY) > 0 Then
            .Top = TopMargin - PhysOffsetCY
        Else
            .Top = PhysOffsetCY
        End If
        If (BottomMargin - PhysOffsetCY) > 0 Then
            '.Bottom = (PhysCY - .Top) - (BottomMargin - PhysOffsetCY)
            .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
        Else
            '.Bottom = (PhysCY - .Top) - PhysOffsetCY
            .Bottom = PhysCY - PhysOffsetCY
        End If
    The bottom one SHOULD be the commented out lines in theory I believe where .top is subtracted also, but in practice there must be some other issue going on with the PhysCY or PhysOffsetCY that doesn't also happen with PhysCX or PhysOffsetCX because subtracting the top offset (margin) doesn't work like it does for the right offset and is only correct when NOT subtracting the top offset.

    In any event, the original margin calculations were incorrect and resulted in noticeably wrong printed margins.
    Thanks for this report.
    I checked this topic and come to following formula which works on my end. Can you confirm ?

    Code:
    .Left = LeftMargin - PhysOffsetCX
    .Top = TopMargin - PhysOffsetCY
    .Right = (PhysCX - RightMargin) + PhysOffsetCX
    .Bottom = (PhysCY - BottomMargin) + PhysOffsetCY

  20. #3220

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

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Bugfix for RichTextBox done concerning wrong calculated margins in the internal CreatePrintJob method.

  21. #3221
    Member
    Join Date
    Oct 2007
    Posts
    45

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    Thanks! I am sorry for late response and I see you issued an update. Okay, first things first. In testing again today, I see that I made a stupid mistake when I was previously testing. I was actually feeding the sub swapped right and top values. So my assertion before that it was "wildly off" wasn't quite right - it was "wildly off" because I was stupid. lol

    However, the old code still was not correct. My replacement code above also was not correct - the .Right calculations in my code was wrong.

    Your new code is better, but I think there is still a mistake in the .Right and .Bottom. I believe you should be subtracting the PhysOffsetCX and PhysOffsetCY instead of adding them.

    In other words it should now be:

    Code:
        .Left = LeftMargin - PhysOffsetCX
        .Top = TopMargin - PhysOffsetCY
        .Right = (PhysCX - RightMargin) - PhysOffsetCX
        .Bottom = (PhysCY - BottomMargin) - PhysOffsetCY
    This is basically the way my old code that I've used for years was doing it.

    Note however that this code does not take into account either if the margins are less than the offsets or if the margins are not specified. I've seen printers that have .5 inch offsets (or a little less but you get the idea). This code would fail on that if they specified a margin say of .30 inches because it would give a negative number. That is why I did the If/Then's. It's not pretty, but it solves this problem. I also think you should not be setting the default values to 0. If margins aren't specified (they are optional in PrintDoc) then it's almost guaranteed not to be right. Taking everything together, I believe something like the following is probably best:

    Code:
        With .RC
        If (LeftMargin - PhysOffsetCX) > 0 Then 
             .Left = LeftMargin - PhysOffsetCX
        Else
             .Left = PhysOffsetCX
        End If
        If (TopMargin - PhysOffsetCY) > 0 Then 
             .Top = TopMargin - PhysOffsetCY
        Else
             .Top = PhysOffsetCY
        End If
        If (RightMargin - PhysOffsetCX) > 0 Then 
             .Right = (PhysCX - RightMargin) - PhysOffsetCX
        Else
             .Right = PhysCX - PhysOffsetCX
        End If
        If (BottomMargin - PhysOffsetCY) > 0 Then 
             .Bottom = (PhysCY - BottomMargin) - PhysOffsetCY
        Else
             .Bottom = PhysCY - PhysOffsetCY
        End If
        End With
    This only sets based on the margins if the margins that were set are greater than the offsets, otherwise or if no margins were set at all, will set a default.

    Thanks again for all your work with all of these!! I appreciate you! This stuff gets complicated and I think there was some wrong MS documentation/examples on this margin stuff too.

    [Edit: Updated to fix a silly mistake in my code where I originally was setting default values for RCPage and not RC]
    Last edited by chrislong2; Sep 6th, 2021 at 10:07 PM.

  22. #3222

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chrislong2 View Post
    Hi Krool,

    Thanks! I am sorry for late response and I see you issued an update. Okay, first things first. In testing again today, I see that I made a stupid mistake when I was previously testing. I was actually feeding the sub swapped right and top values. So my assertion before that it was "wildly off" wasn't quite right - it was "wildly off" because I was stupid. lol

    However, the old code still was not correct. My replacement code above also was not correct - the .Right calculations in my code was wrong.

    Your new code is better, but I think there is still a mistake in the .Right and .Bottom. I believe you should be subtracting the PhysOffsetCX and PhysOffsetCY instead of adding them.

    In other words it should now be:

    Code:
        .Left = LeftMargin - PhysOffsetCX
        .Top = TopMargin - PhysOffsetCY
        .Right = (PhysCX - RightMargin) - PhysOffsetCX
        .Bottom = (PhysCY - BottomMargin) - PhysOffsetCY
    This is basically the way my old code that I've used for years was doing it.

    Note however that this code does not take into account either if the margins are less than the offsets or if the margins are not specified. I've seen printers that have .5 inch offsets (or a little less but you get the idea). This code would fail on that if they specified a margin say of .30 inches because it would give a negative number. That is why I did the If/Then's. It's not pretty, but it solves this problem. I also think you should not be setting the default values to 0. If margins aren't specified (they are optional in PrintDoc) then it's almost guaranteed not to be right. Taking everything together, I believe something like the following is probably best:

    Code:
        With .RC
        If (LeftMargin - PhysOffsetCX) > 0 Then 
             .Left = LeftMargin - PhysOffsetCX
        Else
             .Left = PhysOffsetCX
        End If
        If (TopMargin - PhysOffsetCY) > 0 Then 
             .Top = TopMargin - PhysOffsetCY
        Else
             .Top = PhysOffsetCY
        End If
        If (RightMargin - PhysOffsetCX) > 0 Then 
             .Right = (PhysCX - RightMargin) - PhysOffsetCX
        Else
             .Right = PhysCX - PhysOffsetCX
        End If
        If (BottomMargin - PhysOffsetCY) > 0 Then 
             .Bottom = (PhysCY - BottomMargin) - PhysOffsetCY
        Else
             .Bottom = PhysCY - PhysOffsetCY
        End If
        End With
    This only sets based on the margins if the margins that were set are greater than the offsets, otherwise or if no margins were set at all, will set a default.

    Thanks again for all your work with all of these!! I appreciate you! This stuff gets complicated and I think there was some wrong MS documentation/examples on this margin stuff too.

    [Edit: Updated to fix a silly mistake in my code where I originally was setting default values for RCPage and not RC]
    According to MS (https://docs.microsoft.com/en-us/win...-edit-controls) the cxPhysOffset/cyPhysOffset is added for right/bottom. (thus correct with my new code)
    (keeping aside the extra margins which are ignored by MS, but for the principle)

    Code:
    // Set the rendering rectangle to the pintable area of the page.
    fr.rc.left   = cxPhysOffset;
    fr.rc.right  = cxPhysOffset + cxPhys;
    fr.rc.top    = cyPhysOffset;
    fr.rc.bottom = cyPhysOffset + cyPhys;

  23. #3223
    New Member
    Join Date
    Apr 2021
    Posts
    6

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    I found a problem with the FrameW control. The Caption font is not rendered properly if the application runs with GDIScaling.
    This is most notable if one uses a TrueType font as the ClearType/AntiAliasing is not working.
    I was able to narrow the problem down to the way the FrameW uses its Picture property in the DrawFrame function:
    .Cls
    Set .Picture = Nothing
    ...
    Set .Picture = .Image
    Interestingly the font is smooth if the DrawText API is used instead of the DrawThemeText version.
    I have a small test project in case you have a Windows 10 maschine...

    Also I think there are some control which leak FontHandles. The following handles are not deleted on UserControl_Terminate:
    DTPickerCalendarFontHandle
    LinkLabelUnderlineFontHandle
    ProgressBarFontHandle

    Is it possible to maybe cache fonts? As far as I understand each call to CreateGDIFontFromOLEFont creates a new font handle...
    Its not terrible but its the last place where you "waste" GID Handles.
    I think most people are using more controls than they use different fonts.
    But again most probably not worth any effort

    Thank you very much and keep up the good work

  24. #3224

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by NilsB View Post
    Also I think there are some control which leak FontHandles. The following handles are not deleted on UserControl_Terminate:
    DTPickerCalendarFontHandle
    LinkLabelUnderlineFontHandle
    ProgressBarFontHandle

    Is it possible to maybe cache fonts? As far as I understand each call to CreateGDIFontFromOLEFont creates a new font handle...
    Its not terrible but its the last place where you "waste" GID Handles.
    Hello, Thank!
    I fixed the 3 GDI leaks. It is not a good idea to cache IFont objects as the underlying hFont is not stable. Thus I need to create new font handle which is stable and can be passed to the controls.

  25. #3225
    Member
    Join Date
    Oct 2007
    Posts
    45

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Krool View Post
    According to MS (https://docs.microsoft.com/en-us/win...-edit-controls) the cxPhysOffset/cyPhysOffset is added for right/bottom. (thus correct with my new code)[/CODE]
    I understand and certainly MS is certainly the ones to generally follow for guidance, but I've seen that code before and I'm almost certain it is wrong. Adding the physical width offset to the physical width for a right margin means they are saying the printing extends into the offset area that the printer can't print. That code from MS basically says that the place to stop printing on the right is equal to the entire width PLUS the offset that the printer can't print. That's wrong - it should be subtracted from it in saying that the place to stop printing on the right is physical width (which includes the offset area) MINUS the offset so that the total area to print is only the part the printer can actually print in. Further, their code there is horrible anyway because it doesn't even take into account any margin area at all. Whoever coded that whipped that up but certainly weren't using it to actually print anything - it looks to me like a theoretical piece of code someone threw together but they certainly never used it to actually print anything. I just double-checked and the code I used for 20+ years has the offset subtracted and not added and in those 20 years I never heard anyone tell me of any printing issues. So I'm pretty sure it is supposed to be subtracted. These days, because many printers have pretty small offsets, it's probably not a huge deal either way, but I think the correct mode is to subtract. Microsoft failed. I wish they hadn't removed all their comments they used to have on their pages some years back because many times people would comment the flaws with their api or example code and those could be helpful in situations like this.

  26. #3226

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by chrislong2 View Post
    I understand and certainly MS is certainly the ones to generally follow for guidance, but I've seen that code before and I'm almost certain it is wrong. Adding the physical width offset to the physical width for a right margin means they are saying the printing extends into the offset area that the printer can't print. That code from MS basically says that the place to stop printing on the right is equal to the entire width PLUS the offset that the printer can't print. That's wrong - it should be subtracted from it in saying that the place to stop printing on the right is physical width (which includes the offset area) MINUS the offset so that the total area to print is only the part the printer can actually print in. Further, their code there is horrible anyway because it doesn't even take into account any margin area at all. Whoever coded that whipped that up but certainly weren't using it to actually print anything - it looks to me like a theoretical piece of code someone threw together but they certainly never used it to actually print anything. I just double-checked and the code I used for 20+ years has the offset subtracted and not added and in those 20 years I never heard anyone tell me of any printing issues. So I'm pretty sure it is supposed to be subtracted. These days, because many printers have pretty small offsets, it's probably not a huge deal either way, but I think the correct mode is to subtract. Microsoft failed. I wish they hadn't removed all their comments they used to have on their pages some years back because many times people would comment the flaws with their api or example code and those could be helpful in situations like this.
    explanation would be maybe that the viewport of the printer is not 0, 0. I saw some code where it actually get substracted.
    Code:
    // offset by printing offset
    printDC.SetViewportOrg (-printDC.GetDeviceCaps (PHYSICALOFFSETX),
    -printDC.GetDeviceCaps (PHYSICALOFFSETY));
    Maybe that's why in the ms doc it's added at right/bottom ?

  27. #3227
    Member
    Join Date
    Oct 2007
    Posts
    45

    Re: CommonControls (Replacement of the MS common controls)

    Hmm, maybe, tho I wonder why anyone would want to do that.

  28. #3228
    New Member
    Join Date
    Apr 2021
    Posts
    6

    Re: CommonControls (Replacement of the MS common controls)

    Hi Krool,

    do you have any news on the GDIScaling problem of the FrameW?
    I do understand you call Set .Picture = .Image because of the transparency of the frame.
    But is it not enough to call a simple Refresh to update the persistent graphics as AutoRedraw = true?
    Problem is that the GDI Scaler rescales the persistent graphics. I attached screenshots taken at 144 DPI.

    Setting the picture:
    Attachment 182284

    Calling refresh:
    Attachment 182285

    Any help would be greatly appreciated

  29. #3229
    Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    63

    VBCCR RichTextBox Issues

    Hi Krool,

    Ive been using the RichTextBox from ActiveX control Version 1.7. (win 10 64 bit)
    In the MS version of rtb i could set
    Code:
    rtb.selstart = Len(rtb.text)
    and then compare equal would be true
    Code:
    If rtb.SelStart = Len(rtb.Text) Then  '<-- = True
    however, with this rtb its behavior is different from
    the MS version.

    Ive done some investigating and it appears the Len(rtb.Text) includes CR-LF per line in length
    but rtb.SelStart doesnt not include calculations for CR-LF line endings.
    Below is a screenshot showing results of test. Would it be possible to get the same behavior as MS control?
    Regards,
    Lewis

    (not sure why its so small)
    here is link to image: https://imgur.com/a/eFrOmRB

    Name:  rtb.jpg
Views: 154
Size:  27.1 KB
    Last edited by vbLewis; Oct 10th, 2021 at 06:00 PM. Reason: clarify crlf line ending

  30. #3230

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

    Re: VBCCR RichTextBox Issues

    Quote Originally Posted by vbLewis View Post
    Hi Krool,

    Ive been using the RichTextBox from ActiveX control Version 1.7. (win 10 64 bit)
    In the MS version of rtb i could set
    Code:
    rtb.selstart = Len(rtb.text)
    and then compare equal would be true
    Code:
    If rtb.SelStart = Len(rtb.Text) Then  '<-- = True
    however, with this rtb its behavior is different from
    the MS version.

    Ive done some investigating and it appears the Len(rtb.Text) includes CR-LF per line in length
    but rtb.SelStart doesnt not include calculations for CR-LF line endings.
    I hate this quirk and it was discussed several times already.

    So, to sum up. We have SelStart and SelLength and SelText (using the EM_GETSELTEXT, rich edit message only) all ignoring CR-LF and just uses CR.
    The only "annyoing" part is the Text property which will use EM_STREAMOUT. And this EM_STREAMOUT put out CR-LF.
    So, I could "fix" the Text property by using EM_GETTEXTEX which only returns CR (unless GT_USECRLF is used).

    However, additional quirk is that EM_STREAMOUT does not output "hidden" text. This could be fixed additionally by using GT_NOHIDDENTEXT flag. (but this exists only as of rich edit version 4, thus leaving 2 and 3 in the dark...)

    So, all in all it's a shame...
    Or I replace all CR-LF to CR only within EM_STREAMOUT.. However, this would be an additional memory allocation exchange for the text.

    Edit: the MS rtb uses the v1 which uses CR+LF internally.
    Last edited by Krool; Oct 11th, 2021 at 09:41 AM.

  31. #3231
    Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    63

    Re: VBCCR RichTextBox Issues

    Quote Originally Posted by Krool View Post
    I hate this quirk and it was discussed several times already.

    So, to sum up. We have SelStart and SelLength and SelText (using the EM_GETSELTEXT, rich edit message only) all ignoring CR-LF and just uses CR.
    The only "annyoing" part is the Text property which will use EM_STREAMOUT. And this EM_STREAMOUT put out CR-LF.
    So, I could "fix" the Text property by using EM_GETTEXTEX which only returns CR (unless GT_USECRLF is used).

    However, additional quirk is that EM_STREAMOUT does not output "hidden" text. This could be fixed additionally by using GT_NOHIDDENTEXT flag. (but this exists only as of rich edit version 4, thus leaving 2 and 3 in the dark...)

    So, all in all it's a shame...
    Or I replace all CR-LF to CR only within EM_STREAMOUT.. However, this would be an additional memory allocation exchange for the text.

    Edit: the MS rtb uses the v1 which uses CR+LF internally.
    Hi Krool,
    Thanks for your reply. Sorry I wasnt aware others had brought it up already, I thought I was reporting a good bug LOL. Its fine if the behavior is an unintended consequence of upgrading to new api.
    I Fixed my problem by using API to get Text length to compare to SelStart and it works very well.

    Maybe a non-standard function like .GetTextLength(optional param,optional param) would be a solution?

    regards,
    lewis

  32. #3232

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

    Re: CommonControls (Replacement of the MS common controls)

    Ok, so EM_STREAMOUT will not respect hidden text on richedit20.dll.
    Upon Msftedit.dll it will exclude hidden text, that's why introduced GT_NOHIDDENTEXT.

    However, it is not possible to calculate via EM_GETTEXTLENGTHEX w/o hidden text as no flag exists...

    So, my conclusion will then be to not bother with GT_NOHIDDENTEXT, so that a potential new Text property will be equal with a new TextLength property..

  33. #3233
    Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    63

    Re: CommonControls (Replacement of the MS common controls)

    Krool Thanks for your insight, sorry to bother you again but this just may be something Im doing wrong....

    In the event LinkEvent(ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal LinkStart As Long, ByVal LinkEnd As Long)
    I cant seem to get the hyperlink from text using LinkStart and LinkEnd.

    Private Sub rtb_LinkEvent(ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal LinkStart As Long, ByVal LinkEnd As Long)

    Dim Link As String

    If wMsg = 514 And wParam = 0 Then
    Link = Mid$(rtb.Text, LinkStart, (LinkEnd + 1) - LinkStart)
    End If
    End Sub


    The return value 'Link' is something from a random place in the text and not even close to a hyperlink.
    Is this something Im doing wrong or is it maybe related to the hidden text problem?
    Regards,
    Lewis

  34. #3234

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by vbLewis View Post
    Krool Thanks for your insight, sorry to bother you again but this just may be something Im doing wrong....

    In the event LinkEvent(ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal LinkStart As Long, ByVal LinkEnd As Long)
    I cant seem to get the hyperlink from text using LinkStart and LinkEnd.

    Private Sub rtb_LinkEvent(ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal LinkStart As Long, ByVal LinkEnd As Long)

    Dim Link As String

    If wMsg = 514 And wParam = 0 Then
    Link = Mid$(rtb.Text, LinkStart, (LinkEnd + 1) - LinkStart)
    End If
    End Sub


    The return value 'Link' is something from a random place in the text and not even close to a hyperlink.
    Is this something Im doing wrong or is it maybe related to the hidden text problem?
    Regards,
    Lewis
    LinkStart/LinkEnd is a CharRange. Try using EM_GETTEXTRANGE.

    I tested it with sample text and the Mid$(rtb.Text, LinkStart, (LinkEnd + 1) - LinkStart) worked. So can you provide full test sample to replicate issue ?
    Last edited by Krool; Oct 13th, 2021 at 03:37 AM.

  35. #3235

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

    Re: CommonControls (Replacement of the MS common controls)

    Update released.

    Finally fixed the mismatch of the RichTextBox Text property concerning CrLf and the internal Cr only.
    The RichTextBox control now uses EM_GETTEXTEX/EM_SETTEXTEX instead of EM_STREAMOUT/EM_STREAMIN for the Text property.
    Included the UseCrLf property to control whether or not to apply GT_USECRLF/GTL_USECRLF on EM_GETTEXTEX.
    It defaults to False and thus makes a compatibility break to the previous VBCCR which used EM_STREAMOUT (always CrLf)

    Also included the TextLength property in the TextBoxW and RichTextBox control to conveniently get the length of text w/o the need of allocating memory for the Text. (like in .net)

    The OCX VBCCR17 was also updated. The internal type lib version is now 1.1.
    Code:
    Object={7020C36F-09FC-41FE-B822-CDE6FBB321EB}#1.1#0; VBCCR17.OCX

  36. #3236
    Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    63

    Re: CommonControls (Replacement of the MS common controls)

    Hi,

    Here is a sample project that reproduces the error for me. the screenshot shows the result above after clicking the highlighted link.

    Name:  ss.jpg
Views: 50
Size:  64.4 KB
    Attached Files Attached Files

  37. #3237
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Cool Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by vbLewis View Post
    Hi,
    Here is a sample project that reproduces the error for me. the screenshot shows the result above after clicking the highlighted link.
    Here is the solution for your problem:

    Name:  Screenshot - 14.10.2021 , 10_49_04.jpg
Views: 44
Size:  60.4 KB

    Code:
    Option Explicit
    
    Private Const WM_USER = &H400
    Private Const EM_GETTEXTRANGE = (WM_USER + 75)
    
    Private Declare Function SendMessageW Lib "user32" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
    
    Private Type CHARRANGE
        cpMin As Long
        cpMax As Long
    End Type
     
    Private Type TEXTRANGE
        chrg As CHARRANGE
        lpstrText As String
    End Type
     
    Private Type SETTEXTEX
        flags As Long
        codepage As Integer
    End Type
    
    
    Private Sub Form_Load()
       rtb.LoadFile App.Path & "\test.rtf", RtfLoadSaveFormatRTF, False
       rtb.SelStart = 3500
       rtb.ScrollToCaret
    '   Me.Show
    '   DoEvents
    '   MsgBox "click on nightbot links", vbInformation
    End Sub
    
    Private Sub rtb_LinkEvent(ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal LinkStart As Long, ByVal LinkEnd As Long)
        If wMsg = 514 And wParam = 0 Then
            lblLink.Caption = GetLinkText(LinkStart, LinkEnd)
        End If
    End Sub
    
    Private Function GetLinkText(ByVal LinkStart As Long, ByVal LinkEnd As Long) As String
        Dim tdCharRange As CHARRANGE
        Dim tdTextRange As TEXTRANGE
        
        tdCharRange.cpMin = LinkStart
        tdCharRange.cpMax = LinkEnd
        
        tdTextRange.chrg = tdCharRange
        tdTextRange.lpstrText = Space$(256)
        
        Call SendMessageW(rtb.hWnd, EM_GETTEXTRANGE, 0&, ByVal tdTextRange)
        GetLinkText = tdTextRange.lpstrText
        
    End Function

  38. #3238
    Member vbLewis's Avatar
    Join Date
    Feb 2009
    Location
    USA
    Posts
    63

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Mith View Post
    Here is the solution for your problem:

    Name:  Screenshot - 14.10.2021 , 10_49_04.jpg
Views: 44
Size:  60.4 KB

    Code:
    Option Explicit
    
    Private Const WM_USER = &H400
    Private Const EM_GETTEXTRANGE = (WM_USER + 75)
    
    Private Declare Function SendMessageW Lib "user32" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
    
    Private Type CHARRANGE
        cpMin As Long
        cpMax As Long
    End Type
     
    Private Type TEXTRANGE
        chrg As CHARRANGE
        lpstrText As String
    End Type
     
    Private Type SETTEXTEX
        flags As Long
        codepage As Integer
    End Type
    
    
    Private Sub Form_Load()
       rtb.LoadFile App.Path & "\test.rtf", RtfLoadSaveFormatRTF, False
       rtb.SelStart = 3500
       rtb.ScrollToCaret
    '   Me.Show
    '   DoEvents
    '   MsgBox "click on nightbot links", vbInformation
    End Sub
    
    Private Sub rtb_LinkEvent(ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal LinkStart As Long, ByVal LinkEnd As Long)
        If wMsg = 514 And wParam = 0 Then
            lblLink.Caption = GetLinkText(LinkStart, LinkEnd)
        End If
    End Sub
    
    Private Function GetLinkText(ByVal LinkStart As Long, ByVal LinkEnd As Long) As String
        Dim tdCharRange As CHARRANGE
        Dim tdTextRange As TEXTRANGE
        
        tdCharRange.cpMin = LinkStart
        tdCharRange.cpMax = LinkEnd
        
        tdTextRange.chrg = tdCharRange
        tdTextRange.lpstrText = Space$(256)
        
        Call SendMessageW(rtb.hWnd, EM_GETTEXTRANGE, 0&, ByVal tdTextRange)
        GetLinkText = tdTextRange.lpstrText
        
    End Function
    Mith, thank you so much!

    just curious... Is that return text a C string or a com allocated string? wondering if sysallocatestring should be used on it?
    Edit: nevermind i see you allocated it with space()
    Last edited by vbLewis; Oct 14th, 2021 at 12:11 AM.

  39. #3239
    Addicted Member Mith's Avatar
    Join Date
    Jul 2017
    Location
    Thailand
    Posts
    185

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by vbLewis View Post
    Mith, thank you so much!

    just curious... Is that return text a C string or a com allocated string? wondering if sysallocatestring should be used on it?
    Edit: nevermind i see you allocated it with space()
    Maybe you should use Space(1024) and Trim(tdTextRange.lpstrText) for long URLs.

  40. #3240

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

    Re: CommonControls (Replacement of the MS common controls)

    Quote Originally Posted by Mith View Post
    Maybe you should use Space(1024) and Trim(tdTextRange.lpstrText) for long URLs.
    Or use LinkEnd - LinkStart to allocate just enough space.

Page 81 of 82 FirstFirst ... 31717879808182 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