Dynamic FOLDER problem with GET on XP

[alexstrickland]

Hello Antonio

This is a slightly modified version of folder.prg:

Code: Select all

#include "fivewin.ch"

function Main()

   local oDlg, oFld
   local oGet, cGet := "     "

   DEFINE DIALOG oDlg TITLE "FiveWin Dynamic folders" ;
      FROM 5, 5 TO 20, 49

   @ 0.5, 1 FOLDER oFld PROMPT "&xBase", "&And OOP", "&Power" ;
      OF oDlg SIZE 160, 90

   @ 1, 1 BUTTON "&Hello" OF oFld:aDialogs[ 1 ] ;
     ACTION MsgInfo( "Hello world!" )

    // Comment this line to get proper Folder colour
   @ 3, 2 GET oGet VAR cGet OF oFld:aDialogs[ 1 ]

   @ 5.5, 11 BUTTON "Ok" OF oDlg ACTION oDlg:End()

   ACTIVATE DIALOG oDlg CENTERED

return nil

procedure AppSys // Xbase++ requirement

return

It must be compiled along with folder.rc for XP style:

1 24 "winxp\WindowsXP.Manifest"

The GET messes up the colour of the folder page, instead of a whitish colour it changes to the standard dialog colour and makes the tab look horrible.

Regards
Alex

[Antonio Linares]

Alex,

Here it looks fine on XP and Vista:

[Antonio Linares]

Ok, I see what you mean: The dialog background

[Antonio Linares]

Alex,

Do it this way as a workaround meanwhile we find where the difference comes from:

Code: Select all

   ACTIVATE DIALOG oDlg CENTERED ;
      ON INIT AddGet( oFld )

return nil 

function AddGet( oFld )

   local cGet := "     " 
   
   @ 6, 2 GET oGet VAR cGet OF oFld:aDialogs[ 1 ] SIZE 90, 25

return nil

[Antonio Linares]

This may also help:

@ 3, 2 GET oGet VAR cGet OF oFld:aDialogs[ 1 ]

oFld:aDialogs[ 1 ]:bEraseBkGnd = { | hDC | DrawPBack( oFld:aDialogs[ 1 ]:hWnd, hDC ), 1 }

[alexstrickland]

Hi Antonio

Thanks for the response. The first solution unfortunately is not suitable for my app.

The second solution causes my app to crash, no error, no gpf.

It works for folder.prg but the button does not look so good any more.

I actually also get a crash when I use oFolder:Move(...), I use MoveWindow() instead.

I can send you may test app, it is 1 .prg but is quite large (~1000 lines). It may help in your testing?

Regards
Alex

[alexstrickland]

Hi Antonio

This command has similar problems, and obscures items "behind" it:

@ <nTop>, <nLeft> [ GROUP <oGroup> ] TO <nBottom>, <nRight>

Regards
Alex

[Antonio Linares]

Alex,

You have to create the GROUP before other controls that you plan to place on top of it

[alexstrickland]

Hi Antonio

I am placing it on before and sizing it after, all items in the group are obscured.

Regards
Alex

[Antonio Linares]

Alex,

Have you considered to build your folders from resources ?

[alexstrickland]

Antonio,

Sorry, it is totally data driven, resources cannot help me at all.

Regards
Alex

[Antonio Linares]

Alex,

I guess that you have found this problem when you added the themes support, right ?

How was it working before ?

[Antonio Linares]

Alex,

In source\classes\folder.prg you find this twice:

Code: Select all

            if Empty( oDlg:oBrush:hBitmap )
               oDlg:bEraseBkGnd = { | hDC | DrawPBack( oDlg:hWnd, hDC ), 1 }
            endif   

Comment if and endif so the codeblock is always assigned

[alexstrickland]

Antonio

I have taken the liberty of sending you my source code.

There are 4 #defines at the top of the file:

#define UGLY
//#define HANGS
//#define GROUP
#define FIX

If UGLY is defined then the tab is not a nice colour and the edges are obscured.

If HANGS is defined the Folder:Move will hang.

If GROUP is defined then you can see the problems with this.

If FIX is defined then your last fix is applied, but it has it's own problems as you may see.

You must compile with the manifest (I guess you know:).

Regards
Alex

[Antonio Linares]

Alex,

Here it is not hanging using Vista 32.

have you tried to create the controls on top of groups as childs of them ?

@ ..., ... OF oGroup