Desktop Bleed Through

[Gary Beene]

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.

#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

[Dave Biggs]

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

[Gary Beene]

Howdy, Dave!

Thanks for the reply.

Do you mean something like this ...

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.

[Dave Biggs]

Hi Gary,

Yes that's what I had in mind..

   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

[Borje Hagsten]

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.

[Gary Beene]

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.

[Gary Beene]

Howdy David/Borje!

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

However, in my main app I tried replacing this:

 %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.

 %WS_Popup

Then, I tried using these and saw no bleedthrough.

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

[Gary Beene]

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.

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.

[Dave Biggs]

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 ??

[Gary Beene]

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!

[Gary Beene]

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.

#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

[Rodney Hicks]

From here:

https://docs.microsoft.com/en-us/windows/win32/controls/create-rich-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.

[Gary Beene]

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

#Resource Manifest, 1, "xptheme.xml"

<?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>

[Rodney Hicks]

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.

[Stuart McLachlan]

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)

[Gary Beene]

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.

[Stuart McLachlan]

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/user-to-user-discussions/powerbasic-for-windows/751775-how-to-place-tooltips-on-column-headers-in-a-listview?p=751798#post751798

and the two before it.

[Rodney Hicks]

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. .

[Gary Beene]

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

[Dale Yarker]

(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,