Re: [Harbour] SF.net SVN: harbour-project:[14190] trunk/harbour
Thanks! 2010/3/20 vouch...@users.sourceforge.net: Revision: 14190 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14190view=rev Author: vouchcac Date: 2010-03-20 05:35:28 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-19 22:22 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.ch * contrib/hbide/hbide.prg * contrib/hbide/idemisc.prg * contrib/hbide/idesaveload.prg + Reworked command-line parameters. Now hbIDE can be invoked with either of the combination, .ini .hbp .prg .c .cpp. Following algorithm is followed: 1 .ini has the precedance over .hbp. 2 if both are passed then .hbp will be added to the project tree, after loading components from .ini. 3 if only .hbp is passed, then no attempt is made to save the settings. 4 if only sources are passed then all will be opened Main panel, which will also be the startup panel, no project tree will be displayed. c:\harbour\contrib\hbidehbide.exe hbide.hbp c:\harbour\contrib\hbidehbide.exe idemisc.prg idethemes.prg c:\harbour\contrib\hbidehbide.exe C:\dev_hbmk\hbide.ini hbide.hbp Regression is possible, please inform any incompatibilities. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.ch trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/idesaveload.prg -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] About message WM_CREATE in gtwvt.c
Hi, All Before returning, CreateWindow sends a WM_CREATE message to the window procedure. So this message _never_ processed in hb_gt_wvt_WndProc, because window handle is still unknown for hb_gt_wvt_Find. This also appends to messages WM_GETMINMAXINFO, WM_NCCREATE and WM_NCCALCSIZE. Any hint how to resolve this? Best regards, Saulius ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14191] trunk/harbour
Revision: 14191 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14191view=rev Author: petr_ch Date: 2010-03-20 09:03:45 + (Sat, 20 Mar 2010) Log Message: --- 2009-11-28 11:00 UTC+0200 Petr Chornyj (myorg63 at mail.ru) * harbour/bin/postinst.bat * Minor change to respect HB_BUILD_SHARED Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/postinst.bat This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14191] trunk/harbour
Hi, It broke creation of shared binaries in my regular release builds. Brgds, Viktor On 2010 Mar 20, at 10:03, petr...@users.sourceforge.net wrote: Revision: 14191 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14191view=rev Author: petr_ch Date: 2010-03-20 09:03:45 + (Sat, 20 Mar 2010) Log Message: --- 2009-11-28 11:00 UTC+0200 Petr Chornyj (myorg63 at mail.ru) * harbour/bin/postinst.bat * Minor change to respect HB_BUILD_SHARED Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/postinst.bat This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14192] trunk/harbour
Revision: 14192 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14192view=rev Author: vszakats Date: 2010-03-20 09:39:53 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 10:38 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * bin/postinst.bat ! Fixed recent change. 'HB_BUILD_SHARED=yes' means to create _default_ binaries (hbtest.exe, hbrun.exe, etc) in shared mode, so the correct behavior here is to _not_ create separate shared versions in this case. I didn't retest every aspect of this, so it's possible even this is wrong and the whole change has to be rethought or reverted. ! Fixed indentation after recent change. Please do respect formatting when editing files. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/postinst.bat This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14193] trunk/harbour
Revision: 14193 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14193view=rev Author: vszakats Date: 2010-03-20 09:43:04 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 10:42 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) - contrib/hbbzip2 + contrib/hbbz2 * contrib/Makefile * contrib/hbbz2/hbbzip2.hbc * Renaming hbbzip2 to hbbz2 (pass 1/2) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/Makefile trunk/harbour/contrib/hbbz2/hbbzip2.hbc Added Paths: --- trunk/harbour/contrib/hbbz2/ Removed Paths: - trunk/harbour/contrib/hbbzip2/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14194] trunk/harbour
Revision: 14194 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14194view=rev Author: vszakats Date: 2010-03-20 09:50:12 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 10:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbbz2/Makefile - contrib/hbbz2/hbbzip2.ch + contrib/hbbz2/hbbz2.ch - contrib/hbbz2/hbbzip2.c + contrib/hbbz2/hbbz2.c - contrib/hbbz2/hbbzip2.hbc + contrib/hbbz2/hbbz2.hbc * contrib/hbbz2/tests/hbmk.hbm * Renaming hbbzip2 to hbbz2 (pass 2/2) * utils/hbmk2/examples/contribf.hbc * Updated. - utils/hbmk2/examples/hmg.hbc - utils/hbmk2/examples/minigui.hbc - Deleted these example since they are now maintained in HMG/MiniGui projects (Thanks!). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbz2/Makefile trunk/harbour/contrib/hbbz2/tests/hbmk.hbm trunk/harbour/utils/hbmk2/examples/contribf.hbc Added Paths: --- trunk/harbour/contrib/hbbz2/hbbz2.c trunk/harbour/contrib/hbbz2/hbbz2.ch trunk/harbour/contrib/hbbz2/hbbz2.hbc Removed Paths: - trunk/harbour/contrib/hbbz2/hbbzip2.c trunk/harbour/contrib/hbbz2/hbbzip2.ch trunk/harbour/contrib/hbbz2/hbbzip2.hbc trunk/harbour/utils/hbmk2/examples/hmg.hbc trunk/harbour/utils/hbmk2/examples/minigui.hbc This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
On Fri, 19 Mar 2010, Mindaugas Kavaliauskas wrote: Hi, I've included BCC55 for comparison. It's running at half the overall speed compared to 4.5 64-bit. Ec... I'm still using BCC, because... it compiles f.e. \external\sqlite3 in 2.74 s, and MGW compiles it in 3 minutes 3.25 s, i.e. 67 times slower... It's important only if you have to often recompile very big C files which can be hardly optimized. So you can use BCC when you are working on such files and MinGW to create final binaries. You can also try to reduce the optimization level, i.e. you can use -Os in MinGW flags. It should reduce the compilation time and final binaries will be slower then the one created by BCC though still faster. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About message WM_CREATE in gtwvt.c
Saulius Zrelskis wrote: Before returning, CreateWindow sends a WM_CREATE message to the window procedure. So this message _never_ processed in hb_gt_wvt_WndProc, because window handle is still unknown for hb_gt_wvt_Find. This also appends to messages WM_GETMINMAXINFO, WM_NCCREATE and WM_NCCALCSIZE. Any hint how to resolve this? Hi, Warning: I do not know anything about WVT, so, my answer will be more generic, but could not fit in case of WVT. I understand the main problem is binding the hWnd to some internal window structure/object representing hWnd in application. Before CreateWindow returns (and hWnd is obtained and bound), event handler receives some messages and it is unable to locate window structure. I use the following method: before CreateWindow() call I put structure pointer into static variable. After first (any) message is received I do hWnd and structure binding, and forward message to real handler. To isolate this binding functionality and avoid situation then message for a different (not the one that was just created) window will be dequeued, I use a separate window procedure for binding purpose. After hWnd and structure is bound, I set the real window handler using SetWindowLong(hWnd, GWL_WNDPROC, ...) and forward event to real handler. Is it clear? Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
On Fri, 19 Mar 2010, Maurilio Longo wrote: Hi, for real code, doing I/O on a network share, the difference could be lower, though. Network IO operations are extremely expensive so they will consume most of time anyhow in local IO operations are not such significant and there are time consuming operations which can be done locally, i.e. reindexing. Please also note that usually *nix applications are executed remotely on the server side only so the execution speed is not reduced by network overhead at all. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14195] trunk/harbour
Revision: 14195 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14195view=rev Author: druzus Date: 2010-03-20 12:07:46 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 13:07 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbwin/wapi_winuser.c * cleaned some code to use wapi_par_*() and wapi_ret_*() macros + added WAPI_*() functions to create and manipolate menus (HMENU) + added WAPI_CREATEACCELERATORTABLE( aAccels ) - hAccel and WAPI_DESTROYACCELERATORTABLE( hAccel ) * harbour/contrib/hbwin/hbwin.ch + added new constant values for WAPI manu functions (WIN_MF_* and WIN_TPM_*) * harbour/contrib/hbwin/hbwapi.h + added few new wapi_par_*() and wapi_ret_*() macros ! fixed wapi_ret_UINT() and wapi_ret_DWORD() macros to not make conversion which can create negative values Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/wapi_winuser.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14194] trunk/harbour
On Sat, 20 Mar 2010, vszak...@users.sourceforge.net wrote: Hi, --- 2010-03-20 10:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbbz2/Makefile - contrib/hbbz2/hbbzip2.ch + contrib/hbbz2/hbbz2.ch - contrib/hbbz2/hbbzip2.c + contrib/hbbz2/hbbz2.c - contrib/hbbz2/hbbzip2.hbc + contrib/hbbz2/hbbz2.hbc * contrib/hbbz2/tests/hbmk.hbm * Renaming hbbzip2 to hbbz2 (pass 2/2) Thank you very much. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: Harbour 14189, hbqt
Pritpal: Tests with Harbour fresh checkout: * $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $ 2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) os2qt development has moved to Qt462 Current tests with os2qt462 r701 so we have a newer Harbour and newer os2Qt462 With our 4 specific error cases - one has been fixed (a) - one changed behaviour (c) - two remain with same behaviour (b, d) a) demoqt.prg Case: QT_QWIDGET_RESIZE(0) PMMERGE 3:0007f6f8 Fixed For first time in history I see demoqt.exe running on OS/2 b) demoqt.prg, MsgInfo( Testing ) added Case: Object destruction LIBC063 0:000669ca Remain Question: Is this a common problem in hbqt in rest of platforms, or exist only in OS/2 ? This is (1,2) output: demoqt.prg:127:MAIN(): HB_TR_ALWAYS demoqt.prg:128:MAIN(): HB_TR_ALWAYS -b- Exception c005 at address 0x1de369ca Exception Code:C005 Exception Address:1DE369CA EAX:0001 EBX:0290FC8C ECX:0290FC94 EDX:0001 ESI: EDI: EBP:0030FB68 CS:EIP:005B:1DE369CA SS:ESP:0053:0030FB50 DS:0053 ES:0053 FS:150B GS: Flags:00010246 Called from MSGINFO(605) in demoqt.prg Called from MAIN(131) in demoqt.prg Killed by SIGSEGV pid=0x45d1 ppid=0x459d tid=0x0001 slot=0x00a4 pri=0x0200 mc=0x0001 E:\HARBOUR103C\HARBOUR\CONTRIB\HBQT\TESTS\DEMOQT.EXE LIBC063 0:000669ca cs:eip=005b:1de369ca ss:esp=0053:0030fb50 ebp=0030fb68 ds=0053 es=0053 fs=150b gs= efl=00010246 eax=0001 ebx=0290fc8c ecx=0290fc94 edx=0001 edi= esi= Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. c) hbide project Case: hbide crash at startup LIBC063 0:000669ca Changed behaviour My description was, for previous behaviour: - New failure When run, show logo, build window with content and CRASH in 5 seconds without human intervention. Tested many times and same behaviour Something changed in hbqt*, hbide. With 13976 was running with some failures, but do not crash in 5 seconds Initial window size is different in both versions - In current behaviour, show logo and never build window, then crash This is (1,2) output: idemisc.prg:925:HBIDE_DBG(): HB_TR_ALWAYS NIL QWidget::setLayout: Attempting to set QLayout on QDockWidget dockProjectTree, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockEditorTabs, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockFuncList, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockSkltnsTree, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockHelp, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockSkeleton, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockFindInFiles, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockThemes, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockProperties, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockEnvironments, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockCompileResults, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockLinkResults, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockOutputResults, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockDocViewer, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockDocWriter, which already has a layout QWidget::setLayout: Attempting to set QLayout on QDockWidget dockFunctions, which already has a layout Exception c005 at address 0x1de369ca Exception Code:C005 Exception Address:1DE369CA EAX:0001 EBX:02C00F6C ECX:02C00F74 EDX:0001 ESI: EDI:02C00F9C EBP:005CFCE8 CS:EIP:005B:1DE369CA SS:ESP:0053:005CFCD0 DS:0053 ES:0053 FS:150B GS: Flags:00010246 Called from HBIDE:CREATE(487) in hbide.prg Called from MAIN(117) in hbide.prg Killed by SIGSEGV pid=0x45f7 ppid=0x459d tid=0x0001 slot=0x00a2 pri=0x0200 mc=0x0001 E:\HARBOUR103C\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE LIBC063 0:000669ca cs:eip=005b:1de369ca ss:esp=0053:005cfcd0 ebp=005cfce8 ds=0053 es=0053 fs=150b gs= efl=00010246 eax=0001 ebx=02c00f6c ecx=02c00f74 edx=0001 edi=02c00f9c esi= Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. d) demoxbp.prg
Re: [Harbour] About message WM_CREATE in gtwvt.c
Hi, Is it clear? Yes, clear and robust solution. Thank you very much. I try to use CreateWindow(Ex) parameter LPVOID lpParam. There can be address of memory or any value ( LPVOID ) 0x12345678 and messages WM_NCCREATE, WM_CREATE receives in lParam structure CREATESTRUCT address, where member lpCreateParams have value passed through lpParam in CreateWindow(Ex). Have you experience on this? Best regards, Saulius ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About message WM_CREATE in gtwvt.c
Saulius Zrelskis wrote: I try to use CreateWindow(Ex) parameter LPVOID lpParam. There can be address of memory or any value ( LPVOID ) 0x12345678 and messages WM_NCCREATE, WM_CREATE receives in lParam structure CREATESTRUCT address, where member lpCreateParams have value passed through lpParam in CreateWindow(Ex). Have you experience on this? lpCreateParams can be used to pass windows structure/object, but this does not help if you want to have hWnd and windows structure binding in WM_GETMINMAXINFO, since this message does not have CREATESTRUCT parameter. WM_GETMINMAXINFO processing could be useful if window size should depend on its child controls size and you want to avoid flicker caused by multiple resize. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14197] trunk/harbour
Revision: 14197 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14197view=rev Author: vszakats Date: 2010-03-20 13:33:10 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 14:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_shell.c ! Inevitable tweaking for Windows API header / compiler idiocy. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_shell.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Request feature win_prn.
Hi! Please add possibility vertical print caracters. Best regards, Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About message WM_CREATE in gtwvt.c
Mindaugas Kavaliauskas wrote: lpCreateParams can be used to pass windows structure/object, but this does not help if you want to have hWnd and windows structure binding in WM_GETMINMAXINFO, since this message does not have CREATESTRUCT parameter. WM_GETMINMAXINFO processing could be useful if window size should depend on its child controls size and you want to avoid flicker caused by multiple resize. Yes, WM_GETMINMAXINFO is the only message which appears before WM_NCCREATE. But you can recall it with MoveWindow, SetWindowPos calls. To avoid flicker turn on window visibility after all readiness. Or I am mistaken? Best regards, Saulius ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 14189, hbqt
David Arturo Macias Corona wrote: Tests with Harbour fresh checkout: * $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $ 2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) os2qt development has moved to Qt462 Current tests with os2qt462 r701 so we have a newer Harbour and newer os2Qt462 Thanks for your constant efforts, someday we will reach a solution, for sure. With our 4 specific error cases - one has been fixed (a) - one changed behaviour (c) - two remain with same behaviour (b, d) a) demoqt.prg Case: QT_QWIDGET_RESIZE(0) PMMERGE 3:0007f6f8 Fixed For first time in history I see demoqt.exe running on OS/2 All the good. b) demoqt.prg, MsgInfo( Testing ) added Case: Object destruction LIBC063 0:000669ca Remain Question: Is this a common problem in hbqt in rest of platforms, or exist only in OS/2 ? This is the behavior of GC and Qt's destruction mechanism, see below. c) hbide project Case: hbide crash at startup LIBC063 0:000669ca Changed behaviour In current behaviour, show logo and never build window, then crash Probably fixed in r14198, please test. It is again a destruction of object issue. d) demoxbp.prg Case: QPIXMAP:SCALED(0) LIBC063 0:000669ca Remain Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg This is bug in OS Qt in QPixmap() class. Tell Dmitry specifically pointing to this issue only. Regarding the object destruction in Qt. I don't know if this is relevant or not, but Qt uses a lot of global and local static objects (in terms of C++) that get automatically constructed at program startup and destroyed at termination. In C++, the order in which these objects are constructed and destructed, is not guaranteed. I found one bug related to this issue in Qt itself (see r599 in the SVN) but there may be more. The above reply portrays the snapshot of our GC way of destruction and how Qt handles them, all timing problem. This is one factor I always struggle about. If we do away with GC pointers, everything goes OK but then application keeps on eating memory unless we reuse the objects, that was the case with first few months of development. I am writing an artical on Harbour-Qt implementation focusing on object creation and destruction mechanism. Once that is in place, we can request netlabs to look into it deeply and suggest us what should be our strategy. Thank you for constant efforts. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/OS-2-Harbour-14189-hbqt-tp4768265p4768762.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 14189, hbqt
Will be good if possible if sameboy [like Pritpal] found a way in hbide,hbqt.hbxbp that when a compoment not work the application will continue also without this part, this be usefull for platform like os2,ubuntu,mobile platform with partial support SET INGNORE ERROR Better partial that nothing 2010/3/20 Pritpal Bedi bediprit...@hotmail.com: David Arturo Macias Corona wrote: Tests with Harbour fresh checkout: * $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $ 2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) os2qt development has moved to Qt462 Current tests with os2qt462 r701 so we have a newer Harbour and newer os2Qt462 Thanks for your constant efforts, someday we will reach a solution, for sure. With our 4 specific error cases - one has been fixed (a) - one changed behaviour (c) - two remain with same behaviour (b, d) a) demoqt.prg Case: QT_QWIDGET_RESIZE(0) PMMERGE 3:0007f6f8 Fixed For first time in history I see demoqt.exe running on OS/2 All the good. b) demoqt.prg, MsgInfo( Testing ) added Case: Object destruction LIBC063 0:000669ca Remain Question: Is this a common problem in hbqt in rest of platforms, or exist only in OS/2 ? This is the behavior of GC and Qt's destruction mechanism, see below. c) hbide project Case: hbide crash at startup LIBC063 0:000669ca Changed behaviour In current behaviour, show logo and never build window, then crash Probably fixed in r14198, please test. It is again a destruction of object issue. d) demoxbp.prg Case: QPIXMAP:SCALED(0) LIBC063 0:000669ca Remain Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg This is bug in OS Qt in QPixmap() class. Tell Dmitry specifically pointing to this issue only. Regarding the object destruction in Qt. I don't know if this is relevant or not, but Qt uses a lot of global and local static objects (in terms of C++) that get automatically constructed at program startup and destroyed at termination. In C++, the order in which these objects are constructed and destructed, is not guaranteed. I found one bug related to this issue in Qt itself (see r599 in the SVN) but there may be more. The above reply portrays the snapshot of our GC way of destruction and how Qt handles them, all timing problem. This is one factor I always struggle about. If we do away with GC pointers, everything goes OK but then application keeps on eating memory unless we reuse the objects, that was the case with first few months of development. I am writing an artical on Harbour-Qt implementation focusing on object creation and destruction mechanism. Once that is in place, we can request netlabs to look into it deeply and suggest us what should be our strategy. Thank you for constant efforts. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/OS-2-Harbour-14189-hbqt-tp4768265p4768762.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano Iscritto all'albo dei CTU presso il Tribunale di Novara per materia Informatica Delta Informatica S.r.l. (http://www.deltain.it/) (+39 0321 455962) Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14199] trunk/harbour
Revision: 14199 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14199view=rev Author: petr_ch Date: 2010-03-20 16:26:55 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 18:00 UTC+0200 Petr Chornyj (myorg63 at mail.ru) * harbour/bin/postinst.bat ! fixed to not override hbrun if HB_BUILD_SHARED == yes * harbour/ChangeLog ! fixed date * harbour/contrib/hbsqlit3/hbsqlit3.c ! fixed usage hb_fsNameConv in SQLITE3_TEMP_DIRECTORY Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/postinst.bat trunk/harbour/contrib/hbsqlit3/hbsqlit3.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14200] trunk/harbour/ChangeLog
Revision: 14200 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14200view=rev Author: petr_ch Date: 2010-03-20 16:35:33 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 18:30 UTC+0200 Petr Chornyj (myorg63 at mail.ru) * harbour/ChangeLog ! fixed typo my previous commit. Sorry.. Modified Paths: -- trunk/harbour/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14201] trunk/harbour
Revision: 14201 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14201view=rev Author: vouchcac Date: 2010-03-20 17:17:14 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 10:12 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/ideprojmanager.prg * contrib/hbide/idesources.prg + Implemented: auto-save the project's source(s) at build time, if some are modified. This is implemented by default, no options. Regression is possible, please report. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/idesources.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14202] trunk/harbour
Revision: 14202 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14202view=rev Author: vszakats Date: 2010-03-20 17:53:29 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 18:51 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * bin/postinst.bat ! Fixed/cleaned latest modification, removed redundancy. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/postinst.bat This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14203] trunk/harbour
Revision: 14203 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14203view=rev Author: vouchcac Date: 2010-03-20 18:28:56 + (Sat, 20 Mar 2010) Log Message: --- 2010-03-20 11:25 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.ch * contrib/hbide/hbide.prg * contrib/hbide/idefunctions.prg * contrib/hbide/idesaveload.prg + Implemented: auto-loading the last Re-tagged functions prototype. It may take some time but it is done at the background, so user will never experience the difference. You can start working on any other aspect of hbIDE. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.ch trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idefunctions.prg trunk/harbour/contrib/hbide/idesaveload.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Hbide is at xmate level for harbour user
Massimo Belgrano wrote: Project function lookup is very good but little complex to use: is possible Define a hbide project flag who automatically open tag so balance need of fast load with easy to use Done. r14203. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-is-at-xmate-level-for-harbour-user-tp4762452p4769494.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Hbide is at xmate level for harbour user
Project mapping and user menu (because i use for integrate harbour developer language with winapi) On TODO list. Very good! Gui Debugger Still not thought of, I need be more educated in this field. basic function of prg level debug are exec steep by step your prg and show value of variable MultiThread give more difficult debug http://www.allinea.com/?page=86 c level need solution like Valgrind Can somebody share here intresting experiences in different language? -Color and look must find a way to be more professional Where do you find hbIDE does not look professional ? Single out the areas and suggest what should be different. We removed the gradients because of obivious reasons, that is what you are pointing out ? in follow lin same screeen shoot of Vistual studio 2010 all icon,element are blue colored qt similar look green In color area Vailton Renato have made a very good work with Harbour website Can Vailton Help here? Anybody can contribute here with wich are good look and feel for Modern Gui Web 2.0 Colour http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/visual-studio-2010-screenshots http://community.visual-basic.it/alessandro/archive/2009/10/20/26741.aspx http://blogs.devleap.com/articolidevleap/archive/2008/11/30/visual-studio-2010-primo-contatto-parte-3.aspx -Having all toolbar feature in also menu because tree toolbar are a lot and little unusual -we need reduce complexity Here I am totally disagree with you at all. How do you consider a menu is better than a toolbar. In this case you are refering to tree-views, right ? Note that complex nature of some data need different presentation methodology. No sorry i bad explain if you give either way of do a Thing, can be used for user that habitually use menu or toolbar or righclick for example i use menu and user menu for discover choice offered from a program then want define my preferred customised icon toolbar -give a extensibility for allow the creation of plugin pligin concept is proprietory to Qt itself, and cannot be replicated through Harbour wrappers. BTW which plugins you are talking about? still sorry for my bad english I think a plugin for hbide, FOr example if a write a program and want use in hbide Kind of program may be like... -customised file compare -Another file search function -Binary editor -Support a different language in hbide -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE - Autosave a Source
Hi All I am almost there to implement autosave a modified source after a fixed interval of time. My worry - is it worth ? Opinions? - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/hbIDE-Autosave-a-Source-tp4769695p4769695.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE - Autosave a Source
yes, but only IF: - it is an option not enabled by default OR - autosaves to a different file to not overwrite the file on disk imagine you have your editor open and you go to have a drink, your cat jumps over the keyboard and deletes some lines of code Infact both vi editor and ms word autosave to a temporary file with a different (but similar) name... if the program crashes and you run it again, the program recognizes that an autosave file is present and ask you to recover it... So, again, YES, it is an important feature, but it must be properly implemented Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] field-(name) in a macro
Hi,
How can I compile (and run) this code in a macro:
field-(name)
example:
func xxx( name )
local b := ( {|| field-(' + name + ') } )
return eval( b )
Error BASE/1449 Syntax error:
PS in *.hrb the exact same error
PPS Alaska XBase++: compiles without errors
(I convert the code from XBase++)
--
Alexandr
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: field-(name) in a macro
xVar := (cAlias)-(FieldGet(FieldPos('name')))
HTH
Angel
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: field-(name) in a macro
Hi
And since change in more than 800 files?
there is a simpler solution?
In PRG everything compiles and runs fine
2010/3/21 Angel Pais amigo...@adinet.com.uy:
xVar := (cAlias)-(FieldGet(FieldPos('name')))
HTH
Angel
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: field-(name) in a macro
And since change in more than 800 files?
I don't know your source code but you wrote:
func xxx( name )
local b := ( {|| field-(' + name + ') } )
return eval( b )
so I understand that in your 800 files there are several calls like:
bGet = xxx( surname )
It this is the actual situation, you may try something like:
func xxx( name )
local b := ( {|| FieldGet(FieldPos(' + name + '))} )
return eval( b )
but it only looks in current workarea
If you have FIELD definition for different workareas you may try:
local b := ( {|| field-FieldGet(FieldPos(' + name + '))} )
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] field-(name) in a macro
Harbour has the same behavior as Clipper .-
proc main()
PUBLIC VAR := 'Hello'
? M-(VAR) // Ok
? xxx( VAR ) // Ok
? Eval( ('{|| M-'+VAR+'}') ) // Ok
? Eval( ('{|| M-(VAR) }') ) // Error BASE/1449 Syntax error:
return
func xxx( name )
// b := ( {|| field- + name + } )
local b := ( {|| M- + name + } )
return eval( b )
PS At least with this. :)
HTH
--
Xavi
El 20/03/2010 23:06, Alexandr Okhotnikov escribió:
Hi,
How can I compile (and run) this code in a macro:
field-(name)
example:
func xxx( name )
local b :=( {|| field-(' + name + ') } )
return eval( b )
Error BASE/1449 Syntax error:
PS in *.hrb the exact same error
PPS Alaska XBase++: compiles without errors
(I convert the code from XBase++)
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
