New FWH 11.07

[Maurizio]

Antonio and Rao

Say and groups works correctly . Thanks.

Now I have another anomaly with folder
when I use oFld:setoption(2) the focus remain in in folder 1

I modify the foldxbrw.prg in samples adding :

oBrw1:aCols[ 2 ]:bEditBlock := { || oFld:SetOption(2) }

After click on the colum and switch in folder 2 try the arrows key , doesn't work because the focus remain on folder .

Regards Maurizio

Code: Select all

#include "FiveWin.ch" 
#include "XBrowse.ch" 

function Main() 

   local oDlg, oFld, oBrw1, oBrw2 
   local aDat1, aDat2 

   aDat1:={{"Row1-Col1","Row1-Col2","Row1-Col3"},; 
                 {"Row2-Col1","Row2-Col2","Row2-Col3"},; 
                 {"Row3-Col1","Row3-Col2","Row3-Col3"},; 
                 {"Row4-Col1","Row4-Col2","Row4-Col3"}} 

   aDat2:={{"ROW1-COL1","ROW1-COL2","ROW1-COL3"},; 
                 {"ROW2-COL1","ROW2-COL2","ROW2-COL3"},; 
                 {"ROW3-COL1","ROW3-COL2","ROW3-COL3"},; 
                 {"ROW4-COL1","ROW4-COL2","ROW4-COL3"}} 

   DEFINE DIALOG oDlg RESOURCE "Test" 
   

   REDEFINE FOLDER oFld ; 
      PROMPTS "One", "Two" ; 
      DIALOGS "One", "Two" ; 
      ID 100 OF oDlg 

   REDEFINE XBROWSE oBrw1 ID 10 OF oFld:aDialogs[ 1 ] ARRAY aDat1 AUTOCOLS 

   REDEFINE XBROWSE oBrw2 ID 10 OF oFld:aDialogs[ 2 ] ARRAY aDat2 AUTOCOLS 

   oBrw1:aCols[ 2 ]:nEdittype := EDIT_BUTTON
   oBrw2:aCols[ 2 ]:nEdittype := EDIT_GET 

   oBrw1:aCols[ 2 ]:bEditBlock := { ||  oFld:SetOption(2) }
   

   ACTIVATE DIALOG oDlg CENTERED 

return nil

[nageswaragunupudi]

Mr Maurizio

This would not work in FWH 11.5 either. We can not treat this as a new issue created by the new versions.

Well. this can not be done from within oCol:bEditBlock, now or before. After execution of bEditBlock, control goes back to the calling browse. Because the dialog is a non-modal one, the control immediately goes back to oBrw1 which is hidden.

[nageswaragunupudi]

Antonio, the bolder and bolder-effect from the says comes in all cases, when the dialog is refreshed with oDlg:refresh(.F.). But only > XP. Try in a normal dialog with a button a call from oDlg:refresh(.F.) and you see the effect!

I tried on Windows 7 32 bits version. I am not able to reproduce this problem. This is the code.

Code: Select all

#include "fivewin.ch"

function Main()

   local oDlg, oBrush

//   DEFINE BRUSH oBrush COLOR CLR_YELLOW
   DEFINE BRUSH oBrush FILE "c:\fwh\bitmaps\backgrnd\browback.bmp"

   DEFINE DIALOG oDlg BRUSH oBrush TRANSPARENT

   @ 10,10 SAY "This is a text message" SIZE 100,10 PIXEL OF oDlg
   @ 30,10 BUTTON "Refresh(.f.)" SIZE 50,12 PIXEL OF oDlg ACTION oDlg:Refresh(.f.)

   ACTIVATE DIALOG oDlg CENTERED

   RELEASE BRUSH oBrush

return nil
 

I have tried with both color and bitmap brushes.
Can you please help me to reproduce the problem with a small sample code?

[Antonio Linares]

Rao,

samples\Testfx8.prg, click on the checkbox and the below SAYs will overpaint.

The same code, using TFolder instead of TFolderEx does not overpaint. Can't find the reason yet...

[nageswaragunupudi]

Rao,

samples\Testfx8.prg, click on the checkbox and the below SAYs will overpaint.

The same code, using TFolder instead of TFolderEx does not overpaint. Can't find the reason yet...

First thing I want to ensure that says are never overpainted in any case except TFolderEx. Can this be taken as confirmed? If so we can look for the reasons in TFolderEx. But it appears from mr. byte-ones' posting that oDlg:Refresh( .f. ) overpaints says on any dialog ( if OS is above WinXP. i.e, Vista or Win7 ).

My advise is that let us first clear up the issue in all cases except tFolderEx.

[nageswaragunupudi]

Rao,

samples\Testfx8.prg, click on the checkbox and the below SAYs will overpaint.

The same code, using TFolder instead of TFolderEx does not overpaint. Can't find the reason yet...

Incidentally byte-one's point about refresh(.f.) may be considered.
In the above testfx8.prg, please change the action for click me button like this.

Code: Select all

    REDEFINE BUTTON oBtn ID 1002 OF oFld1:aDialogs[1];
          ACTION oFld1:aDialogs[ 1 ]:Refresh( .f. )
 

When we click on the button, the action Refresh( .f. ) results in bold text of the say.

Please see this code in Control class:

Code: Select all

      case nMsg == WM_LBUTTONDOWN
           if ::lTransparent .and. ( ::IsKindOf( "TRADIO" ) .or. ::IsKindOf( "TCHECKBOX" ) )
              ::oWnd:Refresh( .f. )
           endif
           return ::LButtonDown( nHiWord( nLParam ), nLoWord( nLParam ), nWParam )

      case nMsg == WM_LBUTTONUP
           if ::lTransparent .and. ( ::IsKindOf( "TRADIO" ) .or. ::IsKindOf( "TCHECKBOX" ) )
//              ::oWnd:Refresh( .f. )   // EMG commented out to avoid flicker
           endif
           return ::LButtonUp( nHiWord( nLParam ), nLoWord( nLParam ), nWParam )
 

Mr. byte-one says if we comment out ::oWnd:Refresh( .f. ), the problem is gone.

What does this Refresh( .f. ) do and does this create problem in TFolderEx only or any other dialog also.

[Enrico Maria Giordano]

I think we cannot go anywhere without a little sample showing the problem.

EMG

[byte-one]

EMG, please make yourself a simple dialog (transparent) with a button that call the action oDlg:refresh(.f.) and a say with redefine and a say with a static text (only defined in the RC-file). Then click on the button and you see, that the say(s) become bolder and bolder with every click on the button!

[nageswaragunupudi]

I confirm this. Mr byte-one also said that this can be seen only on vista and win7, but not on xp.

sample code:

Code: Select all

#include "fivewin.ch"

function Main()

   local oDlg, oFont, oSay
   local lVar  := .t.

   DEFINE FONT oFont NAME 'TAHOMA' SIZE 0,-12
   DEFINE DIALOG oDlg RESOURCE "TESTDLG" FONT oFont TRANSPARENT

   REDEFINE SAY oSay PROMPT "SECOND LINE" ID 4002 OF oDlg

   REDEFINE BUTTON ID 4009 OF oDlg ACTION oDlg:Refresh( .f. ) //lVar := ! lVar )

   ACTIVATE DIALOG oDlg CENTERED

return nil
 

rc file

Code: Select all

LANGUAGE LANG_ENGLISH,SUBLANG_ENGLISH_US

TESTDLG DIALOG DISCARDABLE 6, 18, 266, 134
STYLE WS_POPUP|DS_MODALFRAME|WS_CAPTION|WS_SYSMENU|WS_VISIBLE
CAPTION "Dialog"
{
  CONTROL "OK", IDOK, "Button", WS_TABSTOP, 148, 108, 45, 15
  CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 204, 108, 45, 15
  CONTROL "This is some static text", 4001, "Static", WS_GROUP, 12, 12, 100, 12, WS_EX_TRANSPARENT
  CONTROL "Second Line Static Text", 4002, "Static", WS_GROUP, 12, 32, 100, 12, WS_EX_TRANSPARENT
  CONTROL "Sample Check Box", 4003, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 116, 16, 92, 12, WS_EX_TRANSPARENT
  CONTROL "Second Check Box", 4004, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 116, 40, 92, 12, WS_EX_TRANSPARENT
  CONTROL "Radio-1", 4005, "Button", BS_AUTORADIOBUTTON, 124, 60, 56, 10, WS_EX_TRANSPARENT
  CONTROL "Radio-2", 4006, "Button", BS_AUTORADIOBUTTON, 124, 80, 56, 10, WS_EX_TRANSPARENT
  CONTROL "Inside Group", 4007, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 20, 68, 80, 16, WS_EX_TRANSPARENT
  CONTROL "This is a Group", 4008, "Button", BS_GROUPBOX, 8, 56, 92, 44, WS_EX_TRANSPARENT
  CONTROL "Test", 4009, "Button", WS_TABSTOP, 12, 108, 50, 14
}
 

[Rick Lipkin]

Rao

Just curious .. what resource editor did you use to create this .rc ?

Thanks
Rick Lipkin

Code: Select all

LANGUAGE LANG_ENGLISH,SUBLANG_ENGLISH_US

TESTDLG DIALOG DISCARDABLE 6, 18, 266, 134
STYLE WS_POPUP|DS_MODALFRAME|WS_CAPTION|WS_SYSMENU|WS_VISIBLE
CAPTION "Dialog"
{
  CONTROL "OK", IDOK, "Button", WS_TABSTOP, 148, 108, 45, 15
  CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 204, 108, 45, 15
  CONTROL "This is some static text", 4001, "Static", WS_GROUP, 12, 12, 100, 12, WS_EX_TRANSPARENT
  CONTROL "Second Line Static Text", 4002, "Static", WS_GROUP, 12, 32, 100, 12, WS_EX_TRANSPARENT
  CONTROL "Sample Check Box", 4003, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 116, 16, 92, 12, WS_EX_TRANSPARENT
  CONTROL "Second Check Box", 4004, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 116, 40, 92, 12, WS_EX_TRANSPARENT
  CONTROL "Radio-1", 4005, "Button", BS_AUTORADIOBUTTON, 124, 60, 56, 10, WS_EX_TRANSPARENT
  CONTROL "Radio-2", 4006, "Button", BS_AUTORADIOBUTTON, 124, 80, 56, 10, WS_EX_TRANSPARENT
  CONTROL "Inside Group", 4007, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 20, 68, 80, 16, WS_EX_TRANSPARENT
  CONTROL "This is a Group", 4008, "Button", BS_GROUPBOX, 8, 56, 92, 44, WS_EX_TRANSPARENT
  CONTROL "Test", 4009, "Button", WS_TABSTOP, 12, 108, 50, 14
}
 

[byte-one]

Just a idea:
oDlg:refresh(.f.) forces the repaint from the controls in the dialog with next PAINT-message without deleting the background. If the coordinates from say-controls not the same as at last repaint, the says painted on wrong place. I have tested with the windows-API-function "UpdateWindow()" unstead the "InvalidateRect()" and there are the same effect. Maybe the ::cPs from says are modified from repaint to repaint? -> Antonio

[Antonio Linares]

Problem solved !!!

Please add the style WS_CLIPCHILDREN to the dialogbox rc, i.e.:

STYLE WS_POPUP|DS_MODALFRAME|WS_CAPTION|WS_SYSMENU|WS_VISIBLE|WS_CLIPCHILDREN

Please test it and comment results. Thanks

[Antonio Linares]

A brief explanation:

SAYs (labels) are static text, that many times don't need to be changed, i.e. when we use "Name:", "Phone:", etc. labels.

As we can define colors, or other brushes, for the dialogs, those SAYs need to be "modified" or they don't show transparent by default. FiveWin function FixSays() steps through all the controls in the dialog and changes the procedures of those SAYs so they behave the way we want without the need to REDEFINE them, one by one.

When we are using a gradient brush, i.e., we need to paint those SAYs as transparent, and the way to achieve this is to copy the "parent image" as the background of the SAY. This is what ParentImage() exactly does

1. We copy the background "under" the SAY
2. We paint the SAY text on top of that background in transparent mode.

The problem is that if we don't use the style WS_CLIPCHILDREN in the dialog style, then the dialog makes the child controls painting as a part of its painting. Thats why, if we paint the text on top again, we get a bold effect.

WS_CLIPCHILDREN requires the dialog to paint just its surface and not its childs image. So when we copy this area as the background of the control, then there is no text, and we just paint once on top of it.

[byte-one]

Antonio, the problems with the says are gone, but the background from a groupbox are not transparent (also when i define clausula TRANSPARENT) and i cannot define the colors from the groupbox!

[nageswaragunupudi]

Antonio, the problems with the says are gone, but the background from a groupbox are not transparent (also when i define clausula TRANSPARENT) and i cannot define the colors from the groupbox!

Yes, this is the immediate effect of adding WS_CLIPCHILDREN style to DIALOGS in the .rc file. Group boxes from source code are not effected.

Before I report my proposed solution, let us recall the complaint of Mr Maurizio that the transparent group boxes were not painted transprently, if the groups were defined after the contained controls ( tab order of group boxes is later than the tab order of the controls in the .rc file). Then we made a small modification to control.prg that solved the issue.

Having tested, the solution seems to be:
1. Reverse the last modification in the control.prg I described above.
2. This requires that group boxes be defined prior to the controls within the group box ( in rc files, the tab order should be changed accordingly)
3. All group boxes in the rc file should be redefined in the program. They should not be left undefined.
( points 2 and 3 will entail some revisions in the programs by some programmers )

This is Mr. Maurizio's sample after I made the above changes to his rc file and source code as well as the control.prg.


Mr. Antonio may see and offer his guidance. Also I appreciate other friends' comments.

This is the change I made to control.prg for this test.
Existing code:

Code: Select all

         if ! Empty( ::oWnd:oBrush ) .and. ! Empty( ::oWnd:oBrush:hBitmap ) .and. ;
              ! ::IsKindOf( "TGROUP" )
 

Revised

Code: Select all

         if ! Empty( ::oWnd:oBrush ) .and. ! Empty( ::oWnd:oBrush:hBitmap )