Announcement

Collapse
No announcement yet.

Desktop Bleed Through

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Desktop Bleed Through

    When starting an app of mine, I sometimes get bleed through of the underlying desktop - where a rectangle of the desktop appears in the RichEdit. Scrolling the RichEdit will cause the bleed through to go away (correctly redraw the RichEdit control).

    It does not happen every time - only occasionally.

    The code below is pretty much what I use in the app, but the code below will not duplicate the bleed-through. It's hard to test fixes because the problem doesn't happen repeatedly.
    Code:
    #Include "win32api.inc"
    %MultiLineREStyle_Wrap    = %WS_Child Or %WS_ClipSiblings Or %WS_Visible Or %ES_MultiLine Or %WS_VScroll Or %ES_AutoVScroll Or %ES_WantReturn Or %ES_NoHideSel Or %WS_TabStop Or %ES_SaveSel
    %IDC_RichEdit = 500
    Global hDlg, hRichEdit As Dword
    
    Function PBMain()
       Dialog Default Font "Arial Bold", 32, 1
       Dialog New Pixels, 0, "Bleed Test",0,0,1920,1080, %WS_Popup Or %WS_ClipSiblings Or %WS_ClipChildren To hDlg
       LoadLibrary("msftedit.dll")
       Control Add "RichEdit50W", hDlg, %IDC_RichEdit, "Bleed Test",10,10,1900,1060, %MultiLineREStyle_Wrap, %WS_Ex_ClientEdge
       Dialog Show Modal hDlg Call DlgProc
    End Function
    
    CallBack Function DlgProc() As Long
       Select Case Cb.Msg
          Case %WM_ContextMenu : Dialog End hDlg
          Case %WM_Command     : If Cb.Ctl = %IdCancel Then Dialog End hDlg
       End Select
    End Function

  • #2
    You could try hiding the app until it has finished initializing, show by posting a message at the end of %WM_INITDIALOG ?
    Rgds, Dave

    Comment


    • #3
      Howdy, Dave!

      Thanks for the reply.

      Do you mean something like this ...

      Code:
      Dialog New ...
      Dialog Hide hDlg
      
      then  under WM_InitDialog ...
      Dialog Post hDlg, %WM_User+500,0,0
      
      Case %WM_User+500
         Dialog Normalize
      I did try posting and using Dialog Redraw hDlg under %WM_User+500, but as best I could tell, that did not have the desired result.

      Comment


      • #4
        Hi Gary,

        Yes that's what I had in mind..
        Code:
           Dialog Hide hDlg
           Dialog Show Modal hDlg Call DlgProc
        End Function
        
        CallBack Function DlgProc() As Long
           Select Case Cb.Msg
              Case %WM_InitDialog  : Dialog Post hDlg, %WM_User+500,0,0
              Case %WM_User+500    : Dialog Redraw hDlg : Dialog Normalize hDlg
        Rgds, Dave

        Comment


        • #5
          Does it happen when you switch between apps? Then you maybe could try redraw / refresh RichEdit under %WM_Activate or %WM_NcActivate. Oh, I now see you meant at startup. Maybe dialog post to %WM_User+500 and do CONTROL REDRAW on RichEdit instead. Sometimes I have had to use one or more DOEVENTS to finalize things properly at end of such places.

          Comment


          • #6
            Howdy, Borge!

            Thanks for the comment!

            I've never seen the problem before, so I was a bit surprised. Plus, I've used very similar code on multiple apps. So I'm guessing that my latest app has added a new "feature"!

            I'll try both Dave's and your suggestions this evening when I have time to play with it. Since it won't fail on demand, it's hard to judge the effect of code changes.

            ... added ... actually, I open my main app dialog first - it has no RichEdit. It's when I open a child dialog that has a RichEdit that the bleed through occurs.

            Comment


            • #7
              Howdy David/Borje!

              I tried both of your suggestions and still got the bleed through.

              However, in my main app I tried replacing this:

              Code:
               %WS_Popup Or %WS_ClipChildren Or %WS_ClipSiblings
              ... with just this and the bleed through went away. I had seem some flickering on startup, hence the use of ClipChildren and ClipSIblings.

              Code:
               %WS_Popup
              Then, I tried using these and saw no bleedthrough.

              Code:
              WS_SysMenu Or %WS_ClipChildren Or %WS_ClipSiblings
              %WS_OverlappedWIndow Or %WS_ClipChildren Or %WS_ClipSiblings
              I did a bit of searching on the web but did not find any mention that %WS_Popup could not be used with %WS_ClipChildren or %WS_ClipSiblings

              Comment


              • #8
                This combination, redrawing both RichEdit and Dialog under %WM_User seems to eliminate the bleedthrough.

                I am still not clear on why there is any bleedthrough in the first place.

                Code:
                Dialog Post hDlg, %WM_User+500, 0, 0
                
                Case %WM_User+500
                   Control ReDraw hDlg, %IDC_RichEdit
                   Dialog ReDraw hDlg

                Scrolling the RichEdit will cause the bleed through to go away
                While scrolling works (as I mentioned in #1), this two-line Redraw doesn't introduce as much flicker on startup.

                Comment


                • #9
                  I am still not clear on why there is any bleedthrough in the first place
                  Something to do with the child dialog sharing the main Dialog Message loop and getting a lower priority for redraws and so on ??
                  Rgds, Dave

                  Comment


                  • #10
                    Howdy, Dave!

                    Well, since I've used similar code for years now, without seeing any bleeding, then I assume its something I've done differently. I'll continue to look at it until the difference bleeds through to my brain!

                    Comment


                    • #11
                      Well, well, well! I bumped up the font size and the bleed through appears!

                      ... added ... there seems to be some correlation to the amount of text. With one line of text the bleed through does not appear. but with many lines of text the bleed through does appear. Not sure of any exact size that triggers the effect.

                      Code:
                      #Include "win32api.inc"
                      %MultiLineREStyle_Wrap    = %WS_Child Or %WS_ClipSiblings Or %WS_Visible Or %ES_MultiLine Or %WS_VScroll Or %ES_AutoVScroll Or %ES_WantReturn Or %ES_NoHideSel Or %WS_TabStop Or %ES_SaveSel
                      %IDC_RichEdit = 500
                      Global hDlg, hRichEdit, hFont As Dword
                      
                      Function PBMain()
                         Dialog Default Font "Arial Bold", 72, 1
                         Dialog New Pixels, 0, "Bleed Test",0,0,1920,1080, %WS_Popup Or %WS_ClipSiblings Or %WS_ClipChildren To hDlg
                         LoadLibrary("msftedit.dll")
                         Control Add "RichEdit50W", hDlg, %IDC_RichEdit, Repeat$(25,"Bleed Test one more time!"+$CrLf),10,10,1900,1060, %MultiLineREStyle_Wrap, %WS_Ex_ClientEdge
                         Control Handle hDlg, %IDC_RichEdit To hRichEdit
                         Dialog Show Modal hDlg Call DlgProc
                      End Function
                      
                      CallBack Function DlgProc() As Long
                         Select Case Cb.Msg
                            Case %WM_InitDialog
                               Font New "Arial Black", 96, 1 To hFont
                               Control Set Font GetParent(hRichEdit), %IDC_RichEdit, hFont
                            Case %WM_ContextMenu : Dialog End hDlg
                            Case %WM_Command     : If Cb.Ctl = %IdCancel Then Dialog End hDlg
                         End Select
                      End Function

                      Comment


                      • #12
                        From here:
                        https://docs.microsoft.com/en-us/win...-edit-controls

                        o use visual styles with these controls, an application must include a manifest and must call the InitCommonControls function at the beginning of the program.
                        Rod
                        In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                        Comment


                        • #13
                          Howdy, Rodney!
                          Thanks for the suggestion, but even with a manifest, the bleed through occurs. And as I recall, PBWin handles calling InitCommonControls.

                          Code:
                          #Resource Manifest, 1, "xptheme.xml"
                          Code:
                          <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
                          <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
                          <assemblyIdentity
                              version="1.0.0.0"
                              processorArchitecture="*"
                              name="PowerBASIC EXE"
                              type="win32"
                          />
                          <description>PowerBASIC Application</description>
                          <dependency>
                              <dependentAssembly>
                                  <assemblyIdentity
                                      type="win32"
                                      name="Microsoft.Windows.Common-Controls"
                                      version="6.0.0.0"
                                      processorArchitecture="*"
                                      publicKeyToken="6595b64144ccf1df"
                                      language="*"
                                  />
                              </dependentAssembly>
                          </dependency>
                          </assembly>

                          Comment


                          • #14
                            I'm not sure that PBWin handles calling the InitCommonControls, where did you see that? PBForms handles calling but I don't think the compiler does.
                            Rod
                            In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                            Comment


                            • #15
                              https://docs.microsoft.com/en-us/win...commoncontrols

                              Registers and initializes certain common control window classes. This function is obsolete. New applications should use the InitCommonControlsEx function.
                              ...
                              Under Comctl32.dll version 5.x, only Windows 95 classes (ICC_WIN95_CLASSES) can be registered through InitCommonControls. Programs which require additional common control classes must use the InitCommonControlsEx function.
                              Under Comctl32.dll version 6.0 and later, InitCommonControls does nothing. Applications must explicitly register all common controls through InitCommonControlsEx.

                              Interestingly, I haven't put either in any PB application for years and haven't come across any issues (which implies that PB does it for you)



                              Comment


                              • #16
                                Howdy, Stuart!
                                Yep, same here. I'm looking for where I read that the call was not necessary. Without raising ghosts, I seem to recall that it was in a post or email from Bob Zale.

                                Comment


                                • #17
                                  Originally posted by Gary Beene View Post
                                  Howdy, Stuart!
                                  Yep, same here. I'm looking for where I read that the call was not necessary. Without raising ghosts, I seem to recall that it was in a post or email from Bob Zale.
                                  Since DDT uses lots of common controls "under the hood", I'd guess that it is done automagically.

                                  Closest to a reference I can find is this post
                                  https://forum.powerbasic.com/forum/u...798#post751798

                                  and the two before it.

                                  Comment


                                  • #18
                                    InitCommonControlSEX, perhaps it's impotent.

                                    Well, considering that PBWin is several years old, I thought that that might be applicable. Having said that, subsequent changes may have affected the performance thereof.
                                    Failing that, perhaps one of the styles used is causing an issue. Specifically, %ES_SaveSel. A different problem rears its head when it is removed, on my machine at least.

                                    I had to put #INCLUDE "RichEdit.inc" in to get it to work at all, which makes me think you're using J.Roca's includes, which also means I might be wasting your time with my thoughts. .
                                    Rod
                                    In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                                    Comment


                                    • #19
                                      Howdy, Rodney!
                                      Yep. Jose includes. My apologies for not including that in the posted code.

                                      Comment


                                      • #20
                                        (just EWAG here) If PBWin did it "automagically", then PBForms would not have to.

                                        PBForms does call InitCommonControlsEx by way of macro in PBForms.inc ; and the includes for both PBWin 9 and 10 have DECLAREs for InitCommonControlsEx not InitCommonControls (no Ex).

                                        Cheers,
                                        Dale

                                        Comment

                                        Working...
                                        X