TreeView problem

User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

TreeView problem

Post 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.*/
Ciao, best regards,
Ugo
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

Post 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
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post 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?
Ciao, best regards,
Ugo
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

Post by Antonio Linares »

Ugo,

Please test the EXE that I send you by email.

Have you modified any FWH classes yourself ?
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post 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! :(
Ciao, best regards,
Ugo
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post by Ugo »

Ugo wrote: 7) In WBrowse.prg:
::nClrForeHead := GetSysColor( COLOR_BTNTEXT ) // Why CLR_BLACK???
This modification is in Redefine() Method.
Ciao, best regards,
Ugo
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

Post by Antonio Linares »

Ugo,

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

Antonio Linares
www.fivetechsoft.com
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post 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?
Ciao, best regards,
Ugo
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post 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
Ciao, best regards,
Ugo
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post 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
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

Post by Antonio Linares »

Ugo,

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

Antonio Linares
www.fivetechsoft.com
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post 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!
Ciao, best regards,
Ugo
User avatar
Ugo
Posts: 283
Joined: Sat Oct 15, 2005 6:40 am
Location: Turin, Italy

Post 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?
Ciao, best regards,
Ugo
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

Post by Antonio Linares »

Ugo,

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

We are working to fix it
regards, saludos

Antonio Linares
www.fivetechsoft.com
HennekensSM
Posts: 17
Joined: Sun Jan 28, 2007 11:47 am

Post 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
Post Reply