hwgui-developers

[Hwgui-developers] Changelog 2004-10-19 15:10 UTC+0300

[Alexander S.K. <al...@be...>]

2004-10-19 15:10 UTC+0300 Alexander Kresin <al...@be...>
  * source/hdialog.prg
  * utils/designer/designer.prg
  * utils/designer/hformgen.prg
    * Appearance of an integrated designer is fixed


Regards,
 Alexander
http://kresin.belgorod.su

Re: [Hwgui-developers] Changelog 2004-10-19 15:10 UTC+0300

[Lorenzo F. <lor...@te...>]

Alexander S.Kresin wrote:

> 2004-10-19 15:10 UTC+0300 Alexander Kresin <al...@be...>
>   * source/hdialog.prg
>   * utils/designer/designer.prg
>   * utils/designer/hformgen.prg
>     * Appearance of an integrated designer is fixed

Good job. For your information I've just rebuilt hwgui with latest xHarbour CVS + mingw/gcc 3.4.2
and I tried a.prg and grid_5.prg samples. They work well but I still get many memory leaks from fm.c.
fm.log is 1.5MB I'll add only first and last lines:

Memory Allocation Report
Application: C:\dvl\xharbour\contrib\hwgui\samples\a.exe
xHarbour Version: xHarbour build 0.99.2 Intl. (SimpLex)
Compiler: Cygnus MinGW GNU C 3.4.2
Platform: Windows 2000 Professional 5.00.2195 Service Pack 4
Time Occured: 2004.10.19 13:43:21
Total 74637 allocations (11751 reallocation), of which 74633 freed.
Highest total allocated 1452990 bytes in 5283 blocks.
WARNING! Memory allocated but not released: 29 bytes (4 blocks)
Block 1 00FA6C6C (size 4) GETEDITTEXT(0), "01000000"
Block 2 00FA7234 (size 6) GETEDITTEXT(0), "pippo."
Block 3 00FA74C4 (size 15) STRTRAN(0), "88999999999999."
Block 4 00FA5244 (size 4) STRTRAN(0), "01000000"
--------------------------------------------------------------------------------
Memory Allocation Report
Application: C:\dvl\xharbour\contrib\hwgui\samples\grid_5.exe
xHarbour Version: xHarbour build 0.99.2 Intl. (SimpLex)
Compiler: Cygnus MinGW GNU C 3.4.2
Platform: Windows 2000 Professional 5.00.2195 Service Pack 4
Time Occured: 2004.10.19 13:45:15
Total 128007 allocations (10562 reallocation), of which 112602 freed.
Highest total allocated 1343610 bytes in 19568 blocks.
WARNING! Memory allocated but not released: 394695 bytes (15405 blocks)
Block 1 00E495F4 (size 40) LISTVIEW_ADDCOLUMN(0), "6C95E40064D2150100714300010002000004E000080000000600000032D64B000100000054ECE000"
Block 2 00E4956C (size 40) LISTVIEW_ADDCOLUMN(0), "0497E400F495E40000714300010002000004E000080000000500000049D64B000100000054ECE000"
Block 3 00E49704 (size 40) LISTVIEW_ADDCOLUMN(0), "E494E4006C95E40000714300010002000004E000080000000400000060D64B000100000054ECE000"
Block 4 00E494E4 (size 40) LISTVIEW_ADDCOLUMN(0), "7C96E4000497E40000714300010002000004E000080000000400000075D64B000100000054ECE000"
Block 5 00E4967C (size 40) LISTVIEW_ADDCOLUMN(0), "5C90E400E494E40000714300010002000004E00008000000040000008AD64B000100000054ECE000"
Block 6 00E38A54 (size 11) STR(0), "         1."
Block 7 00E48FF4 (size 4) STR(0), "01000000"
Block 8 00E4905C (size 40) LISTVIEW_SETDISPINFO(0), "AC91E4007C96E400007143000100020000044C0010114B000A000000548AE30000000000F48FE400"
Block 9 00E4665C (size 11) STR(0), "         1."
Block 10 00E49234 (size 4) STR(0), "01000000"
Block 11 00E491AC (size 40) LISTVIEW_SETDISPINFO(0), "8C97E4005C90E400007143000100020000044C0010114B000A0000005C66E400000000003492E400"
Block 12 00E49314 (size 4) ONDISPINFO(343), "01000000"
Block 13 00E4937C (size 31) ONDISPINFO(343), "Test          1               ."
Block 14 00E4978C (size 40) LISTVIEW_SETDISPINFO(0), "1498E400AC91E400007143000100020000044C0010114B001E0000007C93E400000000001493E400"
Block 15 00E49814 (size 40) LISTVIEW_SETDISPINFO(0), "0499E4008C97E400007143000100020000044C0010114B000100000035DF4B0001000000049CE300"
Block 16 00E4989C (size 4) DTOC(0), "01000000"
...
Block 15403 0115D134 (size 101) MEMOLINE(0), "Memo Test                                                                                           ."
Block 15404 0115D1FC (size 4) MEMOLINE(0), "01000000"
Block 15405 0115D264 (size 40) LISTVIEW_SETDISPINFO(0), "F495E400FCCE1501007143000100020000044C0010114B006400000034D1150100000000FCD11501"
--------------------------------------------------------------------------------

[Hwgui-developers] Re: Changelog 2004-10-19 15:10 UTC+0300

[Alexander S.K. <al...@be...>]

On 19.10.2004 15:50, Lorenzo Fiorini <lor...@te...> wrote:

LF> Good job. For your information I've just rebuilt hwgui with latest xHarbour CVS + mingw/gcc 3.4.2
LF> and I tried a.prg and grid_5.prg samples. They work well but I still get many memory leaks from fm.c.
LF> fm.log is 1.5MB I'll add only first and last lines:

 I didn't check with xHarbour the grid_5.prg, but have compiled a.prg
 and it hadn't created the fm.log for me. What manipulations with a GET items
 are you do to get that result ?

Regards,
 Alexander
http://kresin.belgorod.su

Re: [Hwgui-developers] Re: Changelog 2004-10-19 15:10 UTC+0300

[Lorenzo F. <lor...@te...>]

Alexander S.Kresin wrote:

>  I didn't check with xHarbour the grid_5.prg, but have compiled a.prg
>  and it hadn't created the fm.log for me. What manipulations with a GET items
>  are you do to get that result ?

I've just tried: simply opened a child and type hwgui on the first get then close and:

Memory Allocation Report
Application: C:\dvl\xharbour\contrib\hwgui\samples\a.exe
xHarbour Version: xHarbour build 0.99.2 Intl. (SimpLex)
Compiler: Cygnus MinGW GNU C 3.4.2
Platform: Windows 2000 Professional 5.00.2195 Service Pack 4
Time Occured: 2004.10.19 14:30:35
Total 9224 allocations (2514 reallocation), of which 9222 freed.
Highest total allocated 775883 bytes in 3732 blocks.
WARNING! Memory allocated but not released: 10 bytes (2 blocks)
Block 1 00ED9364 (size 4) GETEDITTEXT(0), "01000000"
Block 2 00ED93CC (size 6) GETEDITTEXT(0), "hwgui."
--------------------------------------------------------------------------------

regards,
Lorenzo Fiorini

[Hwgui-developers] Re: Changelog 2004-10-19 15:10 UTC+0300

[Alexander S.K. <al...@be...>]

On 19.10.2004 16:32, Lorenzo Fiorini <lor...@te...> wrote:

LF> Alexander S.Kresin wrote:

>>  I didn't check with xHarbour the grid_5.prg, but have compiled a.prg
>>  and it hadn't created the fm.log for me. What manipulations with a GET items
>>  are you do to get that result ?

LF> I've just tried: simply opened a child and type hwgui on the first get then close and:

 Yes, now I get it, too. Was the same before, or it is introduced with a
 last changes ?


Regards,
 Alexander
http://kresin.belgorod.su

Re: [Hwgui-developers] Re: Changelog 2004-10-19 15:10 UTC+0300

[Lorenzo F. <lor...@te...>]

Alexander S.Kresin wrote:

>  Yes, now I get it, too. Was the same before, or it is introduced with a
>  last changes ?

I think it was the same before. I'm not sure about a.prg but here is a msg I sent to you
the July 29 2004 about grid_5.prg:

Here is the fm.log I get after running the grid_5 test.

( The real fm.log is 6939 lines long. )

....
Memory Allocation Report
Application: C:\dvl\xharbour\contrib\hwgui\samples\grid_5.exe
xHarbour Version: xHarbour build 0.99.0 Intl. (SimpLex)
Compiler: Cygnus MinGW GNU C 3.4.1
Platform: Windows 2000 Professional 5.00.2195 Service Pack 4
Time Occured: 2004.07.29 19:02:28
Total 289341 allocations (1731 reallocation), of which 282412 freed.
Highest total allocated 1066848 bytes in 10736 blocks.
WARNING! Memory allocated but not released: 173820 bytes (6929 blocks)
Block 1 00ECF004 (size 40) LISTVIEW_ADDCOLUMN(0), "CF7FCE004CE2101007E534001000200000408F770B30C90060000000236BB40010000000437E9E00"
Block 2 00ECF7FC (size 40) LISTVIEW_ADDCOLUMN(0), "CE6FCE00400FCE0007E534001000200000408F770B30C90050000000946BB40010000000437E9E00"
Block 3 00ECF6EC (size 40) LISTVIEW_ADDCOLUMN(0), "CD5FCE00CF7FCE0007E534001000200000408F770B30C90040000000066BB40010000000437E9E00"
Block 4 00ECF5DC (size 40) LISTVIEW_ADDCOLUMN(0), "C80FCE00CE6FCE0007E534001000200000408F770B30C90040000000576BB40010000000437E9E00"
Block 5 00ECF08C (size 40) LISTVIEW_ADDCOLUMN(0), "4AAFCE00CD5FCE0007E534001000200000408F770B30C90040000000A86BB40010000000437E9E00"
Block 6 00EA8B84 (size 11) STR(0), "         1."
Block 7 00ECDFDC (size 4) STR(0), "10000000"
Block 8 00ECFAA4 (size 40) LISTVIEW_SETDISPINFO(0), "488FCE00C80FCE0007E53400100020000040C400060FA400A000000048B8AE0000000000CDFDCE00"
Block 9 00EA948C (size 11) STR(0), "         1."
Block 10 00ECF1DC (size 4) STR(0), "10000000"
Block 11 00ECF884 (size 40) LISTVIEW_SETDISPINFO(0), "442FCE004AAFCE0007E53400100020000040C400060FA400A0000000C849AE0000000000CD1FCE00"
Block 12 00ECF2CC (size 4) ONDISPINFO(343), "10000000"
Block 13 00ECF664 (size 31) ONDISPINFO(343), "Test          1               ."
Block 14 00ECF244 (size 40) LISTVIEW_SETDISPINFO(0), "477FCE00488FCE0007E53400100020000040C400060FA400E1000000466FCE0000000000CC2FCE00"
Block 15 00ECF774 (size 40) LISTVIEW_SETDISPINFO(0), "4BFFCE00442FCE0007E53400100020000040C400060FA4001000000053FBB400100000004868AE00"
Block 16 00ECF4CC (size 4) DTOC(0), "10000000"
Block 17 00EA9704 (size 9) DTOC(0), "07/30/04."
...

[Hwgui-developers] Re: Changelog 2004-10-19 15:10 UTC+0300

[Alexander S.K. <al...@be...>]

On 19.10.2004 16:57, Lorenzo Fiorini <lor...@te...> wrote:

>>  Yes, now I get it, too. Was the same before, or it is introduced with a
>>  last changes ?

LF> I think it was the same before. I'm not sure about a.prg but here is a msg I sent to you
LF> the July 29 2004 about grid_5.prg:

 Now I've found the roots.
 The fm.log for grid_5.prg is caused by a real bug in the grid.c:

HB_FUNC( LISTVIEW_SETDISPINFO )
{
        PHB_ITEM pValue = hb_itemNew( NULL );
        LV_DISPINFO* pDispInfo = (LV_DISPINFO*)hb_parnl(1);
        hb_itemCopy( pValue, hb_param( 2, HB_IT_STRING ));
        pDispInfo->item.pszText = pValue->item.asString.value;
        
        if (pDispInfo->item.iSubItem == 0)
                pDispInfo->item.state = 2;
}

The pValue item isn't released there and the string, assigned to the
pDispInfo->item.pszText, is never released, too.
This function and all related code should be fully rewritten. It would
be nice if Rodrigo could look at it.

 The problem with a.prg is very interesting. It doesn't appear in
 modal dialogs, only in nonmodal and in MDI Child windows and is
 caused by the fact that variables, used in GET items, are declared as
 local in the window creation procedure and are released before the
 window is closed ! To check this, just move these variables
 declaration to the main procedure and make them Private - you'll see
 the difference.
 There is a difference in handling of local
 variables and codeblocks in Harbour and xHarbour ( I don't know,
 which one is more correct ), so this doesn't cause problems in
 Harbour.
 

Regards,
 Alexander
http://kresin.belgorod.su

[Hwgui-developers] Re: 2004-10-19 15:10 UTC+0300

[Alexander S.K. <al...@be...>]

On 20.10.2004 10:39, Alexander S.Kresin <al...@be...> wrote:

ASK>  The problem with a.prg is very interesting. It doesn't appear in
ASK>  modal dialogs, only in nonmodal and in MDI Child windows and is
ASK>  caused by the fact that variables, used in GET items, are declared as
ASK>  local in the window creation procedure and are released before the
ASK>  window is closed ! To check this, just move these variables
ASK>  declaration to the main procedure and make them Private - you'll see
ASK>  the difference.
ASK>  There is a difference in handling of local
ASK>  variables and codeblocks in Harbour and xHarbour ( I don't know,
ASK>  which one is more correct ), so this doesn't cause problems in
ASK>  Harbour.
 
 After more testing I'm suppose that it is a bug in xHarbour.

Regards,
 Alexander
http://kresin.belgorod.su

Re: [Hwgui-developers] Re: 2004-10-19 15:10 UTC+0300

[Lorenzo F. <lor...@te...>]

Alexander S.Kresin wrote:

>  After more testing I'm suppose that it is a bug in xHarbour.

I think you're right. I had to modify prg code to avoid memory leaks in xHarbour
but I could not find the reason. Probably you've found it.

Can I forward this to the xHarbour developer list ?

regards,
Lorenzo Fiorini

[Hwgui-developers] Re: 2004-10-19 15:10 UTC+0300

[Alexander S.K. <al...@be...>]

On 20.10.2004 12:19, Lorenzo Fiorini <lor...@te...> wrote:

LF> Alexander S.Kresin wrote:

>>  After more testing I'm suppose that it is a bug in xHarbour.

LF> I think you're right. I had to modify prg code to avoid memory leaks in xHarbour
LF> but I could not find the reason. Probably you've found it.

LF> Can I forward this to the xHarbour developer list ?

 Sure.


Regards,
 Alexander
http://kresin.belgorod.su