Desktop Bleed Through

[Dave Biggs]

The distracting thing about that statement is that I've used a RichEdit for years now with GUI changes under WM_InitDialog, with nary an occasion of bleed through. I can't reconcile why I see it now and did not see it in my apps from the last several years.

Hi Gary,

The bleed through effect displayed by Post #11 does not occur on Win7 64Bit.

It seems that there must have been differences in the way that Desktop Windows Management handles presentation to screen, introduced in more recent Win10 systems.

[Mannish Bhandari]

Thanks Gary, does the additional code in post #27 as shown below
actually did the trick to prevent the bleeding?

     CASE %WM_INITDIALOG
          DIALOG POST hDlg, %WM_App+500,0,0

      CASE %WM_App+500
           CONTROL NORMALIZE hDlg, %IDC_RichEdit

what I can see is that it normalize or refreshes the display of the richedit control?

It goes through a cycle of hide then normalize the richedit control which can be weird ?

[Gary Beene]

Howdy, Dave!

In my tests, when using the Hide/Normalize approach that you suggest in #27, the Font New and Control Set Font can be located in PBMain or under WM_Initdialog. Both locations result in no bleed through.

Do you see that as well?

The big picture seems to be that when the RichEdit GUI settings are changed before the control is visible, that the bleeding can occur and post-visibility code can remove the bleeding.

The distracting thing about that statement is that I've used a RichEdit for years now with GUI changes under WM_InitDialog, with nary an occasion of bleed through. I can't reconcile why I see it now and did not see it in my apps from the last several years.

Even though this also works, the Hide/Normalize approach gives less of a flicker on startup.

. Scrolling the RichEdit will cause the bleed through to go away (correctly redraw the RichEdit control).

Thanks for your help and suggestions on this! I will still go look at prior code I've written to try and figure out what I'm getting the problem now but did not get the problem in the past.

[Gary Beene]

Howdy, Mannish!

Read post #1 to see the problem we're trying to solve - the desktop is bleeding through the new dialog (part of the desktop is displayed within the boundary of the dialog). The recent code examples are trying to understand what causes the bleedthrough and how to stop it from happening.

[Rodney Hicks]

Compare the code in post #1 to the code in post #27. You should see the difference. I don't think it matters what font is used in the post #27 code.

[Mannish Bhandari]

I am figuring out what the post #27 by Dave is trying to do? say if I change the fonts from Arial to Tahoma?
What's the purpose of this prog ? What is bleeding?

[Rodney Hicks]

Well done, Dave!

Gary, there are some variable width fonts that worked with prior to Dave's solution. @Microsoft JhengHei UI was one. Really odd issue, I was getting a light blue background on some of the fonts that failed, yet there was nothing about colours in the code.

[Dave Biggs]

Oops, tested this version on my Win10 system..
'

#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
        Font New "Arial", 96, 1 To hFont
        Control Set Font GetParent(hRichEdit), %IDC_RichEdit, hFont
      Control Hide hDlg, %IDC_RichEdit
    Dialog Show Modal hDlg Call DlgProc
End Function
 
CallBack Function DlgProc() As Long
   Select Case As Long Cb.Msg
      Case %WM_InitDialog  : Dialog Post hDlg, %WM_App+500,0,0
      Case %WM_App+500     : Control Normalize hDlg, %IDC_RichEdit
      Case %WM_ContextMenu : Dialog End hDlg
      Case %WM_Command     : If Cb.Ctl = %IdCancel Then Dialog End hDlg
   End Select
End Function
'

[Gary Beene]

Howdy, Dave!
With your code of #24, I still get bleed through.

Howdy, Rodney!
So, it appears to affect only variable character width fonts?
Lucida Console - no bleed
Tahoma - bleed
Arial Black - bleed
Times New Roman - bleed
Courier New - no bleed

[Rodney Hicks]

Dave, I still get the see through effect with your code. But if I change from Arial to Lucida Console there is no see through at a size of 96.

[Dave Biggs]

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

Hi Gary,
As a general rule you should not include code which changes the GUI during %WM_INITDIALOG as the screen presentation is still being constructed at that stage.
Try this version of your 'Bleeding' (not rude!) 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
      Font New "Arial Black", 96, 1 To hFont
      Control Set Font GetParent(hRichEdit), %IDC_RichEdit, hFont
 '      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
      Case %WM_ContextMenu : Dialog End hDlg
      Case %WM_Command     : If Cb.Ctl = %IdCancel Then Dialog End hDlg
   End Select
End Function
'

[Stuart McLachlan]

. I have a vague memory (40% chance of real) of having to put back InitCommonControlsEx for "less common" common controls like MONTH CALEDAR. (And that might have been PBForms 1.x under PBWin 8 versus current PBForms 2 under PBWin 10)

We'll just have to see if it helps Gary.

Stripped down version of Calendar from Samples. Uses Month Calendar. No includes, no InitCommonCOntrols(ex), runs fine for me.

'

#COMPILER PBWIN 10
#COMPILE EXE
#DIM ALL
#RESOURCE MANIFEST, 1, "XPTheme.xml"

%MCN_FIRST               = 0-746       ' monthcal
%MCN_SELCHANGE       = %MCN_FIRST - 3
%MCM_FIRST = &H1000
%MCM_SETMAXSELCOUNT  = %MCM_FIRST + 4
%MCS_MULTISELECT      = &H0002
%WM_SYSCOLORCHANGE           = &H0015
%WM_WININICHANGE             = &H001A

TYPE SYSTEMTIME
    wYear         AS WORD
    wMonth        AS WORD
    wDayOfWeek    AS WORD
    wDay          AS WORD
    wHour         AS WORD
    wMinute       AS WORD
    wSecond       AS WORD
    wMilliseconds AS WORD
END TYPE

TYPE NMSELCHANGE
    hdr        AS NMHDR       ' this must be first, so we don't break WM_NOTIFY
    stSelStart AS SYSTEMTIME
    stSelEnd   AS SYSTEMTIME
END TYPE
'------------------------------------------------------------------------------
' Equates
'------------------------------------------------------------------------------
%IDC_LABEL    = %WM_USER + 2048
%IDC_CALENDAR = %WM_USER + 2049

'------------------------------------------------------------------------------
' Return the name of a given month number
'------------------------------------------------------------------------------
FUNCTION GetMonthName (BYVAL Month AS LONG) AS WSTRING

    FUNCTION = READ$(Month)

    DATA "January", "February", "March", "April", "May", "June", "July"
    DATA "August", "September", "October", "November", "December"

END FUNCTION

'------------------------------------------------------------------------------
' Main callback
'------------------------------------------------------------------------------
CALLBACK FUNCTION DlgProc

    LOCAL pNMSC   AS NMSELCHANGE PTR
    LOCAL DateStr AS WSTRING

    SELECT CASE CB.MSG

        CASE %WM_COMMAND
            ' The use selected the CLOSE button
            IF CBCTL = %IDCANCEL THEN DIALOG END CB.HNDL, 0

        CASE %WM_NOTIFY
            ' Set up the NMSELCHANGE pointer passed in CB.LPARAM
            pNMSC = CB.LPARAM

            ' Detect changes in the calendar control
            IF @pNMSC.hdr.code = %MCN_SELCHANGE THEN ' Get selected date/time
                ' Here we use an international date format, just to show how it works
                ' Tip: in a database, we can use these values to get stored
                ' data related to the selected date..

                DateStr = GetMonthName(@pNMSC.stSelStart.wMonth) _
                                + STR$(@pNMSC.stSelStart.wDay)   + ", " _
                                + STR$(@pNMSC.stSelStart.wYear)
                DateStr = "Selected date: " + DateStr _
                        + "    (Right click for popup menu...)"

                CONTROL SET TEXT CB.HNDL, %IDC_LABEL, DateStr
            END IF

        CASE %WM_SYSCOLORCHANGE, %WM_WININICHANGE
            ' If user changes system settings (color, etc), forward the change
            ' notification message to the Calendar control
            CONTROL SEND CB.HNDL, %IDC_CALENDAR, CB.MSG, CB.WPARAM, CB.LPARAM

    END SELECT

END FUNCTION


'------------------------------------------------------------------------------
' Main entry point for the application
'------------------------------------------------------------------------------
FUNCTION PBMAIN () AS LONG

    LOCAL hDlg AS DWORD
    DIALOG NEW %HWND_DESKTOP, "Calendar demo",,, 400, 232, %WS_SYSMENU TO hDlg

    CONTROL ADD LABEL,  hDlg, %IDC_LABEL,  "Select a date.",  8,  8, 280,  14
    CONTROL ADD BUTTON, hDlg, %IDCANCEL,   "&Close",        340,  6,  50,  14
    CONTROL ADD "SysMonthCal32", hDlg, %IDC_CALENDAR, "",     0, 26, 396, 190, _
        %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP OR %MCS_MULTISELECT, _
        %WS_EX_CLIENTEDGE

    ' Enable selection of up to 31 days.
    ' See COMMCTRL.INC for other useful messages, equates and Type structures
    CONTROL SEND hDlg, %IDC_CALENDAR, %MCM_SETMAXSELCOUNT, 31, 0

    DIALOG SHOW MODAL hDlg CALL DlgProc

END FUNCTION
'

[Dale Yarker]

Could be. But when did Bob leave in anything that might slow run time, increase exe size or slow compile time?

I have also removed all trace of PBforms (including InitCommonControlsEx) and not having a problem with "simple" common controls like TEXTBOX and BUTTONs. I have a vague memory (40% chance of real) of having to put back InitCommonControlsEx for "less common" common controls like MONTH CALEDAR. (And that might have been PBForms 1.x under PBWin 8 versus current PBForms 2 under PBWin 10)

We'll just have to see if it helps Gary.

Cheers,

[Stuart McLachlan]

(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

I suspect the PBForms InitCommonControls(Ex) is an unnecessary legacy statement with recent PBWIn versions. Try commenting it out

FWIW, when I use PBForms to design dialogs, which I do frequently, I never save back into PBEdit. I just do a "View DDT code" and copy/paste the relevant DIALOG and CONSTANTS sections. I never use any of the other #PBFORMS blocks - including the #PBFOORMS INCLUDE block

And frequently I don't have ANY include files.

IOW I never have any InitCommonControls(Ex) statements, yet I've never experienced any problems.

and the includes for both PBWin 9 and 10 have DECLAREs for InitCommonControlsEx not InitCommonControls (no Ex).

It's in CommCtrl.inc (Line 61)

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

[Gary Beene]

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

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

[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/u...798#post751798

and the two before it.

[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]

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)