Page 1 of 2

TreeView problem

Posted: Sat Feb 03, 2007 3:49 am
by Ugo
Hi Fw's
the treeview is not correctly visible if started from an buttonbar on mdi window. This is the test:

Code: Select all

#include "FiveWin.ch"
function Main()
   LOCAL oWnd, oBar

   DEFINE WINDOW oWnd MDI

      DEFINE BUTTONBAR oBar 3DLOOK BUTTONSIZE 40, 40 OF oWnd

      DEFINE BUTTON RESOURCE "END_END" OF oBar  ;
             TOOLTIP "Uscita dal sistema" ;
             ACTION oWnd:END()

      DEFINE BUTTON RESOURCE "Search" OF oBar  ;
             TOOLTIP "TestTree" ;
             ACTION TestTree()   // this is not good    :-(

      ACTIVATE WINDOW oWnd MAXIMIZED ;
            ON INIT ( TestTree(),;    // This is good
                           MsgInfo( "Good  :-)", "TestTree()" ),;
                           MsgInfo( "No Good :-( " + CRLF +;
                                         "if press the 2° button", "TestTree()" ) )

      RETURN Nil

//------------------------------------------------------------------------------
// From here is the standard treeview sample
STATIC FUNCTION TestTree()

   local oDlg, oBtn1, oBtn2
   local oTree, oBmp1, oBmp2, oImageList
   local oFont

   DEFINE FONT oFont NAME "Ms Sans Serif" SIZE 0, -12

   DEFINE DIALOG oDlg NAME "ARBOL" FONT oFont

   oImageList = TImageList():New()

   oBmp1 = TBitmap():Define( , "..\bitmaps\16x16\folder.bmp" , oDlg )
   oBmp2 = TBitmap():Define( , "..\bitmaps\16x16\fldMask.bmp", oDlg )

   oImageList:Add( oBmp1, oBmp2 )

   oTree := TTreeView():Redefine( 100, oDlg  )

   oTree:bLDblClick := { | nRow, nCol, nKeyFlags | MyClick( nRow, nCol, oTree ) }

   ACTIVATE DIALOG oDlg CENTERED ;
      ON INIT FillTree( oTree, oImageList )

   oImageList:End()
   oBmp1:End()
   oBmp2:End()


return nIL

//------------------------------------------------------------------------------------------//

function MyClick( nRow, nCol, oTree )

   local oItem

   oItem := oTree:HitTest( nRow, nCol )

   if oItem != NIL
      MsgInfo( oItem:cPrompt )
   else
      MsgInfo( "Not found!" )
   endif

return NIL

//----------------------------------------------------------------------------//

function FillTree( oTree, oImageList )

   local oItem1, oItem2, n

   oTree:SetImageList( oImageList )

   oItem1 := oTree:Add( "Hello world!" )

   oItem1:Add( "xBase & OOPS" )

   oItem2 := oItem1:Add( "Clipper 5" )
    oItem2:Add( "Another" )
   oItem2:Add( "item" )

   oTree:Add( "FiveWin power!" )

   oItem2 := oTree:Add( Time() )
    oItem2:Add( Time() )

    for n = 1 to 50
       oItem2:Add( Str( n ) )
   next

return nil
rc is testtree.rc from sample directory.

someone can confirm?
some solution?
thanks for your answers.*/

Posted: Sat Feb 03, 2007 9:17 am
by Antonio Linares
Ugo,

Your sample is working fine here both from the ON INIT and pressing the button bar second button. What problem do you get ?
Image

Posted: Sat Feb 03, 2007 3:19 pm
by Ugo
Antonio Linares wrote:Your sample is working fine here both from the ON INIT and pressing the button bar second button. What problem do you get ?
Antonio,

When I press 2° button on buttonbar the treeview it appears like in the image:

Image
Have you a suggestion?

Posted: Sat Feb 03, 2007 4:49 pm
by Antonio Linares
Ugo,

Please test the EXE that I send you by email.

Have you modified any FWH classes yourself ?

Posted: Sat Feb 03, 2007 6:24 pm
by Ugo
Antonio Linares wrote:Please test the EXE that I send you by email.
Antonio,
your exe is good! :shock:
Antonio Linares wrote:Have you modified any FWH classes yourself ?
Yes, i have modified any fwh classes :D
A modification creates the problem, ok, but which?
I have modified:
1) In Dialog.prg in Activate Method default lResize16 is .T.
2) In ErrorSys.prg many modifications
3) In Folder.prg I have added the management lResize16
4) In Tget and MGet I have insert the background color when is in focus
5) In RadMenu.prg I have move the default clause after local clause (I send you a private mail in 2007-01-17, do you remember?)
6) In TreeView.prg:

Code: Select all

in New() method I changed:
    nClrBack := oWnd:nClrPane,; // GetSysColor( COLOR_WINDOW ),;
    // I have tested in default mode but do not work!
    // and in the Add Method I have added the management cCargo
//----------------------------------------------------------------------------//
// Aggiunto cCargo (gestito dal TTVItem ma qui non riportato) Ugo Garombo 24/11/2004
METHOD Add( cPrompt, nImage, cCargo ) CLASS TTreeView

   local oItem

   oItem := TTVItem():New( TVInsertItem( ::hWnd, cPrompt, , nImage ), Self, cCargo, cPrompt, nImage )
   // Verificare ... Linares aveva tolto i rem nelle 2 righe sotto
   // also I have removed the next two lines because it are already
   // present in TTvItem New() Method:
   // oItem:cPrompt := cPrompt
   // oItem:nImage  := nImage

   AAdd( ::aItems, oItem )

return oItem

7) In WBrowse.prg:
::nClrForeHead := GetSysColor( COLOR_BTNTEXT ) // Why CLR_BLACK???
8 ) In Window.prg I have added a new method:

Code: Select all

   METHOD ARefresh()           // added by Ugo Garombo Nov. 2004
                               // a differenza di Refresh fa il refresh di tutti gli oggetti


//----------------------------------------------------------------------------//

METHOD ARefresh() CLASS TWindow

   if ValType( ::aControls ) == "A"
      AEval( ::aControls, {| a | a:Refresh() } )
   endif

return nil

//----------------------------------------------------------------------------//
That's all. :D
The question is:
A modification creates the problem, ok, but which?
Can you help me to find the problem?
If you want i can send you my modified source.

Thank you for the moment, and sorry for my bad English! :(

Posted: Sat Feb 03, 2007 6:29 pm
by Ugo
Ugo wrote: 7) In WBrowse.prg:
::nClrForeHead := GetSysColor( COLOR_BTNTEXT ) // Why CLR_BLACK???
This modification is in Redefine() Method.

Posted: Sat Feb 03, 2007 8:30 pm
by Antonio Linares
Ugo,

Please use FWH source\classes\treeview.prg instead of yours and tray it again, thanks

Posted: Sun Feb 04, 2007 1:43 pm
by Ugo
Antonio Linares wrote:Please use FWH source\classes\treeview.prg instead
of yours and tray it again, thanks
Antonio,
do not work! :(
I test with standard library and do not Work!!! :cry:
Do not work with the FWH TTreeView and with FWH fivehx.lib!!! :shock:
I tested another solution:
The new fivehx.lib (with my changed) and the previous fivehc.lib with, in the source, the declaration of not present new functions; now is better but is different from the previous version for the background color. Now is gray normally is white!
Which thing I can make?

Posted: Sun Feb 04, 2007 1:56 pm
by Ugo
Another thing: if I use the normal lib (my fivehx) and i declare this functions in the source:

Code: Select all

FUNCTION tbaddmenu(); RETURN nil
FUNCTION TBGETRECT (); RETURN NIL
FUNCTION TBSETTEXT(); RETURN NIL
FUNCTION TVSETCOLOR(); RETURN NIL
FUNCTION TVSETTEXTIMAGE(); RETURN NIL
The result is this:

Image

Posted: Sun Feb 04, 2007 4:33 pm
by James Bott
Ugo,

You are seeing why it is not a good idea to change FW source. If you need to change the behavior of the source it is much better to subclass the original class. This way you automatically inherit all the changes made to the FW class when you upgrade to a new version.

Also, I would NEVER change one of the original FW lib files. If you feel you must change one of the FW PRGs then just link the OBJ in before the original FW LIBs.

When you are in the situation that you are now, the way to find out which changed FW prg is causing the problem is to remove the changed PRGs one at a time from the link script until the problem goes away. Then the last one you removed is the problem PRG.

If you have put your changed PRGs into the FW LIBs, then rewrite your link script to use the original FW libs and your modified OBJs. Then follow the procedure above.

One other point. If you find a legitimate problem with one of the FW language PRGs then perhaps you should bring it up on the newsgroup. If there is a general agreement that it either needs fixing or it is a good enhancement, often Antonio will add it to the next release.

James

Posted: Sun Feb 04, 2007 6:25 pm
by Antonio Linares
Ugo,

We email you the libraries that we are using. You should get the same EXE as we get

Posted: Sun Feb 04, 2007 10:50 pm
by Ugo
James Bott wrote:You are seeing why it is not a good idea to change FW source. If you need to change the behavior of the source it is much better to subclass the original class. This way you automatically inherit all the changes made to the FW class when you upgrade to a new version.

Also, I would NEVER change one of the original FW lib files. If you feel you must change one of the FW PRGs then just link the OBJ in before the original FW LIBs.

When you are in the situation that you are now, the way to find out which changed FW prg is causing the problem is to remove the changed PRGs one at a time from the link script until the problem goes away. Then the last one you removed is the problem PRG.

If you have put your changed PRGs into the FW LIBs, then rewrite your link script to use the original FW libs and your modified OBJs. Then follow the procedure above.
Dear James,
you have reason!! :(
But my modifications is very little!
James Bott wrote:One other point. If you find a legitimate problem with one of the FW language PRGs then perhaps you should bring it up on the newsgroup. If there is a general agreement that it either needs fixing or it is a good enhancement, often Antonio will add it to the next release.
My modifications are not due to the errors but for better use in my sources.
Now are of public domain and I hope that Antonio inserts in the next version. :wink:

Very thanks for your post!

Posted: Sun Feb 04, 2007 10:51 pm
by Ugo
Antonio Linares wrote:We email you the libraries that we are using. You should get the same EXE as we get
Antonio,
thanks, but do not change nothing! :cry:
I believe to have isolate the problem: I think that the problem is in the RC file! If I remove this line:
1 24 "WindowsXP.manifest"
work correctly, but if I insert, do not work!

Can you confirm?

Posted: Mon Feb 05, 2007 7:49 am
by Antonio Linares
Ugo,

Yes, we have been able to reproduce the bug using 1 24 "WindowsXP.manifest"

We are working to fix it

Posted: Sun Feb 25, 2007 3:06 pm
by HennekensSM
Antonio,

I am experiencing the same problem with the treeview in combination with the manifest file. A fix would be most welcome.
Regards,
Stephan