Announcement

Collapse
No announcement yet.

Desktop Bleed Through

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

  • Dave Biggs
    replied
    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.

    Leave a comment:


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

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

    Leave a comment:


  • Gary Beene
    replied
    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.

    Leave a comment:


  • Gary Beene
    replied
    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.

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • Mannish Bhandari
    replied
    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?

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • Dave Biggs
    replied
    Oops, tested this version on my Win10 system..
    '
    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", 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
    '

    Leave a comment:


  • Gary Beene
    replied
    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

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • Dave Biggs
    replied
    Originally posted by Gary Beene View Post
    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..
    '
    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
    '

    Leave a comment:


  • Stuart McLachlan
    replied
    Originally posted by Dale Yarker View Post
    . 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.

    '
    Code:
    #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
    '

    Leave a comment:


  • Dale Yarker
    replied
    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,

    Leave a comment:


  • Stuart McLachlan
    replied
    Originally posted by Dale Yarker View Post
    (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)

    Leave a comment:


  • Dale Yarker
    replied
    (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,

    Leave a comment:


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

    Leave a comment:


  • Rodney Hicks
    replied
    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. .

    Leave a comment:


  • Stuart McLachlan
    replied
    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.

    Leave a comment:


  • Gary Beene
    replied
    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.

    Leave a comment:


  • Stuart McLachlan
    replied
    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)



    Leave a comment:

Working...
X