Menu
▾
▴
hwgui-developers — Discussing of HwGUI development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(64) |
Apr
(70) |
May
(54) |
Jun
(57) |
Jul
(34) |
Aug
(19) |
Sep
(28) |
Oct
(48) |
Nov
(42) |
Dec
(43) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(50) |
Feb
(19) |
Mar
(10) |
Apr
(5) |
May
(1) |
Jun
(14) |
Jul
(23) |
Aug
(6) |
Sep
(118) |
Oct
(110) |
Nov
(36) |
Dec
(6) |
| 2006 |
Jan
(19) |
Feb
(7) |
Mar
(4) |
Apr
(32) |
May
(6) |
Jun
(14) |
Jul
(42) |
Aug
(38) |
Sep
(88) |
Oct
(21) |
Nov
(40) |
Dec
(37) |
| 2007 |
Jan
(31) |
Feb
(20) |
Mar
(26) |
Apr
(38) |
May
(4) |
Jun
(3) |
Jul
(3) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(25) |
Dec
(9) |
| 2008 |
Jan
(7) |
Feb
(10) |
Mar
(16) |
Apr
(10) |
May
(25) |
Jun
(16) |
Jul
(27) |
Aug
(8) |
Sep
(20) |
Oct
(54) |
Nov
(11) |
Dec
(14) |
| 2009 |
Jan
(28) |
Feb
(22) |
Mar
(13) |
Apr
(70) |
May
(25) |
Jun
(23) |
Jul
(12) |
Aug
(18) |
Sep
(7) |
Oct
(4) |
Nov
(8) |
Dec
(36) |
| 2010 |
Jan
(58) |
Feb
(66) |
Mar
(3) |
Apr
(16) |
May
(9) |
Jun
(10) |
Jul
(6) |
Aug
(8) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(27) |
| 2011 |
Jan
(3) |
Feb
(17) |
Mar
(5) |
Apr
(12) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(56) |
Oct
(24) |
Nov
(8) |
Dec
(32) |
| 2012 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(29) |
Aug
(3) |
Sep
(17) |
Oct
(60) |
Nov
(17) |
Dec
(52) |
| 2013 |
Jan
(22) |
Feb
(35) |
Mar
(31) |
Apr
(5) |
May
(16) |
Jun
(108) |
Jul
(57) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(3) |
Dec
(13) |
| 2014 |
Jan
(39) |
Feb
(15) |
Mar
|
Apr
(31) |
May
|
Jun
(9) |
Jul
(16) |
Aug
(1) |
Sep
(8) |
Oct
(51) |
Nov
(5) |
Dec
(119) |
| 2015 |
Jan
(78) |
Feb
(47) |
Mar
(25) |
Apr
(32) |
May
(34) |
Jun
(42) |
Jul
(62) |
Aug
(10) |
Sep
(11) |
Oct
(5) |
Nov
(13) |
Dec
(24) |
| 2016 |
Jan
(12) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(5) |
Aug
(32) |
Sep
(36) |
Oct
(34) |
Nov
(3) |
Dec
(1) |
| 2017 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(6) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(26) |
Sep
(24) |
Oct
(2) |
Nov
(6) |
Dec
(26) |
| 2019 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
|
From: ATZCT <at...@ob...> - 2004-10-26 09:31:09
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=windows-1251" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> <meta content="text/html;charset=windows-1251" http-equiv="Content-Type"> <title></title> I created report with HWREPORT for print data on blank of strict report (for example - warrant for receipt goods).<br> Can i change printable area or i must change position of every object manually, that data will be at their place on paper.<br> <br> regards,<br> Alexey Myronenko<br> </body> </html> |
|
From: Alexander S.K. <al...@be...> - 2004-10-26 08:41:05
|
On 25.10.2004 21:37, Sandro R. R. Freire <san...@ya...> wrote: SRRF> Hi Alexander SRRF> its correction of the keyboard key tab, affected the keyboard keys of arrows SRRF> and mouse. Focus in get. Sorry, I don't understand. What is the problem ? Regards, Alexander http://kresin.belgorod.su |
|
From: Sandro R. R. F. <san...@ya...> - 2004-10-25 18:35:36
|
Hi Alexander its correction of the keyboard key tab, affected the keyboard keys of arrows and mouse. Focus in get. Regards Sandro Freire http://www.lumainformatica.com.br |
|
From: Alexander S.K. <al...@be...> - 2004-10-25 06:41:13
|
2004-10-25 10:30 UTC+0300 Alexander Kresin <al...@be...>
* source/menu_c.c
+ New function has been added - GetMenuHandle( hWnd ), which returns the
window's menu handle.
* Functions Checkmenuitem(hMenu), Ischeckedmenuitem(hMenu), Enablemenuitem(hMenu),
Isenabledmenuitem(hMenu) accepts now the menu handle as a parameter
Regards,
Alexander
http://kresin.belgorod.su
|
|
From: Alexander S.K. <al...@be...> - 2004-10-22 13:21:52
|
=EF=FF=F2=ED=E8=F6=E0, 22 =EE=EA=F2=FF=E1=F0=FF 2004 =E3. ATZCT atzct@obu= khov.kiev.ua wrote: A> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland A> Error: Unresolved external '_HB_FUN_OWNBTNPROC' referenced from=20 A> C:\HWGUI\UTILS\HWREPORT\HWREPORT.OBJ A> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland A> REQUEST OWNBTNPROC be present in next files: A> [... ] Thanks for the info, fixed. =20 Regards, Alexander http://kresin.belgorod.su |
|
From: ATZCT <at...@ob...> - 2004-10-22 12:15:51
|
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Error: Unresolved external '_HB_FUN_OWNBTNPROC' referenced from C:\HWGUI\UTILS\HWREPORT\HWREPORT.OBJ Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland REQUEST OWNBTNPROC be present in next files: dbchw.prg example.prg hownbtn.prg - FUNCTION OwnBtnProc( hBtn, msg, wParam, lParam ) are commented hwmysql.prg hwreport.prg regards, Alexey Myronenko |
|
From: Alexander S.K. <al...@be...> - 2004-10-22 09:05:22
|
2004-10-22 12:45 UTC+0300 Alexander Kresin <al...@be...>
* source/hsplit.prg
* New variable :bEndDrag has been added - a codeblock, which executes
after dragging the splitter
Regards,
Alexander
http://kresin.belgorod.su
|
|
From: Sandro R. R. F. <san...@ya...> - 2004-10-21 11:06:43
|
Hi Alexander @ x, y GET oGet1 PAGE "1" @ x, y GET oGet2 @ x, y GET oGet3 ENDPAGE PAGE "2" @ x, y GET oGet3 ENDPAGE @ X, Y button bt 3 TAB Order, page 1 -> TAB -> In TAB GET 2 .or. GET 3 -> Button Is possible Regards Sandro Freire http://www.lumainformatica.com.br ----- Original Message ----- From: "Alexander S.Kresin" <al...@be...> To: <hwg...@li...> Sent: Thursday, October 21, 2004 8:24 AM Subject: [Hwgui-developers] Tab order > Sandro, > > just some thoughts regarding the tab order, which you had requested > recently. > Currently you can define the necessary tab order simply placing the > control definitions in your code in the order which you need. > I.e., if you write: > > @ 100, 80 GET oGet2 ... > @ 50,30 GET oGet1 ... > @ 100,110 GET oGet3 > > the tab order will be: oGet2, oGet1, oGet3. > > Is some special TabOrder method really needed ? > > > Regards, > Alexander > http://kresin.belgorod.su > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Hwgui-developers mailing list > Hwg...@li... > https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: Alexander S.K. <al...@be...> - 2004-10-21 10:25:36
|
Sandro, just some thoughts regarding the tab order, which you had requested recently. Currently you can define the necessary tab order simply placing the control definitions in your code in the order which you need. I.e., if you write: @ 100, 80 GET oGet2 ... @ 50,30 GET oGet1 ... @ 100,110 GET oGet3 the tab order will be: oGet2, oGet1, oGet3. Is some special TabOrder method really needed ? Regards, Alexander http://kresin.belgorod.su |
|
From: Alexander S.K. <al...@be...> - 2004-10-21 09:14:22
|
2004-10-21 13:15 UTC+0300 Alexander Kresin <al...@be...>
* source/htab.prg
* Minor formatting
* source/hcwindow.prg
! Small bug fixed
* source/hedit.prg
* Problem with using of a TAB key in a Tab control has been fixed.
Regards,
Alexander
http://kresin.belgorod.su
|
|
From: Sandro R. R. F. <san...@ya...> - 2004-10-20 11:19:22
|
Hi Alexander I reproduce and send tomorow Regardas Sandro Freire http://www.lumainformatica.com.br ----- Original Message ----- From: "Alexander S.Kresin" <al...@be...> To: <hwg...@li...> Sent: Wednesday, October 20, 2004 8:54 AM Subject: [Hwgui-developers] Problem with Valid in Designer ( to Sandro ) > Sandro, > > you had wrote that there is some problem with Valid in Designer's > xml form . But the sample, which you had sent is quite big and > includes 10 files - so it's difficult to find the problem there. > Could you sent a small test, which demonstrates the problem ? > > > Regards, > Alexander > http://kresin.belgorod.su > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Hwgui-developers mailing list > Hwg...@li... > https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: Alexander S.K. <al...@be...> - 2004-10-20 10:54:47
|
Sandro, you had wrote that there is some problem with Valid in Designer's xml form . But the sample, which you had sent is quite big and includes 10 files - so it's difficult to find the problem there. Could you sent a small test, which demonstrates the problem ? Regards, Alexander http://kresin.belgorod.su |
|
From: Alexander S.K. <al...@be...> - 2004-10-20 08:31:08
|
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 |
|
From: Lorenzo F. <lor...@te...> - 2004-10-20 08:20:23
|
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 |
|
From: Alexander S.K. <al...@be...> - 2004-10-20 07:05:51
|
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 |
|
From: Alexander S.K. <al...@be...> - 2004-10-20 06:40:59
|
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
|
|
From: Sandro R. R. F. <san...@ya...> - 2004-10-19 16:28:50
|
2004-10-19 13-30 UTC-0300 Sandro R. R. Freire <san...@ya...>
* source/printdos.prg
New implementation contribution by Fernando Athayde
Regards
Sandro Freire
http://www.lumainformatica.com.br
|
|
From: Lorenzo F. <lor...@te...> - 2004-10-19 12:58:23
|
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." ... |
|
From: Alexander S.K. <al...@be...> - 2004-10-19 12:47:09
|
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 |
|
From: Lorenzo F. <lor...@te...> - 2004-10-19 12:33:11
|
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 |
|
From: Alexander S.K. <al...@be...> - 2004-10-19 12:22:08
|
On 19.10.2004 15:41, Sandro R. R. Freire <san...@ya...> wrote: SRRF> Hi Alexander SRRF> That corrects the problem of the TAB AND where does more influence I haven't checked the TAB problems. These modifications aren't intended to fix some known bugs, they are done to introduce new possibilities. We could subclass window and control classes before, too; but now it's possible to provide the child classes with a new messages processing methods. Now HwGUI classes structure is much more complies with the OOP paradigm. Regards, Alexander http://kresin.belgorod.su |
|
From: Alexander S.K. <al...@be...> - 2004-10-19 12:21:57
|
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 |
|
From: Lorenzo F. <lor...@te...> - 2004-10-19 11:51:41
|
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" -------------------------------------------------------------------------------- |
|
From: Sandro R. R. F. <san...@ya...> - 2004-10-19 11:39:18
|
Hi Alexander That corrects the problem of the TAB AND where does more influence Regards Sandro Freire http://www.lumainformatica.com.br ----- Original Message ----- From: "Alexander S.Kresin" <al...@be...> To: <hwg...@li...> Sent: Tuesday, October 19, 2004 3:49 AM Subject: [Hwgui-developers] Changelog 2004-10-19 09:50 UTC+0300 > 2004-10-19 09:50 UTC+0300 Alexander Kresin <al...@be...> > * source/window.c > * source/control.c > * source/dialog.c > * source/wbrowse.c > * source/richedit.c > * source/hwindow.prg > * source/hcontrol.prg > * source/hdialog.prg > * source/hbrowse.prg > * source/hedit.prg > * source/hipedit.prg > * source/hownbtn.prg > * source/hpanel.prg > * source/hriched.prg > * source/hsayimg.prg > * source/hsplit.prg > * source/htab.prg > * source/htree.prg > + source/hcwindow.prg > * include/guilib.ch > * makedll.bc > * makefile.bc > * makefile.gcc > * makefile.pc > * makefile.vc > * makefile.wc > * source/Makefile > * Internal messages processing has been changed. Now the callback *WndProc > functions calls onEvent() method instead of appropriate Def* function. > This allow to subclass window, dialog and control classes and, defining new > onEvent() methods for them, to change the default messages processing. > The HWindow() class is now a parent class for HMainWindow(), HMDIChildWindow() > and HChildWIndow() classes. > The only thing, which should be changed in the current applications code > is a syntax of HWindow():New() function - in case if it used directly instead > of a INIT WINDOW command. > > > Regards, > Alexander > http://kresin.belgorod.su > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Hwgui-developers mailing list > Hwg...@li... > https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: Alexander S.K. <al...@be...> - 2004-10-19 11:20:30
|
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
|
101 messages has been excluded from this view by a project administrator.
