Announcement

Collapse
No announcement yet.

Desktop Bleed Through

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

  • #21
    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)

    Comment


    • #22
      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,
      Dale

      Comment


      • #23
        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
        '

        Comment


        • #24
          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
          '
          Rgds, Dave

          Comment


          • #25
            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.
            Rod
            In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

            Comment


            • #26
              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

              Comment


              • #27
                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
                '
                Rgds, Dave

                Comment


                • #28
                  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.
                  Rod
                  In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                  Comment


                  • #29
                    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?

                    Comment


                    • #30
                      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.
                      Rod
                      In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                      Comment


                      • #31
                        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.

                        Comment


                        • #32
                          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.

                          Comment


                          • #33
                            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 ?

                            Comment


                            • #34
                              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.
                              Rgds, Dave

                              Comment

                              Working...
                              X