[Harbour] Compiling harbour
Hi All Ubuntu x64 (ver 9.10) Harbour rev.13806 in file included from ../../../../../include/hbmacro.h:64, from ../../../../../include/hbcomp.h:65, from ../../../nortl.c:58: ../../../../../include/hbapiitm.h:100: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘hb_itemGetNInt’ ../../../../../include/hbapiitm.h:126: error: expected declaration specifiers or ‘...’ before ‘HB_MAXINT’ ../../../../../include/hbapiitm.h:127: error: expected declaration specifiers or ‘...’ before ‘HB_MAXINT’ In file included from ../../../../../include/hbmacro.h:67, from ../../../../../include/hbcomp.h:65, from ../../../nortl.c:58: ../../../../../include/hbexprop.h:82: error: expected ‘)’ before ‘HB_COMP_PTR’ ../../../../../include/hbexprop.h:165: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘hb_compExprAsLongNum’ ../../../../../include/hbexprop.h:208: error: expected declaration specifiers or ‘...’ before ‘HB_MAXINT’ In file included from ../../../nortl.c:58: ../../../../../include/hbcomp.h:206: error: expected ‘)’ before ‘lNumber’ ../../../../../include/hbcomp.h:212: error: expected declaration specifiers or ‘...’ before ‘HB_MAXINT’ ../../../../../include/hbcomp.h:213: error: expected declaration specifiers or ‘...’ before ‘HB_MAXINT’ include/hbdefs.h: #if defined( HB_CLIPPER_INT_ITEMS ) # define HB_INT_MAX SHRT_MAX # define HB_INT_MIN SHRT_MIN # define HB_LONG_MAXLONG_MAX # define HB_LONG_MINLONG_MIN # define HB_ULONG_MAX ULONG_MAX typedef long HB_MAXINT; typedef unsigned long HB_MAXUINT; # define PFHL "l" #elif !defined( HB_LONG_LONG_OFF ) && ULONG_MAX == UINT_MAX # define HB_INT_MAX INT_MAX # define HB_INT_MIN INT_MIN # define HB_LONG_MAXLONGLONG_MAX # define HB_LONG_MINLONGLONG_MIN # define HB_ULONG_MAX ULONGLONG_MAX typedef HB_LONGLONG HB_MAXINT; typedef HB_ULONGLONG HB_MAXUINT; #else # define HB_INT_MAX INT_MAX # define HB_INT_MIN INT_MIN # define HB_LONG_MAXLONG_MAX # define HB_LONG_MINLONG_MIN # define HB_ULONG_MAX ULONG_MAX ?---> typedef long ?? ?---> typedef unsigned long?? # define PFHL "l" #endif -- Okhotnikov Alexandr ___ 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:[13807] trunk/harbour
Revision: 13807 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13807&view=rev Author: vszakats Date: 2010-02-08 09:32:43 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-07 10:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h ! Fixed typo when restructuring types causing no HB_MAXINT type in some cases. * contrib/gtalleg/gtalleg.c * USHORT -> HB_USHORT * contrib/hbct/print.c * contrib/hbnf/descendn.c * contrib/hbclipsm/gauge.c * USHORT -> HB_SIZE * contrib/xhb/txtline.c * USHORT, int -> HB_SIZE Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtalleg/gtalleg.c trunk/harbour/contrib/hbclipsm/gauge.c trunk/harbour/contrib/hbct/print.c trunk/harbour/contrib/hbnf/descendn.c trunk/harbour/contrib/xhb/txtline.c trunk/harbour/include/hbdefs.h 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: Res: [Harbour] MinGW dllcall function not run.
Hi, >> ... I wonder if it's possible to fix this >> function to not be sensitive on this setting. >> >> Any idea? > > Yes, of course. ??? :) > I can fix this without ASM, but a bad use of these functions always cause GPF. That would be the nicest. I guess protection against 'bad use' is not entirely possible, as its users job to passing parameters according to call specification of .dll function. Brgds, Viktor ___ 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:[13808] trunk/harbour
Revision: 13808 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13808&view=rev Author: vszakats Date: 2010-02-08 10:50:44 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-07 11:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/wapi_wingdi.c * contrib/hbwin/hbwin.ch + Added WAPI_EXTTEXTOUT() * contrib/hbwin/axcore.c * contrib/hbwin/olecore.c * USHORT -> HB_USHORT * contrib/hbwin/win_prn2.c * USHORT -> HB_SIZE plus some changes accordingly. * src/rtl/gtwin/gtwin.c * src/rtl/gtwvt/gtwvt.c * USHORT -> HB_WCHAR, HB_USHORT * contrib/gtwvg/gtwvg.c * contrib/gtwvg/wvggui.c * contrib/gtwvg/wvggui.h * contrib/gtwvg/wvgwin.c * contrib/gtwvg/wvgutils.c * contrib/gtwvg/wvgcore.c * contrib/gtwvg/wvgsink.c * contrib/gtwvg/wvgwing.c * USHORT -> HB_WCHAR, HB_USHORT, UINT, int * contrib/gtwvg/gtwvg.h * contrib/gtwvg/wvggui.h - Deleted unused structures (using USHORT). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/gtwvg.h trunk/harbour/contrib/gtwvg/wvgcore.c trunk/harbour/contrib/gtwvg/wvggui.c trunk/harbour/contrib/gtwvg/wvggui.h trunk/harbour/contrib/gtwvg/wvgsink.c trunk/harbour/contrib/gtwvg/wvgutils.c trunk/harbour/contrib/gtwvg/wvgwin.c trunk/harbour/contrib/gtwvg/wvgwing.c trunk/harbour/contrib/hbwin/axcore.c trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/contrib/hbwin/wapi_wingdi.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/src/rtl/gtwin/gtwin.c trunk/harbour/src/rtl/gtwvt/gtwvt.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] bug: ACHOICE()
>> Wich other harbour part need be rewritten from scratch? > > I can't think of any other. I've found three: - XML handling in xhb lib, but that rather needs a reimplementation in core. - .dll support in hbwin. (the x86 part) - SORT command ( + ACHOICE() and MEMOEDIT() of course) Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Started a blog on harbour language
I am excited to announce a blog about harbour language at http://harbourlanguage.blogspot.com/ I update info about hbide,hbxbp,hbmk2 because a lot of user have made follow request by mail Italian version planed be published at http://www.gio22.com/harbour/default.asp i invite also everyone be part of harbour group on facebook http://www.facebook.com/group.php?gid=48795263775&ref=ts -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How to build and use pCode DLL with hbmk2
Hello I have an aplication based on pCode Dll funcionallity. It was written in xHarbour + BCC55 and now I need to know how to build it hbmk2+MINGW. In xHarbour we could choose between 3 dll entry-points by chosing between maindll.obj, maindllh.obj or maindllp.obj and once linking the dll with maindllp.obj one just had to libload the DLL to make all its symbols be brought to the "host" vm, just like using clipper+blinker DLLs. I see that hbmk2 have and option -hbdyn to build dlls, but how do I tell hbmk2 that I need a pCode DLL and not a self-contained or harbour dll? Ahd how about the load procedings? Should it work the same way as in xHarbour (just libload the DLL and its functions will be available) or is there any other formality to fulfill? We had to threatfully make a few changes on the xHarbour vm to make libload() work properly but they were so few and small that I believe they can have been already solved in Harbour once its vm seems to have a stronger design. Regards, Leandro Damasio___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Leandro, Sorry but I know nothing about pcode .dlls, hence there is no support for it in hbmk2 (yet?). I can't recall anyone doing any tests with this (besides me a while back, but without any results) To do anything in this regard, first I should see how pcode .dlls are supposed to work, linked, etc. I also need to see if this is something Windows specific or portable. The latter would certainly make it more interesting to deal with. In the meantime I'd suggest to consider to use .hrb files instead. Unless there is the need to include .c code in these pcode .dlls, they are superior in all aspects, moreover they already work. Brgds, Viktor On 2010 Feb 8, at 13:34, 2D Info - Leandro Damasio wrote: > Hello > I have an aplication based on pCode Dll funcionallity. It was written in > xHarbour + BCC55 and now I need to know how to build it hbmk2+MINGW. In > xHarbour we could choose between 3 dll entry-points by chosing between > maindll.obj, maindllh.obj or maindllp.obj and once linking the dll with > maindllp.obj one just had to libload the DLL to make all its symbols be > brought to the "host" vm, just like using clipper+blinker DLLs. I see that > hbmk2 have and option -hbdyn to build dlls, but how do I tell hbmk2 that I > need a pCode DLL and not a self-contained or harbour dll? > Ahd how about the load procedings? Should it work the same way as in xHarbour > (just libload the DLL and its functions will be available) or is there any > other formality to fulfill? > We had to threatfully make a few changes on the xHarbour vm to make libload() > work properly but they were so few and small that I believe they can have > been already solved in Harbour once its vm seems to have a stronger design. > Regards, > Leandro Damasio > ___ > 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:[13809] trunk/harbour
Revision: 13809 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13809&view=rev Author: vszakats Date: 2010-02-08 11:50:58 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-07 12:48 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbmcdx/hbbmcdx.h * contrib/hbbtree/hb_btree.h * contrib/hbbtree/hb_btree.c * contrib/hbnetio/netiocli.c * contrib/hbnetio/netiosrv.c * contrib/rddsql/sddmy/mysqldd.c * contrib/rddsql/sddpg/pgsqldd.c * contrib/rddsql/sddfb/fbirddd.c * contrib/rddsql/sddodbc/odbcdd.c * contrib/rddsql/hbrddsql.h * contrib/rddsql/sqlbase.c * contrib/rddsql/sqlmix.c * contrib/rddads/adsx.c * contrib/rddads/ads1.c * contrib/xhb/bkgtsks.c * contrib/xhb/hbcrypt.c * contrib/xhb/dbf2txt.c * contrib/xhb/xhbcopyf.c * contrib/xhb/xhbfunc.c * contrib/xpp/philesx.c * contrib/hbnf/ftattr.c * USHORT -> HB_USHORT * contrib/xhb/xhbsave.c * USHORT -> int * contrib/xhb/filestat.c * USHORT -> HB_FATTR * contrib/hbmemio/memio.c * USHORT -> HB_USHORT * USHORT -> HB_ERRCODE * contrib/hbqt/gtqtc/gtqtc.cpp * contrib/hbqt/gtqtc/gtqtc.h * USHORT -> int, HB_USHORT * contrib/hbnf/fttext.c * contrib/hbmisc/hb_f.c + Added "largefile" support. (at least on the low-level) * USHORT -> HB_USHORT * contrib/hbmisc/tests/testhbf.prg - Deleted old comment. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbmcdx/hbbmcdx.h trunk/harbour/contrib/hbbtree/hb_btree.c trunk/harbour/contrib/hbbtree/hb_btree.h trunk/harbour/contrib/hbmemio/memio.c trunk/harbour/contrib/hbmisc/hb_f.c trunk/harbour/contrib/hbmisc/tests/testhbf.prg trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbnf/ftattr.c trunk/harbour/contrib/hbnf/fttext.c trunk/harbour/contrib/hbqt/gtqtc/gtqtc.cpp trunk/harbour/contrib/hbqt/gtqtc/gtqtc.h trunk/harbour/contrib/rddads/ads1.c trunk/harbour/contrib/rddads/adsx.c trunk/harbour/contrib/rddsql/hbrddsql.h trunk/harbour/contrib/rddsql/sddfb/fbirddd.c trunk/harbour/contrib/rddsql/sddmy/mysqldd.c trunk/harbour/contrib/rddsql/sddodbc/odbcdd.c trunk/harbour/contrib/rddsql/sddpg/pgsqldd.c trunk/harbour/contrib/rddsql/sqlbase.c trunk/harbour/contrib/rddsql/sqlmix.c trunk/harbour/contrib/xhb/bkgtsks.c trunk/harbour/contrib/xhb/dbf2txt.c trunk/harbour/contrib/xhb/filestat.c trunk/harbour/contrib/xhb/hbcrypt.c trunk/harbour/contrib/xhb/xhbcopyf.c trunk/harbour/contrib/xhb/xhbfunc.c trunk/harbour/contrib/xhb/xhbsave.c trunk/harbour/contrib/xpp/philesx.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: Res: [Harbour] MinGW dllcall function not run.
Hi all, ... its users job to passing parameters according to call specification of .dll function. Yes, but I think it's not only Harbour. Apply the patch attached to testdll.prg Could someone test that about xBase++ and/or xHarbour? -- Xavi El 08/02/2010 10:54, Viktor Szakáts escribió: Hi, ... I wonder if it's possible to fix this function to not be sensitive on this setting. Any idea? Yes, of course. ??? :) I can fix this without ASM, but a bad use of these functions always cause GPF. That would be the nicest. I guess protection against 'bad use' is not entirely possible, as its users job to passing parameters according to call specification of .dll function. Brgds, Viktor Index: testdll.prg === --- testdll.prg (revision 13328) +++ testdll.prg (working copy) @@ -69,7 +69,8 @@ ? cData DllUnload( hDLL ) - ? "MsgBox:", DllCall( "user32.dll", NIL, "MessageBoxA", 0, "Hello world!", "Harbour sez", hb_bitOr( MB_OKCANCEL, MB_ICONEXCLAMATION, MB_HELP ) ) + /* Cause GPF [jarabal] */ + ? "MsgBox:", DllCall( "user32.dll", NIL, "MessageBoxA", 0, MB_ICONEXCLAMATION /*"Hello world!"*/, "Harbour sez", hb_bitOr( MB_OKCANCEL, MB_ICONEXCLAMATION, MB_HELP ) ) IF hb_FileExists( "libcurl.dll" ) hDLL := DllLoad( "libcurl.dll" ) @@ -96,17 +97,20 @@ hDLL := DllLoad( "shell32.dll" ) ? "ValType( hDLL ): ", ValType( hDLL ) cData := Space( MAX_PATH ) + cData := '' /* Cause GPF [jarabal] */ ? "CALLDLLBOOL: ", CallDllBool( GetProcAddress( hDLL, "SHGetSpecialFolderPath" ), 0, @cData, CSIDL_APPDATA, 0 ) ? "@cData: ", cData ? "CALLDLL: ", CallDll( GetProcAddress( hDLL, "SHGetFolderPath" ), 0, CSIDL_ADMINTOOLS, 0, 0, cData ) // WRONG ? "cData:", cData cData := Space( MAX_PATH ) + cData := '123' /* Cause GPF [jarabal] */ ? "CALDLL: ", CallDll( GetProcAddress( hDLL, "SHGetFolderPath" ), 0, CSIDL_ADMINTOOLS, 0, 0, @cData ) ? "@cData: ", cData DllUnload( hDLL ) ? "DLLCALL" cData := Space( MAX_PATH ) + cData := 123 /* Cause GPF [jarabal] */ ? DllCall( "shell32.dll", NIL, "SHGetFolderPath", 0, CSIDL_ADMINTOOLS, 0, 0, @cData ) ? cData ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
>>... its users job to >> passing parameters according to call specification of >> .dll function. > > Yes, but I think it's not only Harbour. > Apply the patch attached to testdll.prg > Could someone test that about xBase++ and/or xHarbour? Sorry, I can't see your point. It's a fact that GPF can be caused by passing wrongly formatted _raw_ parameters to C level functions. It's not Harbour's job to protect against it. Harbour's job is to create a working interface in pure .c, which makes it possible for users to pass these raw parameters from Harbour level to .c level. That's all. It's currently tackled together using ASM code, and this is the problem, because it's non-portable, CPU, compiler and compiler-setting dependent. From this point it's users responsibility to pass parameters properly. Brgds, Viktor ___ 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:[13810] trunk/harbour
Revision: 13810 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13810&view=rev Author: vszakats Date: 2010-02-08 13:52:23 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-07 14:30 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/pp/ppcore.c * src/pp/hbpp.c * src/vm/macro.c * src/vm/evalhb.c * src/vm/runner.c * src/vm/estack.c * src/vm/codebloc.c * src/vm/dynsym.c * src/vm/garbage.c * src/vm/itemapi.c * src/vm/hvm.c * src/vm/pvalue.c * src/vm/maindllp.c * src/vm/arrays.c * src/vm/fm.c * src/vm/extrap.c * src/vm/proc.c * src/vm/thread.c * src/vm/memvars.c * src/vm/vm.c * src/vm/eval.c * src/vm/dynlibhb.c * src/vm/classes.c * src/common/hbffind.c * src/common/expropt1.c * src/common/expropt2.c * src/nortl/nortl.c * src/rtl/gtdos/gtdos.c * src/rtl/fscopy.c * src/rtl/gtwin/gtwin.c * src/rtl/gtxwc/gtxwc.h * src/rtl/gtxwc/gtxwc.c * src/rtl/gtcrs/gtcrs.c * src/rtl/philesx.c * src/rtl/do.c * src/rtl/gtstd/gtstd.c * src/rtl/gttrm/gttrm.c * src/rtl/xhelp.c * src/rtl/transfrm.c * src/rtl/fserr.c * src/rtl/gtcgi/gtcgi.c * src/rtl/errapi.c * src/rtl/copyfile.c * src/rtl/errintlo.c * src/rtl/gtapi.c * src/rtl/filesys.c * src/rtl/console.c * src/rtl/spfiles.c * src/rtl/gtos2/gtos2.c * src/rtl/philes.c * src/rtl/hbgtcore.c * src/rtl/itemseri.c * src/rtl/gtsln/mousesln.c * src/rtl/gtsln/gtsln.c * src/rtl/gtsln/kbsln.c * src/rtl/disksphb.c * src/rtl/gtpca/gtpca.c * src/rtl/trace.c * src/rtl/gt_tpl/gt_tpl.c * src/rtl/filebuf.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/dbsql.c * src/rdd/hbdbsort.c * src/rdd/workarea.c * src/rdd/wacore.c * src/rdd/sdf1.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbcmd.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/delim1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/dbcmd53.c * src/rdd/usrrdd/usrrdd.c * src/rdd/wafunc.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxord.c * src/rdd/hbsix/sxtable.c * src/rdd/hbsix/sxcompr.c * src/compiler/hbmain.c * src/compiler/hbfix.c * src/compiler/hbdead.c * src/compiler/genobj32.c * src/compiler/genc.c * src/compiler/hbopt.c * src/compiler/gencc.c * src/compiler/harbour.yyc * src/compiler/harbour.y * include/hbpp.h * include/hbrdddbf.h * include/hbvmpub.h * include/hbrddnsx.h * include/hbstack.h * include/hbgtcore.h * include/hbapifs.h * include/hbxvm.h * include/hbdefs.h * include/hbinit.h * include/hbtypes.h * include/hbrddsdf.h * include/hbapi.h * include/hbapiitm.h * include/hbrddntx.h * include/hbvm.h * include/hbcomp.h * include/hbapirdd.h * include/hbcompdf.h * include/hbrdddel.h * include/hbexpra.c * include/hbexprop.h * include/hbdbsort.h * include/hbapigt.h * include/hbrddcdx.h * include/hbapicls.h * include/hbapierr.h * include/hbrddfpt.h * include/hbexprb.c * contrib/hbct/bitnum.c * contrib/hbct/screen2.c * contrib/hbct/strdiff.c * contrib/hbct/token2.c * contrib/hbct/charonly.c * contrib/hbct/atadjust.c * contrib/hbct/ctmath.c * contrib/hbct/ctwin.c * contrib/hbct/charsort.c * contrib/hbct/charmix.c * contrib/hbct/charevod.c * contrib/hbct/wordrepl.c * contrib/hbct/charrepl.c * contrib/hbct/strswap.c * contrib/hbct/trig.c * contrib/hbct/charswap.c * contrib/hbct/charop.c * contrib/hbct/charone.c * contrib/hbct/num1.c * contrib/hbct/pos1.c * contrib/hbct/ascpos.c * contrib/hbct/ctstr.c * contrib/hbct/screen1.c * contrib/hbct/token1.c * contrib/hbct/charmirr.c * contrib/hbct/ctc.c * contrib/hbct/ctwfunc.c * contrib/hbct/relation.c * contrib/hbct/atnum.c * contrib/hbct/count.c * contrib/hbct/ctcrypt.c * contrib/hbct/posdiff.c * contrib/hbct/finan.c * contrib/hbct/range.c * contrib/hbct/addascii.c * contrib/hbct/ctmath2.c * contrib/hbct/tab.c * contrib/hbct/replace.c * contrib/hbct/asciisum.c * contrib/hbct/pos2.c * contrib/hbct/numat.c * contrib/hbct/atrepl.c * contrib/hbct/wordtoch.c * contrib/hbct/ctpad.c * contrib/hbct/print.c * contrib/hbct/justify.c * contrib/hbct/remove.c * USHORT -> HB_USHORT (except where BYTE was used in OS-specific context) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/addascii.c trunk/harbour/contrib/hbct/asciisum.c trunk/harbour/contrib/hbct/ascpos.c trunk/harbour/contrib/hbct/atadjust.c trunk/harbour/contrib/hbct/atnum.c trunk/harbour/contrib/hbct/atrepl.c trunk/harbour/contrib/hbct/bitnum.c trunk/harbour/contrib/hbct/charevod.c trunk/harbour/contrib/hbct/charmirr.c trunk/harbour/contrib/hbct/charmix.c trunk/harbour/contrib/hbct/charone.c trunk/harbour/contrib/hbct/charonly.c trunk/harbour/contrib/hbct/charop.c trunk/harbour/contrib/hbct/charrepl.c trunk/harbour/contrib/hbct/charsort.c trunk/harbour/contrib/hbct/charswap.c trunk/harbour/contrib/hbct/count.
[Harbour] HB_LONG / HB_ULONG
Hi All, There is the known problem of HB_LONG, HB_ULONG which should be the Harbour type name for former LONG / ULONG types, but in the past it has been used to denote largest integer type on given platform. Now its superseded by HB_MAXINT, HB_MAXUINT, and Harbour codebase has been changed to use it. This means no Harbour code use HB_LONG and HB_ULONG anymore. I believe this type was not overused in 3rd party code (I could only find a few placed in LetoDB where it's used), so it's not big job to update them where needed, and even by staying compatible with older Harbour and even xhb version (simply by creating new type HB_MAXINT/HB_MAXUINT). If we go this route, we may reuse HB_LONG and HB_ULONG as replacements for LONG / ULONG. So this would be a small breakage of compatibility, but would give us clean and clear type naming system. I'd vote to do this. If not doing this, we have to come up with new type names for Harbour LONG and Harbour ULONG, or clear Harbour code from these types altogether. Since they are used in 2500 locations, this would be an almost impossible job, at least for ULONG. Or, use simply 'long' and 'unsigned long', but IMO this way we would lose easy way to identify these types. Opinions are welcome! Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Viktor Sorry but I know nothing about pcode .dlls, hence there is no support for it in hbmk2 (yet?). I can't recall anyone doing any tests with this (besides me a while back, but without any results) If you need a tester to this I would be glad to help. I'm working with windows + hbmk2 + mingw. To do anything in this regard, first I should see how pcode .dlls are supposed to work, linked, etc. I also need to see if this is something Windows specific or portable. The latter would certainly make it more interesting to deal with. I don't know if this is what you are talking about, but I could tell as a high-level user what is the expected usage and behaviour if that be the case. I just used pcode dlls in windows enviroment, so I don't know much about their portability also, but I believe there shouldn't be any plataform dependant issues below to hb_libload function in this case. I don't think they can be a "build once run everywhere" solution, but they sure can be a "code once run everywhere" solution. In the meantime I'd suggest to consider to use .hrb files instead. Unless there is the need to include .c code in these pcode .dlls, they are superior in all aspects, moreover they already work. Yes, that can be very good, but I don't know anything about .hrb modules. Are they compiled or interpreted in run-time? What is the usage? Is there any limitations on .hrb modules (variable and function scope limitations, class declaration limitations, mt limitations) compared to statically linked prg modules beyond support to c code? Are there any examples or documentation on repository ? Thank you for answering. Best regards Leandro -- From: "Viktor Szakáts" Sent: Monday, February 08, 2010 8:42 AM To: "Harbour Project Main Developer List." Subject: Re: [Harbour] How to build and use pCode DLL with hbmk2 Hi Leandro, Sorry but I know nothing about pcode .dlls, hence there is no support for it in hbmk2 (yet?). I can't recall anyone doing any tests with this (besides me a while back, but without any results) To do anything in this regard, first I should see how pcode .dlls are supposed to work, linked, etc. I also need to see if this is something Windows specific or portable. The latter would certainly make it more interesting to deal with. In the meantime I'd suggest to consider to use .hrb files instead. Unless there is the need to include .c code in these pcode .dlls, they are superior in all aspects, moreover they already work. Brgds, Viktor On 2010 Feb 8, at 13:34, 2D Info - Leandro Damasio wrote: Hello I have an aplication based on pCode Dll funcionallity. It was written in xHarbour + BCC55 and now I need to know how to build it hbmk2+MINGW. In xHarbour we could choose between 3 dll entry-points by chosing between maindll.obj, maindllh.obj or maindllp.obj and once linking the dll with maindllp.obj one just had to libload the DLL to make all its symbols be brought to the "host" vm, just like using clipper+blinker DLLs. I see that hbmk2 have and option -hbdyn to build dlls, but how do I tell hbmk2 that I need a pCode DLL and not a self-contained or harbour dll? Ahd how about the load procedings? Should it work the same way as in xHarbour (just libload the DLL and its functions will be available) or is there any other formality to fulfill? We had to threatfully make a few changes on the xHarbour vm to make libload() work properly but they were so few and small that I believe they can have been already solved in Harbour once its vm seems to have a stronger design. Regards, Leandro Damasio ___ 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
On Mon, 08 Feb 2010, Szak�ts Viktor wrote: Hi, > Sorry but I know nothing about pcode .dlls, hence > there is no support for it in hbmk2 (yet?). I can't > recall anyone doing any tests with this (besides me > a while back, but without any results) I was creating them without any problems and from time to time I made such tests together with HRB support. As long as some of recent modification did not seriously break sth then it should work without any problem. The most important rule which users have to always remember: it's illegal to link PCODE dll and any other DLLs with Harbour static functions. If you make that then the same code is linked twice so it may not work as expected, i.e. two independent HVM stacks. This same is for any other projects and code so it's rather basic knowledge about using shared libraries in Windows. It also means that fully functional Harbour distribution should have shared version of all libraries or at least provide easy way There are two possible methods to create PCODE dll. 1. when final application using PCODE dll is linked in shared mode with harbour*.dll. In such case it's enough to link the PCODE dll with exactly the same harbour*.dll. That's all. No additional operations have to be done. Please also note that harbour*.dll exports all Harbour functions marked as HB_EXPORT so it's possible to use also C code inside PCODE dll which uses full exported Harbour API. 2. when final application using PCODE dll is linked with in static mode. It's a little bit more complicated situation because in such case it's illegal to link PCODE dll with harbour shared library (harbour*.dll) and as I notice above with static libraries too. It's possible to link with above libraries but generated binaries will be wrong and can cause any unpredictable results so user has to be careful to not create them by mistake. Compiled PRG code needs two functions from the static part of application to wrok: hb_vmExecute() and hb_vmProcessSymbols(). These functions have to be exported by static part of application and the PCODE dll has to be linked with import library having them. We already have such import library and it's called hbmaindllp. It is written in a way which allows to link it also with PCODE dlls which are used by harbour applications linked in shared mode (I see that you nicely updated harbour*.dll names but it needs some minor cleanup yet to use these names, I'll commit it ASAP). So this part is ready and user only need Harbour static libraries which export above two functions. AFAIR by default they are not exported so it's necessary to recompile harbour exporting them. We can resolve this problem enabling symbol exporting also in default static builds or by introducing special wrappers in separate library which is not part of harbour*.dll. In such case it will be enough to link this new library with static part of application (using REQUEST mechanism to force linking) and update hbmaindllp to use this wrapped functions when original ones are not available (i.e. we can add _dll_ prefix for such wrapped function names. PCODE DLLs can be linked with final application or can be loaded dynamically. To load/unload dynamically any libraries always use HB_LIBLOAD()/HB_LIBFREE(). Never use WAPI_LOADLIBRARY()/WAPI_FREELIBRARY(), LOADLIBRARY()/FREELIBRARY(), DLLLOAD()/DLLUNLOAD() because they do not work correctly with HVM what can cause some very serious problems, i.e. it's not possible to cleanly unload PCODE dlls, these functions should be removed or wrapped to HB_LIBLOAD()/HB_LIBFREE()) > To do anything in this regard, first I should see > how pcode .dlls are supposed to work, linked, etc. See above. It should be whole description. > I also need to see if this is something Windows > specific or portable. The latter would certainly > make it more interesting to deal with. In Windows shared libraries cannot be created with late binding resolved at runtime and it causes that it's necessary to use import libraries. On most of other systems (but not all) dynamic runtime linker supports late binding so it's possible to create shared libraries with insufficient dependencies which are resolved at application startup or when function is called 1-st time. > In the meantime I'd suggest to consider to use > .hrb files instead. Unless there is the need to > include .c code in these pcode .dlls, they are > superior in all aspects, moreover they already work. We still do not support HRL (libraries for HRB files what in some cases can seriously reduce HRB functionality) anyhow HRB is portable and always preferred format which has also many features which are not available for DLLs. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Przemek, >> Sorry but I know nothing about pcode .dlls, hence >> there is no support for it in hbmk2 (yet?). I can't >> recall anyone doing any tests with this (besides me >> a while back, but without any results) > > I was creating them without any problems and from time to > time I made such tests together with HRB support. > As long as some of recent modification did not seriously > break sth then it should work without any problem. [...] > So this part is ready and user only need Harbour static libraries > which export above two functions. AFAIR by default they are not exported > so it's necessary to recompile harbour exporting them. > We can resolve this problem enabling symbol exporting also in default > static builds or by introducing special wrappers in separate library > which is not part of harbour*.dll. In such case it will be enough to > link this new library with static part of application (using REQUEST > mechanism to force linking) and update hbmaindllp to use this wrapped > functions when original ones are not available (i.e. we can add _dll_ > prefix for such wrapped function names. Okay and thank you very much. I'm afraid this topic falls beyond the threshold of my brain capacity and interest :( If it works using current tools, it's nice, and we probably have to do only those steps you mention to make it easily available for users. And document it. F.e. in INSTALL (if the end result is elegant or simple), or a separate document if the size of the topic deserves it. > PCODE DLLs can be linked with final application or can be loaded > dynamically. To load/unload dynamically any libraries always use > HB_LIBLOAD()/HB_LIBFREE(). Never use WAPI_LOADLIBRARY()/WAPI_FREELIBRARY(), > LOADLIBRARY()/FREELIBRARY(), DLLLOAD()/DLLUNLOAD() because they do > not work correctly with HVM what can cause some very serious problems, > i.e. it's not possible to cleanly unload PCODE dlls, these functions > should be removed or wrapped to HB_LIBLOAD()/HB_LIBFREE()) Pls remember that hbwin LoadLibrary/FreeLibrary functions are also used by other WAPI wrappers and pure (non-pcode) .dll support, so IMO we shouldn't remove or hide them, but simply document that pcode .dll must always be managed with HB_LIB*() functions. >> I also need to see if this is something Windows >> specific or portable. The latter would certainly >> make it more interesting to deal with. > > In Windows shared libraries cannot be created with late binding > resolved at runtime and it causes that it's necessary to use > import libraries. On most of other systems (but not all) dynamic > runtime linker supports late binding so it's possible to create > shared libraries with insufficient dependencies which are resolved > at application startup or when function is called 1-st time. Hmm... same applies as above, I'm trying to assemble the pieces of puzzle, but until I haven't seen or used these in practice, it's very difficult to digest it. I hope it better helps Leandro, though. >> In the meantime I'd suggest to consider to use >> .hrb files instead. Unless there is the need to >> include .c code in these pcode .dlls, they are >> superior in all aspects, moreover they already work. > > We still do not support HRL (libraries for HRB files what in > some cases can seriously reduce HRB functionality) anyhow HRB > is portable and always preferred format which has also many > features which are not available for DLLs. Amen. Now the only thing I'm still interested in, is what are the advantage of pcode-.dlls over .hrb files? [ I can only cite inclusion of .c functions. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi, On 2010 Feb 8, at 15:56, 2D Info - Leandro Damasio wrote: > Hi Viktor > >> Sorry but I know nothing about pcode .dlls, hence >> there is no support for it in hbmk2 (yet?). I can't >> recall anyone doing any tests with this (besides me >> a while back, but without any results) >> > > If you need a tester to this I would be glad to help. I'm working with > windows + hbmk2 + mingw. > >> To do anything in this regard, first I should see >> how pcode .dlls are supposed to work, linked, etc. >> I also need to see if this is something Windows >> specific or portable. The latter would certainly >> make it more interesting to deal with. > > I don't know if this is what you are talking about, but I could tell as a > high-level user what is the expected usage and behaviour if that be the case. > I just used pcode dlls in windows enviroment, so I don't know much about > their portability also, but I believe there shouldn't be any plataform > dependant issues below to hb_libload function in this case. I don't think > they can be a "build once run everywhere" solution, but they sure can be a > "code once run everywhere" solution. > >> In the meantime I'd suggest to consider to use >> .hrb files instead. Unless there is the need to >> include .c code in these pcode .dlls, they are >> superior in all aspects, moreover they already work. > > Yes, that can be very good, but I don't know anything about .hrb modules. Are > they compiled or interpreted in run-time? What is the usage? Is there any > limitations on .hrb modules (variable and function scope limitations, class > declaration limitations, mt limitations) compared to statically linked prg > modules beyond support to c code? Are there any examples or documentation on > repository ? I hope someone can answer these, but until then I suggest to lookup past messages, there has been _lots_ of detailed talk about .hrb files, even recently. You can start by looking up HB_HRB*() functions in ChangeLog and find examples in source tree. They are pretty handy and lots of Harbour users / developers are actively using them. [ Also see Przemek's recent message about pcode-dlls, though it seems we're both recommending .hrb files. ] Brgds, Viktor ___ 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:[13810] trunk/harbour
Viktor, Thanks for the huge conversion effort. Just to confirm that Rev. 13810 complied with BCC32 on WinNT with no errors or warnings, and hbtest show the usual results. Chen. ___ 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:[13810] trunk/harbour
Thanks you very much Chen. Brgds, Viktor On 2010 Feb 8, at 15:53, Chen Kedem wrote: > Viktor, > > Thanks for the huge conversion effort. > Just to confirm that Rev. 13810 complied with BCC32 on WinNT > with no errors or warnings, and hbtest show the usual results. > > Chen. > ___ > 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] Re: SF.net SVN: harbour-project:[13810] trunk/harbour
> Thanks for the huge conversion effort. +1 ___ 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:[13811] trunk/harbour
Revision: 13811 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13811&view=rev Author: vszakats Date: 2010-02-08 15:54:38 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 16:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h + Readded HB_U8 and HB_I8. Currently mapped to HB_BYTE/HB_CHAR, but it should be used where 8-bitness of a char is a requirement. F.e. when writing/reading to/from files. + HB_CHAR changed from 'char' to 'signed char'. This is brand new type, not yet used in Harbour code, so it's safe. For char with non-guaranteed signedness, ANSI type 'char' should be used. * HB_UCHAR is now a synonym for HB_BYTE. It's now also legacy. * HB_SCHAR is now a synonym for HB_CHAR. It's now also legacy. ; TODO: Replace all HB_SCHAR with HB_CHAR and HB_UCHAR with HB_BYTE, and move the old types to compatibility status. * ChangeLog ! Fixed date in my today's entries. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbdefs.h 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:[13811] trunk/harbour
On Mon, 08 Feb 2010, vszak...@users.sourceforge.net wrote: Hi Viktor, > * HB_UCHAR is now a synonym for HB_BYTE. It's now also legacy. > * HB_SCHAR is now a synonym for HB_CHAR. It's now also legacy. > ; TODO: Replace all HB_SCHAR with HB_CHAR and HB_UCHAR with HB_BYTE, > and move the old types to compatibility status. Code readability is also important and for people working with platforms where 'char' is always unsigned using HB_CHAR as synonym of 'signed char' will be seriously confusing so in my opinion it's bad idea. HB_CHAR should be synonym of 'char' without any fixed 'signed' or 'unsigned' definition. Otherwise we will have to make explicit casting between 'HB_CHAR *' types and 'char *' types, i.e. when we are calling OS functions. best regards, Przemek ___ 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:[13811] trunk/harbour
Hi Przemek, > On Mon, 08 Feb 2010, vszak...@users.sourceforge.net wrote: > > Hi Viktor, > >>* HB_UCHAR is now a synonym for HB_BYTE. It's now also legacy. >>* HB_SCHAR is now a synonym for HB_CHAR. It's now also legacy. >>; TODO: Replace all HB_SCHAR with HB_CHAR and HB_UCHAR with HB_BYTE, >>and move the old types to compatibility status. > > Code readability is also important and for people working with platforms > where 'char' is always unsigned using HB_CHAR as synonym of 'signed char' > will be seriously confusing so in my opinion it's bad idea. I thought of that, but IMO the only point in having special types is to give something more. In case of HB_CHAR being mapped to 'char' there is no point at all besides requiring to type more and add one more thing to worry about for developers. (Same goes to new HB_LONG actually). > HB_CHAR should be synonym of 'char' without any fixed 'signed' or > 'unsigned' definition. Otherwise we will have to make explicit casting > between 'HB_CHAR *' types and 'char *' types, i.e. when we are calling > OS functions. In this case, we could simply drop HB_CHAR, and also drop HB_BYTE and use HB_UCHAR and HB_SCHAR as the only types. Though I expect these to be less obvious for most users / developers. It took me a year to understand it, and while not all users are as slow-thinking as me, I'd still think that not many users will use HB_[U|S]CHAR because they won't easily grasp why/when they are useful. At the same time they could look for (and miss) HB_BYTE, especially since we always had BYTE in the past. [ Technically both kind of conversion can be done at the moment, though HB_BYTE -> HB_UCHAR conversion will take another half-day with lots of manual reformatting. ] Or, we can keep HB_BYTE and HB_SCHAR. (and drop HB_CHAR and HB_UCHAR) Any further elaboration? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_LONG / HB_ULONG
On Mon, 08 Feb 2010, Szak�ts Viktor wrote: Hi Viktor, > There is the known problem of HB_LONG, HB_ULONG > which should be the Harbour type name for former > LONG / ULONG types, but in the past it has been > used to denote largest integer type on given > platform. To be more precise. HB_LONG was used for HB_IT_LONG type. It's not largest integer on given platform but it's largest integer item used by HVM. > Now its superseded by HB_MAXINT, HB_MAXUINT, and > Harbour codebase has been changed to use it. It should be rather HB_VM[U]LONG or HB_VMMAX[U]INT though the exact meaning depends on context. In few places it should be HB_MAX[U]INT so it cannot be done by global S&R. Now it's not critical but when compilers using wider then 64bit integers will appear we will have to clean it. It's also possible to compile Harbour with strict Clipper HB_IT_INTEGER and HB_IT_LONG mapping and it also exploits the problem. It should be fixed in hbdefs.h and I'll make it soon so it's not a problem. > This means no Harbour code use HB_LONG and > HB_ULONG anymore. Thank you very much for your modifications. > I believe this type was not overused in > 3rd party code (I could only find a few placed > in LetoDB where it's used), so it's not big job to > update them where needed, and even by staying > compatible with older Harbour and even xhb version > (simply by creating new type HB_MAXINT/HB_MAXUINT). Yes, it is. In current LETO code HB_ULONG is used only for hb_dateMilliSec() but later casted to 'long' so in all windows builds and other 32bit build it's already stripped to 32bit integer. HB_LONG is used in context where it can be replaced by HB_MAXINT. > If we go this route, we may reuse HB_LONG and > HB_ULONG as replacements for LONG / ULONG. So > this would be a small breakage of compatibility, > but would give us clean and clear type naming > system. I'd vote to do this. For me it's very good choice. In the moment when we decided to add new types with 'HB_' prefix instead of using 'hb' (i.e. hbLong, hbInt, ... ) then we created potential conflicts with existing types using HB_ prefix like HB_LONG or HB_PCODE and we have to clean them. My opinion is that we should not leave any old types which may confuse users. Last modifications force code updating so let's change HB_[U]LONG too. IMO the worse situation is when such modificaitons tooks too much time and 3-rd party developers have to systematically update his code. Anyhow here we should clearly announce that: HB_[U]LONG _STOPS_ TO BE 64 BIT INTEGER. NOW IT'S 32 BIT INTEGER. because in this particular case the modification does not cause compile time errors. 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:[13812] trunk/harbour
Revision: 13812 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13812&view=rev Author: vouchcac Date: 2010-02-08 17:03:42 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 08:50 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/ideactions.prg * contrib/hbide/idedocks.prg * contrib/hbide/ideeditor.prg * contrib/hbide/ideobject.prg * contrib/hbide/idesources.prg * contrib/hbqt/generator/qt45.qtp * contrib/hbqt/hbqt.h * contrib/hbqt/hbqt_hbqplaintextedit.cpp * contrib/hbqt/hbqt_hbqplaintextedit.h * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp * contrib/hbqt/hbqt_hbqsyntaxhighlighter.h * contrib/hbqt/qtgui/filelist.mk * contrib/hbqt/qtgui/HBQPlainTextEdit.cpp * contrib/hbqt/qtgui/HBQSyntaxHighlighter.cpp + contrib/hbqt/qtgui/QStackedWidget.cpp * contrib/hbqt/qtgui/THBQPlainTextEdit.prg * contrib/hbqt/qtgui/THBQSyntaxHighlighter.prg + contrib/hbqt/qtgui/TQStackedWidget.prg * contrib/hbqt/qth/HBQPlainTextEdit.qth * contrib/hbqt/qth/HBQSyntaxHighLighter.qth + contrib/hbqt/qth/QStackedWidget.qth + Added one more class in hbQT. + Prepared to present multiple-views of tabbed-editor. The term multiple-view is a bit confusing. The concept I am thinking of is to present stacked tabs of common interest together switchable from "Editor" tree-presentation or from a combo-box containing such different "views". A better name to this feature is requested. % Code shifting, normalization. + Started to have block(column)copy and paste operation. But appears it is a huge task, probably leading to rewriting the whole HBQPlainTextEdit() class. I must confess that the more I try in the direction, the more I am in troubles. Reason: Qt does not provide any inbuild mechanism to achieve it. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbide/idedocks.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/ideobject.prg trunk/harbour/contrib/hbide/idesources.prg trunk/harbour/contrib/hbqt/generator/qt45.qtp trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.h trunk/harbour/contrib/hbqt/qtgui/HBQPlainTextEdit.cpp trunk/harbour/contrib/hbqt/qtgui/HBQSyntaxHighlighter.cpp trunk/harbour/contrib/hbqt/qtgui/THBQPlainTextEdit.prg trunk/harbour/contrib/hbqt/qtgui/THBQSyntaxHighlighter.prg trunk/harbour/contrib/hbqt/qtgui/filelist.mk trunk/harbour/contrib/hbqt/qth/HBQPlainTextEdit.qth trunk/harbour/contrib/hbqt/qth/HBQSyntaxHighLighter.qth Added Paths: --- trunk/harbour/contrib/hbqt/qtgui/QStackedWidget.cpp trunk/harbour/contrib/hbqt/qtgui/TQStackedWidget.prg trunk/harbour/contrib/hbqt/qth/QStackedWidget.qth 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:[13811] trunk/harbour
On Mon, 08 Feb 2010, Szak�ts Viktor wrote: > > Code readability is also important and for people working with platforms > > where 'char' is always unsigned using HB_CHAR as synonym of 'signed char' > > will be seriously confusing so in my opinion it's bad idea. > I thought of that, but IMO the only point in having > special types is to give something more. In case of > HB_CHAR being mapped to 'char' there is no point at > all besides requiring to type more and add one more > thing to worry about for developers. (Same goes to > new HB_LONG actually). and for HB_SHORT, HB_LONG, etc. If we added new types then they should be easy to use for users and not confuse them. When I see HB_SHORT which is mapped to 'short' and then I expect that HB_CHAR is mapped to 'char'. Sooner or later someone will use 'HB_CHAR *' instead of 'char *'. > > HB_CHAR should be synonym of 'char' without any fixed 'signed' or > > 'unsigned' definition. Otherwise we will have to make explicit casting > > between 'HB_CHAR *' types and 'char *' types, i.e. when we are calling > > OS functions. > In this case, we could simply drop HB_CHAR, and > also drop HB_BYTE and use HB_UCHAR and HB_SCHAR > as the only types. Though I expect these to be > less obvious for most users / developers. It took > me a year to understand it, and while not all users > are as slow-thinking as me, I'd still think that > not many users will use HB_[U|S]CHAR because they > won't easily grasp why/when they are useful. At > the same time they could look for (and miss) HB_BYTE, > especially since we always had BYTE in the past. BYTE also exists on some platform and its sign is undefined so HB_[U|S]CHAR is much more precise definition. Because we have to use OS API functions and these functions accepts text strings then we have to use corresponding types. It means that we need at least three types: signed - when needed signed iteger value storred in one character unsigned - when needed unsigned iteger value storred in one character undefined/raw - when needed text to pass to API function These are three different things. We can define for text 'char' type as we currently use in the code but in such case we should not have HB_CHAR at all because most of people will think it works like 'char' just like HB_SHORT works like 'short' and HB_USHORT works like 'unsigned short', etc. Please remember that types like [U]CHAR, [U]SHORT, [U]LONG, ... are very old types commonly used on different platforms and now when we redefined all such basic types with HB_ prefix people will not expect that HB_ prefix gives some special meaning for them so your proposition is creating exception. best regards, Przemek ___ 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:[13811] trunk/harbour
>>> HB_CHAR should be synonym of 'char' without any fixed 'signed' or >>> 'unsigned' definition. Otherwise we will have to make explicit casting >>> between 'HB_CHAR *' types and 'char *' types, i.e. when we are calling >>> OS functions. >> In this case, we could simply drop HB_CHAR, and >> also drop HB_BYTE and use HB_UCHAR and HB_SCHAR >> as the only types. Though I expect these to be >> less obvious for most users / developers. It took >> me a year to understand it, and while not all users >> are as slow-thinking as me, I'd still think that >> not many users will use HB_[U|S]CHAR because they >> won't easily grasp why/when they are useful. At >> the same time they could look for (and miss) HB_BYTE, >> especially since we always had BYTE in the past. > > BYTE also exists on some platform and its sign is undefined > so HB_[U|S]CHAR is much more precise definition. > Because we have to use OS API functions and these functions > accepts text strings then we have to use corresponding types. > It means that we need at least three types: > > signed - when needed signed iteger value storred in one character > unsigned - when needed unsigned iteger value storred in one character > undefined/raw - when needed text to pass to API function I'd only argue with the last of the three. In this case we don't need any Harbour types at all, since the API clearly defines the required type either with its own type or some ANSI types. IOW we don't need do maintain a matching Harbour type for all possibly existing APIs we can find. So we need signed and unsigned, and for 'raw' we have ANSI C 'char' or whatever the actual API offers (f.e. BYTE or TCHAR in Widows API) > These are three different things. We can define for text 'char' type > as we currently use in the code but in such case we should not have > HB_CHAR at all because most of people will think it works like 'char' > just like HB_SHORT works like 'short' and HB_USHORT works like > 'unsigned short', etc. Please remember that types like [U]CHAR, [U]SHORT, > [U]LONG, ... are very old types commonly used on different platforms > and now when we redefined all such basic types with HB_ prefix people > will not expect that HB_ prefix gives some special meaning for them > so your proposition is creating exception. I agree with that. So I conclude we don't need HB_CHAR. This leaves use with HB_BYTE vs. HB_UCHAR. They seem to be fuly equivalent, so which one should we choose? Or how do we define the difference? Brgds, Viktor ___ 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:[13813] trunk/harbour
Revision: 13813 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13813&view=rev Author: vszakats Date: 2010-02-08 17:35:30 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 18:25 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h + Changed HB_LONG and HB_ULONG to 'long' and 'unsigned long' 32-bit integer types, the new equivalents of legacy types LONG and ULONG. WARNING, INCOMPATIBLE: The legacy meaning of these types were 64-bit integers. Existing code should changes these types to HB_VMMAXINT, HB_VMMAXUINT respectively. Notice this change is non-delayable and non-togglable, so you must update your code now. - Deleted HB_CHAR type. * HB_UCHAR/HB_BYTE marked with QUESTION. - Deleted some commented new types. * contrib/hbbmcdx/bmdbfcdx.c + Attempt to sync with DBFCDX RDD source. Please try to help in this, there are some larger patches which I didn't apply. I'd be very nice if someone could take this code and convert it to a filter RDD instead of current copy+patch approach. In such case it could even be moved to core. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/include/hbdefs.h 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] Debugging c code
On Sun, 07 Feb 2010, April White wrote: Hi, > Przemek, I want to confirm something. I'm not yet using the new code > you wrote, so bear with me here. > If I allocate memory using hb_xgrab_fm() as you suggested before and > then call p1 = hb_itemNew(p2) if I do not release p1 the line > reported by FM statistics appears to be where hb_xgrab_fm() is > called. This is what I believe I am seeing, can you confirm this? It depends on few different things. By default when HB_TR_LEVEL is not set to HB_TR_DEBUG hb_traceset( HB_TR_FM, szFile, iLine, NULL ); set's the information about file and line used by the nearest call to hb_xgrab()/hb_xalloc() and after using it it's reset so it can be used only once. In such case if you make: hb_traceset( HB_TR_FM, "MYFILE", 123, NULL ); ptr = hb_xgrab( 100 ); // use MYFILE:123 set above pItem = hb_itemNew( NULL ); // use PROCNAME():PROCLINE() but if you make: hb_traceset( HB_TR_FM, "MYFILE", 123, NULL ); ptr = hb_xgrab( 100 ); // use MYFILE:123 hb_traceset( HB_TR_FM, "MYFILE2", 125, NULL ); pItem = hb_itemNew( NULL ); // use MYFILE2:125 then 1-st memory block allocated by hb_xgrab()/hb_xalloc() inside hb_itemNew() will use MYFILE2:125 and next ones (if any) will use PROCNAME():PROCLINE(). If you set HB_TR_LEVEL to HB_TR_DEBUG then hb_traceset() will set default file and line number for all blocks until next call to hb_traceset() or HB_TRACE() message in C code because compiled into final code HB_TRACE() messages (not stripped but C macrocompiler) overwrite values set by hb_traceset(). So you described situation which happens when core code is compiled without HB_TRACE() debug messages (default) and you set HB_TR_LEVEL envvar to HB_TR_DEBUG. BTW you can define macro HB_FM_MARKER and use it in your code before functions which allocates memory: #ifdef DEBUG #define HB_FM_MARKER hb_traceset( HB_TR_FM, __FILE__, __LINE__, NULL ); #else #define HB_FM_MARKER #endif [...] HB_FM_MARKER ptr = hb_xgrab( 100 ); HB_FM_MARKER pItem = hb_itemNew( NULL ); 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:[13814] trunk/harbour
Revision: 13814 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13814&view=rev Author: vszakats Date: 2010-02-08 17:41:27 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 18:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbbmcdx/bmdbfcdx.c * Some more syncing. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.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:[13815] trunk/harbour
Revision: 13815 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13815&view=rev Author: vszakats Date: 2010-02-08 18:04:28 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 19:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/gtwin/gtwin.c * ULONG -> HB_SIZE * src/rtl/gtwvt/gtwvt.c * LONG -> int * ULONG -> HB_SIZE * contrib/gtwvg/gtwvg.c * contrib/gtwvg/wvggui.c * LONG -> int * ULONG -> HB_SIZE * contrib/gtwvg/wvgwin.c * ULONG -> HB_ULONG * LONG -> long * contrib/gtwvg/wvgutils.c * contrib/gtwvg/wvgsink.c * contrib/gtwvg/wvgwing.c * contrib/hbwin/axcore.c * LONG -> long * contrib/gtwvg/wvgutils.c * "" -> NULL Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/wvggui.c trunk/harbour/contrib/gtwvg/wvgsink.c trunk/harbour/contrib/gtwvg/wvgutils.c trunk/harbour/contrib/gtwvg/wvgwin.c trunk/harbour/contrib/gtwvg/wvgwing.c trunk/harbour/contrib/hbwin/axcore.c trunk/harbour/src/rtl/gtwin/gtwin.c trunk/harbour/src/rtl/gtwvt/gtwvt.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:[13816] trunk/harbour
Revision: 13816 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13816&view=rev Author: vszakats Date: 2010-02-08 18:54:32 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 19:52 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/macro.c * src/vm/runner.c * src/vm/estack.c * src/vm/codebloc.c * src/vm/debug.c * src/vm/hvm.c * src/vm/pvalue.c * src/vm/arrays.c * src/vm/memvars.c * src/vm/eval.c * src/vm/classes.c * src/common/hbffind.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/workarea.c * src/rdd/sdf1.c * src/rdd/dbcmdx.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbcmd.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/delim1.c * src/rdd/dbf1.c * src/rdd/usrrdd/usrrdd.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxord.c * src/compiler/hbmain.c * src/compiler/hbpcode.c * src/compiler/genc.c * src/compiler/hbopt.c * src/compiler/gencc.c * src/compiler/hblbl.c * tests/bldtest/bldtest.c * include/hbstack.h * include/hbapifs.h * include/hbxvm.h * include/hbdefs.h * include/hbmacro.h * include/hbapi.h * include/hbcomp.h * include/hbapirdd.h * include/hbsxfunc.h * include/hbrddcdx.h * include/hbexprb.c * contrib/hbct/maxline.c * contrib/hbct/numcount.c * contrib/hbct/addascii.c * contrib/xhb/xhbenum.c * contrib/xhb/xhbqself.c * contrib/xhb/xhbwith.c * contrib/xhb/hbcomprs.c * contrib/xhb/xhbmsgs.c * contrib/hbmzip/hbmzip.c * contrib/xpp/dbcmdx.c * contrib/hbnetio/netiocli.c * contrib/rddsql/sqlbase.c * contrib/rddsql/sqlmix.c * contrib/rddads/adsx.c * contrib/rddads/ads1.c * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbmcdx/hbbmcdx.h * contrib/hbbtree/hb_btree.h * contrib/hbbtree/hb_btree.c * LONG -> HB_LONG, long (for dates and extend / item API contexts) (except for external (OS) API specific usage) * src/vm/maindll.c * LONG -> void * + Added 'const' to char * parameter. * contrib/hbct/numline.c * contrib/hbct/ctpad.c * LONG -> HB_LONG, HB_ISIZ * Formatting. * contrib/xhb/hbxml.h * LONG -> HB_ISIZ * contrib/xhb/freadlin.c * LONG, int -> HB_ISIZ Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbmcdx/hbbmcdx.h trunk/harbour/contrib/hbbtree/hb_btree.c trunk/harbour/contrib/hbbtree/hb_btree.h trunk/harbour/contrib/hbct/addascii.c trunk/harbour/contrib/hbct/ctpad.c trunk/harbour/contrib/hbct/maxline.c trunk/harbour/contrib/hbct/numcount.c trunk/harbour/contrib/hbct/numline.c trunk/harbour/contrib/hbmzip/hbmzip.c trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/rddads/ads1.c trunk/harbour/contrib/rddads/adsx.c trunk/harbour/contrib/rddsql/sqlbase.c trunk/harbour/contrib/rddsql/sqlmix.c trunk/harbour/contrib/xhb/freadlin.c trunk/harbour/contrib/xhb/hbcomprs.c trunk/harbour/contrib/xhb/hbxml.h trunk/harbour/contrib/xhb/xhbenum.c trunk/harbour/contrib/xhb/xhbmsgs.c trunk/harbour/contrib/xhb/xhbqself.c trunk/harbour/contrib/xhb/xhbwith.c trunk/harbour/contrib/xpp/dbcmdx.c trunk/harbour/include/hbapi.h trunk/harbour/include/hbapifs.h trunk/harbour/include/hbapirdd.h trunk/harbour/include/hbcomp.h trunk/harbour/include/hbdefs.h trunk/harbour/include/hbexprb.c trunk/harbour/include/hbmacro.h trunk/harbour/include/hbrddcdx.h trunk/harbour/include/hbstack.h trunk/harbour/include/hbsxfunc.h trunk/harbour/include/hbxvm.h trunk/harbour/src/common/hbffind.c trunk/harbour/src/compiler/genc.c trunk/harbour/src/compiler/gencc.c trunk/harbour/src/compiler/hblbl.c trunk/harbour/src/compiler/hbmain.c trunk/harbour/src/compiler/hbopt.c trunk/harbour/src/compiler/hbpcode.c trunk/harbour/src/rdd/dbcmd.c trunk/harbour/src/rdd/dbcmdx.c trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/dbfntx/dbfntx1.c trunk/harbour/src/rdd/delim1.c trunk/harbour/src/rdd/hbsix/sxord.c trunk/harbour/src/rdd/sdf1.c trunk/harbour/src/rdd/usrrdd/usrrdd.c trunk/harbour/src/rdd/workarea.c trunk/harbour/src/vm/arrays.c trunk/harbour/src/vm/classes.c trunk/harbour/src/vm/codebloc.c trunk/harbour/src/vm/debug.c trunk/harbour/src/vm/estack.c trunk/harbour/src/vm/eval.c trunk/harbour/src/vm/hvm.c trunk/harbour/src/vm/macro.c trunk/harbour/src/vm/maindll.c trunk/harbour/src/vm/memvars.c trunk/harbour/src/vm/pvalue.c trunk/harbour/src/vm/runner.c trunk/harbour/tests/bldtest/bldtest.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
[Harbour] SF.net SVN: harbour-project:[13817] trunk/harbour
Revision: 13817 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13817&view=rev Author: druzus Date: 2010-02-08 19:24:22 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 20:24 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapicdp.h * harbour/src/rtl/cdpapi.c * replaced 'unsigned char' with 'HB_UCHAR' * harbour/src/rtl/cdpapihb.c * harbour/contrib/hbwin/wapi_shellapi.c % minor optimization * harbour/src/vm/maindllp.c * use already existing HB_MACRO2STRING() macro instead of locally defined HB_DLLSTR_() * respect defined but not used so far HB_DLL_NAMEMT and HB_DLL_NAMEMT2 Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/wapi_shellapi.c trunk/harbour/include/hbapicdp.h trunk/harbour/src/rtl/cdpapi.c trunk/harbour/src/rtl/cdpapihb.c trunk/harbour/src/vm/maindllp.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] How to build and use pCode DLL with hbmk2
Hi I was creating them without any problems and from time to time I made such tests together with HRB support. As long as some of recent modification did not seriously break sth then it should work without any problem. The most important rule which users have to always remember: it's illegal to link PCODE dll and any other DLLs with Harbour static functions. If you make that then the same code is linked twice so it may not work as expected, i.e. two independent HVM stacks. This same is for any other projects and code so it's rather basic knowledge about using shared libraries in Windows. It also means that fully functional Harbour distribution should have shared version of all libraries or at least provide easy way I don't know if I reach the point you are talking about, but in the xHarbour scenario I mentioned before apparently it wasn't needed to resolve all the references to any functions statically linked to the host executable, because these references were intended to be resolved in runtime. Inside hb_vmRegisterSymbols we inserted a hack to resolve the undefined references both in the DLL and in the host aplication: if the symbol in the DLL had an unresolved pointer (DEAD address), we searched for its name in the host symbol table and replaced the DEAD pointer for a resolved one, and when the symbol was resolved in the DLL but not in the host symbol table we fixed its address in the host symbol table, replacind the DEAD address for the DLL resolved address. IOW, if the same symbol was in the DLL and in the host and was undefined in one of them, we fixed it, otherwise, we let go. Does it make sense to you? Does this already apply to Harbour? It seems to work like this using Blinker, and it offered yet the option to replace or not to replace a doubly defined symbol when loading the DLL, but we couldn't implement it unfortunatelly. There are two possible methods to create PCODE dll. 1. when final application using PCODE dll is linked in shared mode with harbour*.dll. In such case it's enough to link the PCODE dll with exactly the same harbour*.dll. That's all. No additional operations have to be done. Please also note that harbour*.dll exports all Harbour functions marked as HB_EXPORT so it's possible to use also C code inside PCODE dll which uses full exported Harbour API. That is not my case of use - we use harbour self contained executable + pCode dll. 2. when final application using PCODE dll is linked with in static mode. It's a little bit more complicated situation because in such case it's illegal to link PCODE dll with harbour shared library (harbour*.dll) and as I notice above with static libraries too. It's possible to link with above libraries but generated binaries will be wrong and can cause any unpredictable results so user has to be careful to not create them by mistake. Compiled PRG code needs two functions from the static part of application to wrok: hb_vmExecute() and hb_vmProcessSymbols(). These functions have to be exported by static part of application and the PCODE dll has to be linked with import library having them. We already have such import library and it's called hbmaindllp. It is written in a way which allows to link it also with PCODE dlls which are used by harbour applications linked in shared mode (I see that you nicely updated harbour*.dll names but it needs some minor cleanup yet to use these names, I'll commit it ASAP). So this part is ready and user only need Harbour static libraries which export above two functions. AFAIR by default they are not exported so it's necessary to recompile harbour exporting them. In xHarbour 0.9 it seems that hb_vmProcessSymbols and hb_vmExecute were declared inside maindllp.c but just as wrappers to (VM_DLL_EXECUTE) macro. Is this part of the same metodology you described? We can resolve this problem enabling symbol exporting also in default static builds or by introducing special wrappers in separate library which is not part of harbour*.dll. In such case it will be enough to link this new library with static part of application (using REQUEST mechanism to force linking) and update hbmaindllp to use this wrapped functions when original ones are not available (i.e. we can add _dll_ prefix for such wrapped function names. PCODE DLLs can be linked with final application or can be loaded dynamically. To load/unload dynamically any libraries always use HB_LIBLOAD()/HB_LIBFREE(). Never use WAPI_LOADLIBRARY()/WAPI_FREELIBRARY(), LOADLIBRARY()/FREELIBRARY(), DLLLOAD()/DLLUNLOAD() because they do not work correctly with HVM what can cause some very serious problems, i.e. it's not possible to cleanly unload PCODE dlls, these functions should be removed or wrapped to HB_LIBLOAD()/HB_LIBFREE()) To do anything in this regard, first I should see how pcode .dlls are supposed to work, linked, etc. See above. It should be whole descripti
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hello Viktor I hope someone can answer these, but until then I suggest to lookup past messages, there has been _lots_ of detailed talk about .hrb files, even recently. You can start by looking up HB_HRB*() functions in ChangeLog and find examples in source tree. Thanks a lot. I'll follow your suggestion for a start. They are pretty handy and lots of Harbour users / developers are actively using them. [ Also see Przemek's recent message about pcode-dlls, though it seems we're both recommending .hrb files. ] Sure! If there be another (maybe better) way to solve the same problem (dynamically load of prg code) I'll be very satisfied. HRB funcionality sounds great, but they seem to work as loadable modules, not libraries right? If hrb have no important limitations and performance issues compared to statically linked code and If one could manage the load/unload of lots of hrb modules at once, it would have definitelly no use for pcode DLLs at all. HRB libraries could be a perfect crossplatform solution for many people. Best regards Leandro ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
On Mon, 08 Feb 2010, Szak�ts Viktor wrote:
Hi Viktor,
> If it works using current tools, it's nice, and we probably
> have to do only those steps you mention to make it easily
> available for users. And document it. F.e. in INSTALL (if
> the end result is elegant or simple), or a separate document
> if the size of the topic deserves it.
I agree though I do not now if I'm right person to describe it
in INSTALL. For shared binaries using harbour*.dll there is
no problem at all and it's enough to link PCODE dll with harbour*.dll.
The problem is only with binaries which have HVM linked with static
part of application. In the previous message I forgot to write that
also functions called in PRG code compiled to PCODE DLL creates
dependencies so programmer should declare them using DYNAMIC clause.
He can generate header file with all functions which are visible
for core part of his application using this code:
#if 0// uncomment it for tests */
proc main()
genFuncList()
return
#endif
proc genFuncList()
local aFunc, hFile
aFunc := getFuncList()
asort( aFunc )
hFile := fcreate("dynamic.ch")
aeval( aFunc, {|x| fwrite( hFile, "DYNAMIC " + x + hb_osNewLine() ) } )
fclose( hFile )
return
func getFuncList()
local aFunc, nCount := __dynsCount(), nDst:=0, n
aFunc := array( nCount )
for n := 1 to nCount
if __dynsIsFun( n )
aFunc[ ++nDst ] := __dynsGetName( n )
endif
next
asize( aFunc, nDst )
return aFunc
and then simply #include it in .prg files compiled and linked into
PCODE dlls.
Probably to make it easier for users we can add small option to hbmk2
which will attach to final code exported wrappers to hb_vmProcessSymbols()
and hb_vmExecute() or single function which can be used to extract
addresses of other functions so later it will be enough to extend
the list of pseudo exported symbols without touching hbmk2 code.
I can create such function.
> > PCODE DLLs can be linked with final application or can be loaded
> > dynamically. To load/unload dynamically any libraries always use
> > HB_LIBLOAD()/HB_LIBFREE(). Never use WAPI_LOADLIBRARY()/WAPI_FREELIBRARY(),
> > LOADLIBRARY()/FREELIBRARY(), DLLLOAD()/DLLUNLOAD() because they do
> > not work correctly with HVM what can cause some very serious problems,
> > i.e. it's not possible to cleanly unload PCODE dlls, these functions
> > should be removed or wrapped to HB_LIBLOAD()/HB_LIBFREE())
>
> Pls remember that hbwin LoadLibrary/FreeLibrary functions
> are also used by other WAPI wrappers and pure (non-pcode)
> .dll support, so IMO we shouldn't remove or hide them, but
> simply document that pcode .dll must always be managed with
> HB_LIB*() functions.
Such documentation will not help users who do not know if some 3-rd
party libraries contains PRG code or not so it's useless and IMO makes
thing more complicated then necessary. The only one thing we should
made is redirecting above functions to HB_LIB*() ones which in windows
builds internally use the same WIN API functions and only have additional
code to protect HVM against corruption in MT mode, allow clean unloading
and execute INIT/EXIT PRG functions if any. The returned handles can be
used as any other GC pointer items used by HBWIN code. If necessary
we can add to HVM public function to extract library handle from
PHB_ITEM. Please also note that destructor for HB_LIBLOAD() GC pointer
items does not unload library automatically so it will work as current
functions even if user does not save it somewhere.
> Now the only thing I'm still interested in, is what
> are the advantage of pcode-.dlls over .hrb files?
> [ I can only cite inclusion of .c functions. ]
Yes, mixed PRG and C code is probably the only one real feature.
Probably it's mostly important for 3-rd party extensions which can
be distributed as single DLL. For .prg code only HRB files seem to
be much better solution though support for HRL files with optional
conversion of all internal bindings to static when HRL is loaded
will make it even more flexible for big projects.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Leandro, On 2010 Feb 8, at 21:43, 2D Info - Leandro Damasio wrote: > Hello Viktor > >> I hope someone can answer these, but until then I suggest >> to lookup past messages, there has been _lots_ of detailed >> talk about .hrb files, even recently. You can start by >> looking up HB_HRB*() functions in ChangeLog and find examples >> in source tree. > > Thanks a lot. I'll follow your suggestion for a start. > >> They are pretty handy and lots of Harbour users / developers >> are actively using them. >> >> [ Also see Przemek's recent message about pcode-dlls, >> though it seems we're both recommending .hrb files. ] > > Sure! If there be another (maybe better) way to solve the same problem > (dynamically load of prg code) I'll be very satisfied. > HRB funcionality sounds great, but they seem to work as loadable modules, not > libraries right? From the application POV they look the same, you load it by specifying the filename, and execute functions from it. You have much finer control with .hrb, it's also portable, and .hrb files are very simple to generate (either with hbmk2 or harbour compiler). > If hrb have no important limitations and performance issues compared to > statically linked code and If one could manage the load/unload of lots of hrb > modules at once, it would have definitelly no use for pcode DLLs at all. HRB > libraries could be a perfect crossplatform solution for many people. Perfectly said. I don't know of any limitation. I'd suggest you to explore the loading / execution options. There may be some extreme situations which you need take extra care of (see Lorenzo's recent messages). These aspects are not .hrb specific limitations, but general issues that need to be dealt with when dynamically loading/unloading pcode modules via any methods. In Harbour contrib/hbnetio/utils/netiosrv and examples/httpsrv already make use of .hrb files in real example. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] GETREADER() oGet:postBlock / oGet type functions and blocks in Clipper 5.3 / Harbour?
Hi. After a bit of research, I see in the Norton Guides some reference to a bunch of objGet / oGet type functions. In our Clipper 5.2e APP, we have a GETSYS.PRG which seems to implement a lot of these functions. My guess is that Clipper 5.3 decided to make these functions part of the core, instead of giving you a GETSYS.PRG template? Anyways, the problem we're having is on line 157 of the following code. It hangs when a NIL is returned by the postBlock block. (I have no idea what / where the postBlock is even declared, as mentioned in my post to the Users maillist: http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html). To add a bit more confusion, I am not sure in Harbour / Clipper 5.3 you have to have this "getsys.prg" file. It seems we need for what we are doing, as you can see an added line of code on line 152 where my superior added some cursor modifications. My first guess would be to simply add some sort of VALTYPE == "L" check prior to doing the IF statement, but I am not sure if this is a problem with Harbour, or our own code. I thought I would ask here. If my post makes no sense to the developers, I will try to provide more code / info. Thanks in advance. 135 PROCEDURE GetReader( oGet ) 136 137// Read the GET if the WHEN condition is satisfied 138IF ( GetPreValidate( oGet ) ) 139 140 // Activate the GET for reading 141 oGet:setFocus() 142 143 WHILE ( oGet:exitState == GE_NOEXIT ) 144 145 // Check for initial typeout (no editable positions) 146 IF ( oGet:typeOut ) 147 oGet:exitState := GE_ENTER 148 ENDIF 149 150 // Apply keystrokes until exit 151 WHILE ( oGet:exitState == GE_NOEXIT ) 152 SETCURSOR(IIF( SET(_SET_INSERT),2,1)) // MIKE ADDED TO CHANGE CURSOR SHAPE 153 GetApplyKey( oGet, inkey( 0 ) ) 154 ENDDO 155 156 // Disallow exit if the VALID condition is not satisfied 157 IF ( !GetPostValidate( oGet ) ) 158 oGet:exitState := GE_NOEXIT 159 ENDIF 160 ENDDO 161 162 // De-activate the GET 163 oGet:killFocus() 164 165ENDIF 166 167RETURN 168 -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Przemek,
>> If it works using current tools, it's nice, and we probably
>> have to do only those steps you mention to make it easily
>> available for users. And document it. F.e. in INSTALL (if
>> the end result is elegant or simple), or a separate document
>> if the size of the topic deserves it.
>
> I agree though I do not now if I'm right person to describe it
> in INSTALL. For shared binaries using harbour*.dll there is
> no problem at all and it's enough to link PCODE dll with harbour*.dll.
> The problem is only with binaries which have HVM linked with static
> part of application. In the previous message I forgot to write that
> also functions called in PRG code compiled to PCODE DLL creates
> dependencies so programmer should declare them using DYNAMIC clause.
> He can generate header file with all functions which are visible
> for core part of his application using this code:
>
> #if 0// uncomment it for tests */
> proc main()
> genFuncList()
> return
> #endif
>
> proc genFuncList()
> local aFunc, hFile
> aFunc := getFuncList()
> asort( aFunc )
> hFile := fcreate("dynamic.ch")
> aeval( aFunc, {|x| fwrite( hFile, "DYNAMIC " + x + hb_osNewLine() ) } )
> fclose( hFile )
> return
>
> func getFuncList()
> local aFunc, nCount := __dynsCount(), nDst:=0, n
> aFunc := array( nCount )
> for n := 1 to nCount
> if __dynsIsFun( n )
>aFunc[ ++nDst ] := __dynsGetName( n )
> endif
> next
> asize( aFunc, nDst )
> return aFunc
>
> and then simply #include it in .prg files compiled and linked into
> PCODE dlls.
>
> Probably to make it easier for users we can add small option to hbmk2
> which will attach to final code exported wrappers to hb_vmProcessSymbols()
> and hb_vmExecute() or single function which can be used to extract
> addresses of other functions so later it will be enough to extend
> the list of pseudo exported symbols without touching hbmk2 code.
> I can create such function.
Okay we can do it. I'll also need a name proposal for
such hbmk2 option. Or maybe a new main switch instead of
-hbdyn (like -hbdynvm ?) which also turns on this extra
feature automatically, but a good name would be nice
even for this case.
>>> PCODE DLLs can be linked with final application or can be loaded
>>> dynamically. To load/unload dynamically any libraries always use
>>> HB_LIBLOAD()/HB_LIBFREE(). Never use WAPI_LOADLIBRARY()/WAPI_FREELIBRARY(),
>>> LOADLIBRARY()/FREELIBRARY(), DLLLOAD()/DLLUNLOAD() because they do
>>> not work correctly with HVM what can cause some very serious problems,
>>> i.e. it's not possible to cleanly unload PCODE dlls, these functions
>>> should be removed or wrapped to HB_LIBLOAD()/HB_LIBFREE())
>>
>> Pls remember that hbwin LoadLibrary/FreeLibrary functions
>> are also used by other WAPI wrappers and pure (non-pcode)
>> .dll support, so IMO we shouldn't remove or hide them, but
>> simply document that pcode .dll must always be managed with
>> HB_LIB*() functions.
>
> Such documentation will not help users who do not know if some 3-rd
> party libraries contains PRG code or not so it's useless and IMO makes
> thing more complicated then necessary. The only one thing we should
> made is redirecting above functions to HB_LIB*() ones which in windows
> builds internally use the same WIN API functions and only have additional
> code to protect HVM against corruption in MT mode, allow clean unloading
> and execute INIT/EXIT PRG functions if any. The returned handles can be
> used as any other GC pointer items used by HBWIN code. If necessary
> we can add to HVM public function to extract library handle from
> PHB_ITEM. Please also note that destructor for HB_LIBLOAD() GC pointer
> items does not unload library automatically so it will work as current
> functions even if user does not save it somewhere.
I see. In case HB_LIB*() is a superset of other hbwin
specific loaders, I agree to drop those. (convert them
to stubs). For sure DLLLOAD() is an Xbase++ compatibility
function so we should keep it as such, and this way we
could even move it to core.
>> Now the only thing I'm still interested in, is what
>> are the advantage of pcode-.dlls over .hrb files?
>> [ I can only cite inclusion of .c functions. ]
>
> Yes, mixed PRG and C code is probably the only one real feature.
> Probably it's mostly important for 3-rd party extensions which can
> be distributed as single DLL. For .prg code only HRB files seem to
Though even this can only be done if said .dll doesn't depend
on other 3rd party .dlls. So in case the .c code implements
some wrappers (which is typical), the underlying API needs to be
linked to the pcode .dll statically. If I see it correctly.
> be much better solution though support for HRL files with optional
> conversion of all internal bindings to static when HRL is loaded
> will make it even more flexible for big projects.
Agreed. I'm not ye
[Harbour] SF.net SVN: harbour-project:[13818] trunk/harbour
Revision: 13818 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13818&view=rev Author: vszakats Date: 2010-02-08 21:52:47 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 22:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/pp/ppcore.c * src/pp/hbpp.c * src/vm/macro.c * src/vm/runner.c * src/vm/estack.c * src/vm/itemapi.c * src/vm/hvm.c * src/vm/cmdarg.c * src/vm/maindllp.c * src/vm/fm.c * src/vm/thread.c * src/vm/memvars.c * src/vm/eval.c * src/vm/extend.c * src/vm/classes.c * src/debug/dbgentry.c * src/common/expropt1.c * src/common/expropt2.c * src/common/hbhash.c * src/nortl/nortl.c * src/macro/macrolex.c * src/rtl/gtxwc/gtxwc.c * src/rtl/gtstd/gtstd.c * src/rtl/gtcgi/gtcgi.c * src/rtl/errapi.c * src/rtl/hbprocfn.c * src/rtl/hbsocket.c * src/rtl/gtpca/gtpca.c * src/rtl/filebuf.c * src/rtl/hbproces.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/dbsql.c * src/rdd/hbdbsort.c * src/rdd/workarea.c * src/rdd/wacore.c * src/rdd/sdf1.c * src/rdd/dbcmdx.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbcmd.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/delim1.c * src/rdd/dbf1.c * src/rdd/hsx/hsx.c * src/rdd/usrrdd/usrrdd.c * src/rdd/wafunc.c * src/rdd/dbffpt/dbffpt1.c * src/rdd/hbsix/sxord.c * src/rdd/hbsix/sxfname.c * src/rdd/hbsix/sxtable.c * src/rdd/hbsix/sxutil.c * src/rdd/hbsix/sxcrypt.c * src/compiler/ppcomp.c * src/compiler/hbmain.c * src/compiler/compi18n.c * src/compiler/cmdcheck.c * src/compiler/hbdbginf.c * src/compiler/hbpcode.c * src/compiler/genhrb.c * src/compiler/hbdead.c * src/compiler/complex.c * src/compiler/genobj32.c * src/compiler/genc.c * src/compiler/hbopt.c * src/compiler/hbident.c * src/compiler/gencc.c * src/compiler/hbcmplib.c * src/compiler/hblbl.c * src/compiler/harbour.yyc * src/compiler/harbour.y * include/hbpp.h * include/hbrdddbf.h * include/hbvmpub.h * include/hbrddnsx.h * include/hbstack.h * include/hbgtcore.h * include/hbapifs.h * include/hbthread.h * include/hbdefs.h * include/hbmacro.h * include/hbinit.h * include/hbtypes.h * include/hbrddsdf.h * include/hbapi.h * include/hbapiitm.h * include/hbrddntx.h * include/hbvm.h * include/hbapidbg.h * include/hbcomp.h * include/hbapirdd.h * include/hbcompdf.h * include/hbrdddel.h * include/hbexpra.c * include/hbexprop.h * include/hbrddcdx.h * include/hbapicls.h * include/hbapierr.h * include/hbrddfpt.h * include/hbhash.h * include/hbregex.h * include/hbexprb.c * contrib/hbct/screen2.c * contrib/hbct/token2.c * contrib/hbct/dbftools.c * contrib/hbct/atadjust.c * contrib/hbct/ctwin.c * contrib/hbct/files.c * contrib/hbct/dattime3.c * contrib/hbct/ctstr.c * contrib/hbct/screen1.c * contrib/hbct/token1.c * contrib/hbct/ctc.c * contrib/hbct/ct.h * contrib/hbct/atnum.c * contrib/hbct/asciisum.c * contrib/hbct/numat.c * contrib/hbct/atrepl.c * contrib/xhb/bkgtsks.c * contrib/xhb/hbcrypt.c * contrib/xhb/fparse.c * contrib/xhb/datesxhb.c * contrib/xhb/hbnxs.h * contrib/hbqt/gtqtc/gtqtc.cpp * contrib/xpp/dbcmdx.c * contrib/hbnf/dispc.c * contrib/hbnf/ftattr.c * contrib/hbmemio/memio.c * contrib/hbnetio/netiocli.c * contrib/rddsql/sddmy/mysqldd.c * contrib/rddsql/sddpg/pgsqldd.c * contrib/rddsql/sddfb/fbirddd.c * contrib/rddsql/sddodbc/odbcdd.c * contrib/rddsql/hbrddsql.h * contrib/rddsql/sqlbase.c * contrib/rddsql/sqlmix.c * contrib/rddads/adsx.c * contrib/rddads/adsfunc.c * contrib/rddads/rddads.h * contrib/rddads/ads1.c * contrib/rddads/adsmgmnt.c * contrib/hbmisc/spd.c * contrib/hbtip/utils.c * contrib/hbtip/encmthd.c * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbmcdx/hbbmcdx.h * contrib/hbbtree/hb_btree.h * contrib/hbbtree/hb_btree.c * ULONG -> HB_ULONG, HB_SIZE (except for external (OS) API specific usage) * Formatting. ; NOTE: I converted ULONG to HB_SIZE where I felt it appropriate, but didn't touch compiler, codeblock handling, low-level RDD (Set/GetVarLen method) and high-level contrib RDDs, so this needs to be cleaned. Also there may be cases where I didn't change the whole call chain to HB_SIZE. ; NOTE: It would be probably worthy to add new types for these purposes: - line number (HB_USHORT) - record number (HB_ULONG) - RDD connection (HB_ULONG) - parameter count / stack position / class member positions / etc (HB_USHORT, sometimes HB_ULONG) - pcode (HB_BYTE and char) - flags / modes (HB_USHORT / HB_ULONG) - timers (HB_ULONG, HB_MAXINT) - GT API character (HB_USHORT) ; REQUESTS: - Pls don't over-align variable declarations. It makes modification much much slower. Sometimes declarations are aligned even if there w
[Harbour] oGet problems solved... because Harbour was Warning me for no reason!
Dear Harbour,
I have solved the whole oGet problems I was having, referenced by both of
the URLs below of the mailing list.
http://lists.harbour-project.org/pipermail/harbour/2010-February/031851.html
http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html
The problem was Harbour was Warning me about useless vals.
3:28 PM 2/5/2010
GL.PRG(419) Warning W0027 Meaningless use of expression 'String'
GL2.PRG(1460) Warning W0027 Meaningless use of expression 'String'
GL2.PRG(1469) Warning W0027 Meaningless use of expression 'String'
DATPROMO.PRG(10) Warning W0027 Meaningless use of expression 'String'
ORDERS.PRG(794) Warning W0027 Meaningless use of expression 'Logical'
ORDERS.PRG(2034) Warning W0027 Meaningless use of expression 'Logical'
RECONCIL.PRG(1029) Warning W0027 Meaningless use of expression 'String'
RECONCIL.PRG(1035) Warning W0027 Meaningless use of expression 'String'
CRMAIN.PRG(1837) Warning W0027 Meaningless use of expression 'Logical'
CRAUX2.PRG(78) Warning W0027 Meaningless use of expression 'Logical'
CRAUX2.PRG(465) Warning W0027 Meaningless use of expression 'String'
PROCESS.PRG(1497) Warning W0027 Meaningless use of expression 'String'
PROCESS.PRG(1510) Warning W0027 Meaningless use of expression 'String'
Phone.prg(5) Warning W0027 Meaningless use of expression 'String'
Turns out, these were not meaningless. They were in EVAL lines of code
where the "useless" value was needed to get the oGet stuff to work
properly. An example of a line of code:
Valid !lGiftCard .and. (lNegPrice .or. !CRPrice<0) .and.
iif(lNew.and.CRPrice#0,Eval({||SpecialPrice:=.t.,SetPrice:=SpecialPrice,.t.}),.t.)
As soon as I take out the "Meaningless" val, the warning stops when
compiling, but our .PRG hangs when the getReader() function is called and
breaks.
Maybe this could be considered a bug in Harbour, where it is warning me for
no reason?
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] oGet problems solved... because Harbour was Warning me for no reason!
Hi,
I'd suggest to take a look at .ppo file generated, as I'm
100% sure that the meaningless expression is not wrong.
Maybe you need to code it differently to avoid it. Or,
just turn off warnings, if that's not an option.
From personal experience it's sometimes difficult to
see why compiler warns, but so far it was right on all
cases.
Brgds,
Viktor
On 2010 Feb 8, at 22:55, smu johnson wrote:
> Dear Harbour,
>
> I have solved the whole oGet problems I was having, referenced by both of the
> URLs below of the mailing list.
>
> http://lists.harbour-project.org/pipermail/harbour/2010-February/031851.html
> http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html
>
> The problem was Harbour was Warning me about useless vals.
>
> 3:28 PM 2/5/2010
> GL.PRG(419) Warning W0027 Meaningless use of expression 'String'
> GL2.PRG(1460) Warning W0027 Meaningless use of expression 'String'
> GL2.PRG(1469) Warning W0027 Meaningless use of expression 'String'
> DATPROMO.PRG(10) Warning W0027 Meaningless use of expression 'String'
> ORDERS.PRG(794) Warning W0027 Meaningless use of expression 'Logical'
> ORDERS.PRG(2034) Warning W0027 Meaningless use of expression 'Logical'
> RECONCIL.PRG(1029) Warning W0027 Meaningless use of expression 'String'
> RECONCIL.PRG(1035) Warning W0027 Meaningless use of expression 'String'
> CRMAIN.PRG(1837) Warning W0027 Meaningless use of expression 'Logical'
> CRAUX2.PRG(78) Warning W0027 Meaningless use of expression 'Logical'
> CRAUX2.PRG(465) Warning W0027 Meaningless use of expression 'String'
> PROCESS.PRG(1497) Warning W0027 Meaningless use of expression 'String'
> PROCESS.PRG(1510) Warning W0027 Meaningless use of expression 'String'
> Phone.prg(5) Warning W0027 Meaningless use of expression 'String'
>
> Turns out, these were not meaningless. They were in EVAL lines of code where
> the "useless" value was needed to get the oGet stuff to work properly. An
> example of a line of code:
>
> Valid !lGiftCard .and. (lNegPrice .or. !CRPrice<0) .and.
> iif(lNew.and.CRPrice#0,Eval({||SpecialPrice:=.t.,SetPrice:=SpecialPrice,.t.}),.t.)
>
> As soon as I take out the "Meaningless" val, the warning stops when
> compiling, but our .PRG hangs when the getReader() function is called and
> breaks.
>
> Maybe this could be considered a bug in Harbour, where it is warning me for
> no reason?
>
> --
> smu johnson
>
> ___
> 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] oGet problems solved... because Harbour was Warning me for no reason!
Well... all I know is that upon making the Warning "come back" we don't get
a conditional BASE/ error. I just thought I'd pass it along, if anyone
cares to look into it.
The warnings don't really bother us really, so we don't mind seeing them if
nothing needs to be changed in this regard with Harbour warning messages.
Keep up the great work!!
On Mon, Feb 8, 2010 at 2:03 PM, Viktor Szakáts wrote:
> Hi,
>
> I'd suggest to take a look at .ppo file generated, as I'm
> 100% sure that the meaningless expression is not wrong.
> Maybe you need to code it differently to avoid it. Or,
> just turn off warnings, if that's not an option.
>
> From personal experience it's sometimes difficult to
> see why compiler warns, but so far it was right on all
> cases.
>
> Brgds,
> Viktor
>
> On 2010 Feb 8, at 22:55, smu johnson wrote:
>
> > Dear Harbour,
> >
> > I have solved the whole oGet problems I was having, referenced by both of
> the URLs below of the mailing list.
> >
> >
> http://lists.harbour-project.org/pipermail/harbour/2010-February/031851.html
> >
> http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html
> >
> > The problem was Harbour was Warning me about useless vals.
> >
> > 3:28 PM 2/5/2010
> > GL.PRG(419) Warning W0027 Meaningless use of expression 'String'
> > GL2.PRG(1460) Warning W0027 Meaningless use of expression 'String'
> > GL2.PRG(1469) Warning W0027 Meaningless use of expression 'String'
> > DATPROMO.PRG(10) Warning W0027 Meaningless use of expression 'String'
> > ORDERS.PRG(794) Warning W0027 Meaningless use of expression 'Logical'
> > ORDERS.PRG(2034) Warning W0027 Meaningless use of expression 'Logical'
> > RECONCIL.PRG(1029) Warning W0027 Meaningless use of expression 'String'
> > RECONCIL.PRG(1035) Warning W0027 Meaningless use of expression 'String'
> > CRMAIN.PRG(1837) Warning W0027 Meaningless use of expression 'Logical'
> > CRAUX2.PRG(78) Warning W0027 Meaningless use of expression 'Logical'
> > CRAUX2.PRG(465) Warning W0027 Meaningless use of expression 'String'
> > PROCESS.PRG(1497) Warning W0027 Meaningless use of expression 'String'
> > PROCESS.PRG(1510) Warning W0027 Meaningless use of expression 'String'
> > Phone.prg(5) Warning W0027 Meaningless use of expression 'String'
> >
> > Turns out, these were not meaningless. They were in EVAL lines of code
> where the "useless" value was needed to get the oGet stuff to work properly.
> An example of a line of code:
> >
> > Valid !lGiftCard .and. (lNegPrice .or. !CRPrice<0) .and.
> iif(lNew.and.CRPrice#0,Eval({||SpecialPrice:=.t.,SetPrice:=SpecialPrice,.t.}),.t.)
> >
> > As soon as I take out the "Meaningless" val, the warning stops when
> compiling, but our .PRG hangs when the getReader() function is called and
> breaks.
> >
> > Maybe this could be considered a bug in Harbour, where it is warning me
> for no reason?
> >
> > --
> > smu johnson
> >
> > ___
> > 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
>
--
smu johnson
___
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:[13819] trunk/harbour
Revision: 13819 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13819&view=rev Author: vszakats Date: 2010-02-08 22:19:16 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-08 23:18 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/gtwin/gtwin.c * include/hbrddcdx.h * contrib/hbct/screen2.c * contrib/hbct/ct.h * contrib/xhb/freadlin.c * contrib/gtwvg/gtwvg.h ! Cleaned remaining legacy types after verification with grep script. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.h trunk/harbour/contrib/hbct/ct.h trunk/harbour/contrib/hbct/screen2.c trunk/harbour/contrib/xhb/freadlin.c trunk/harbour/include/hbrddcdx.h trunk/harbour/src/rtl/gtwin/gtwin.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] How to build and use pCode DLL with hbmk2
On Mon, 08 Feb 2010, 2D Info - Leandro Damasio wrote: Hi, > I don't know if I reach the point you are talking about, but in the > xHarbour scenario I mentioned before apparently it wasn't needed to > resolve all the references to any functions statically linked to the > host executable, because these references were intended to be > resolved in runtime. > Inside hb_vmRegisterSymbols we inserted a hack to resolve the > undefined references both in the DLL and in the host aplication: if > the symbol in the DLL had an unresolved pointer (DEAD address), > we searched for its name in the host symbol table and replaced the > DEAD pointer for a resolved one, and when the symbol was resolved in > the DLL but not in the host symbol table we fixed its address in the > host symbol table, replacind the DEAD address for the DLL resolved > address. IOW, if the same symbol was in the DLL and in the host and > was undefined in one of them, we fixed it, otherwise, we let go. > > Does it make sense to you? Does this already apply to Harbour? I know what you did and why. The same will work also in Harbour if you use exactly the same C compiler and linker. Anyhow it's really dirty hack and the worse thing you could do. Believe me do if you would know all internal details of such hack with all possible problems and how many things might break final binaries then you never used such method. The clean method to not create such bindings which later you are trying to overload at link time is using DYNAMIC declaration in .prg code but before you will use it you should understand how it really works. Please forget about everything what you have done so far and start with clean mind ;-) BTW xHarbour users can also read it because most of things below are also valid for this compiler. Let's consider on MinGW only. Other C compilers are very similar but they cannot use .DLL libraries directly and need import libraries so such library have to be created together with PCODE DLLs using -implib hbmk2 option. 1. Main application is linked in shared mode with harbour*-dll using -shared hbmk2 switch. It is suggested method to use PCODE DLL. In such case everything is trivial and works out of the box without any hacks and modifications in the code. i.e.: /*** dllcode.prg ***/ proc MY_PROC() ? PROCNAME() + ": hello !!!" return init proc start ? "INIT PROC", PROCNAME() return exit proc end ? "EXIT PROC", PROCNAME() return /*** maincode.prg ***/ proc main() ? "start" my_proc() ? "end" ? return to create PCODE dll simply use: hbmk2 -shared -strip -hbdyn dllcode.prg -n -w -es2 and dllcode.dll is generated, if you are using other then MinGW C compiler then you should add -cflag=-DHB_DYNLIB (to force exporting public functions inside .prg code - only MinGW supports auto export feature) and -implib switches (to create import library - only MinGW supports direct DLL usage by linker), to compile and link final application use: hbmk2 -shared -strip -L. -ldllcode maincode.prg -n -w -es2 Please note that both DLL and final code are linked with harbour*.dll (-shared switch) and to link final application I added -L. and -ldllcode so linker was able to find dllcode.dll in current directory and MY_PROC() function inside. As you can see all works without any problems and you do not need any tricks and/or hacks and/or additional code. You do not have to even touch original code. It's possible because linker was able to cleanly resolve all references at link time. No manual hacks which can only cause unexpected crash. In this version code inside PCODE DLL can access all Harbour exported functions (in case of MinGW all public functions when automatic export feature is enabled). 2. Main application is linked in shared mode with harbour*-dll using -shared hbmk2 switch but PCODE dll is not linked statically at link time but rather loaded dynamically by HB_LIBLOAD(). /*** dllcode.prg ***/ DYNAMIC QOUT, PROCNAME // added to inform compiler and linker that // references to above functions have to be // resolved dynamically at runtime proc MY_PROC() ? PROCNAME() + ": hello !!!" return init proc start ? "INIT PROC", PROCNAME() return exit proc end ? "EXIT PROC", PROCNAME() return /*** maincode.prg ***/ DYNAMIC MY_PROC // declare functions from dynamically loaded DLLs // as DYNAMIC proc main() local hLib ? "start" hLib := hb_libload( "dllcode" ) if empty( hLib ) ? "Cannot load library." else my_proc() hb_libfree( hLib ) endif ? "end" ? return to create PC
Re: [Harbour] How to build and use pCode DLL with hbmk2
On Mon, 08 Feb 2010, Szak�ts Viktor wrote: Hi Viktor, > > Probably to make it easier for users we can add small option to hbmk2 > > which will attach to final code exported wrappers to hb_vmProcessSymbols() > > and hb_vmExecute() or single function which can be used to extract > > addresses of other functions so later it will be enough to extend > > the list of pseudo exported symbols without touching hbmk2 code. > > I can create such function. > Okay we can do it. I'll also need a name proposal for > such hbmk2 option. Or maybe a new main switch instead of > -hbdyn (like -hbdynvm ?) which also turns on this extra > feature automatically, but a good name would be nice > even for this case. Well, as usual names are the hardest part of modification. It will be also good to add switch to replace -cflag=-DHB_DYNLIB when .prg modules used for PCODE DLLs are compiled. See my other message where I tried to more precisely describe how to create and use PCODE DLLs in different combinations with examples. I hope it makes it more clear for everybody. It should also help us to agree the modifications in HBMK2 and core code which allow to use PCODE DLLs with static hbvm library which does not export any symbols. It will be easier for me to explain what we should do when you read this text. 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:[13820] trunk/harbour
Revision: 13820 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13820&view=rev Author: vszakats Date: 2010-02-08 23:17:09 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-09 00:13 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/pp/pplib.c * src/common/hbprintf.c * src/rtl/gtclip.c * src/rdd/dbfntx/dbfntx1.c * src/rdd/dbfnsx/dbfnsx1.c * src/rdd/dbfcdx/dbfcdx1.c * src/rdd/dbffpt/dbffpt1.c * src/compiler/hbpcode.c * include/hbgtcore.h * contrib/hbbmcdx/bmdbfcdx.c * contrib/hbbtree/hb_btree.h * contrib/hbbtree/hb_btree.c ! Fixed remaining type conversion problems after doing live testing on win/bcc. Please test it on other platforms. * config/rules.mk + Enabled HB_LEGACY_TYPES_OFF on default Harbour builds. This is required to keep new type usage enforced. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/rules.mk trunk/harbour/contrib/hbbmcdx/bmdbfcdx.c trunk/harbour/contrib/hbbtree/hb_btree.c trunk/harbour/contrib/hbbtree/hb_btree.h trunk/harbour/include/hbgtcore.h trunk/harbour/src/common/hbprintf.c trunk/harbour/src/compiler/hbpcode.c trunk/harbour/src/pp/pplib.c trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/dbfntx/dbfntx1.c trunk/harbour/src/rtl/gtclip.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] How to build and use pCode DLL with hbmk2
Hi Przemek
I agree though I do not now if I'm right person to describe it
in INSTALL. For shared binaries using harbour*.dll there is
no problem at all and it's enough to link PCODE dll with harbour*.dll.
The problem is only with binaries which have HVM linked with static
part of application. In the previous message I forgot to write that
also functions called in PRG code compiled to PCODE DLL creates
dependencies so programmer should declare them using DYNAMIC clause.
He can generate header file with all functions which are visible
for core part of his application using this code:
#if 0// uncomment it for tests */
proc main()
genFuncList()
return
#endif
proc genFuncList()
local aFunc, hFile
aFunc := getFuncList()
asort( aFunc )
hFile := fcreate("dynamic.ch")
aeval( aFunc, {|x| fwrite( hFile, "DYNAMIC " + x +
hb_osNewLine() ) } )
fclose( hFile )
return
func getFuncList()
local aFunc, nCount := __dynsCount(), nDst:=0, n
aFunc := array( nCount )
for n := 1 to nCount
if __dynsIsFun( n )
aFunc[ ++nDst ] := __dynsGetName( n )
endif
next
asize( aFunc, nDst )
return aFunc
and then simply #include it in .prg files compiled and linked into
PCODE dlls.
Maybe I misunderstood your tip, but the big problem we have here is that the
names of the functions that will be called from the DLL are not known by the
"host" application before run time. We load the DLL, then we call a known
function (via macro evaluation) to get some info about the content of the
DLL and based on this info we fill the macros that result in the dll
functions names. So it's fundamental in this case that the unresolved
references from dll to the app and vice-versa can be resolved in run time,
the same way as blinker dlls load to clipper apps, with no need to declare
the dynamic symbols in the static part prg's.
Now the only thing I'm still interested in, is what
are the advantage of pcode-.dlls over .hrb files?
[ I can only cite inclusion of .c functions. ]
Yes, mixed PRG and C code is probably the only one real feature.
Probably it's mostly important for 3-rd party extensions which can
be distributed as single DLL. For .prg code only HRB files seem to
be much better solution though support for HRL files with optional
conversion of all internal bindings to static when HRL is loaded
will make it even more flexible for big projects.
If we could have collections of hrb modules libbed inside one single file
that could be loaded and unloaded dinamically there would be no need of
using plataform dependant dlls for harbour code. Tha would be just perfect.
Thanks Przemek
Best regards
Leandro
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Przemek, > to create PCODE dll simply use: > > hbmk2 -shared -strip -hbdyn dllcode.prg -n -w -es2 > > and dllcode.dll is generated, if you are using other then MinGW C > compiler then you should add -cflag=-DHB_DYNLIB (to force exporting > public functions inside .prg code - only MinGW supports auto export > feature) and -implib switches (to create import library - only MinGW > supports direct DLL usage by linker), Minor note: -cflag=-DHB_DYNLIB is automatically enabled for non-mingw compilers when -hbdyn is used, so it's not necessary to add it manually. I believe the rest of this nice description should definitely go into doc/pcodedll.txt. You can even commit as is. Brgds, Viktor ___ 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:[13821] trunk/harbour
Revision: 13821
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13821&view=rev
Author: vszakats
Date: 2010-02-08 23:42:55 + (Mon, 08 Feb 2010)
Log Message:
---
2010-02-09 00:41 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* include/hbsetup.ch
+ HB_LEGACY_OFF will also enable HB_LEGACY_TYPES_OFF.
* contrib/hbfimage/Makefile
* contrib/hbfimage/fi_winfu.c
* contrib/hbfimage/fi_wrp.c
+ Forcing HB_LEGACY_TYPES_OFF.
+ Switched to new regular kind of windows.h inclusion.
+ Enabled for *nix platforms. Now it should build w/o problems.
; New regular windows.h inclusion goes as follows:
---
/* After #include "hbapi.h", write this: */
#if defined( HB_OS_WIN )
#include /* or any other Windows API header you may need,
in any valid order or combination. */
#endif
---
Old hacky method can now be safely deleted:
'#define HB_OS_WIN_USED' and/or
'#define HB_OS_WIN32_USED'
* contrib/hbbtree/hb_btree.c
! Cleaned '{};' to be '{}' after prev cleanup (';' -> '{};')
* doc/whatsnew.txt
+ Added section for version 2.1.0.
Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbbtree/hb_btree.c
trunk/harbour/contrib/hbfimage/Makefile
trunk/harbour/contrib/hbfimage/fi_winfu.c
trunk/harbour/contrib/hbfimage/fi_wrp.c
trunk/harbour/doc/whatsnew.txt
trunk/harbour/include/hbsetup.ch
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:[13822] trunk/harbour
Revision: 13822 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13822&view=rev Author: vszakats Date: 2010-02-08 23:44:30 + (Mon, 08 Feb 2010) Log Message: --- 2010-02-09 00:43 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbfimage/Makefile - No more relevant comment deleted. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbfimage/Makefile 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] How to build and use pCode DLL with hbmk2
Hi Przemek! I know what you did and why. The same will work also in Harbour if you use exactly the same C compiler and linker. Anyhow it's really dirty hack and the worse thing you could do. Believe me do if you would know all internal details of such hack with all possible problems and how many things might break final binaries then you never used such method. The clean method to not create such bindings which later you are trying to overload at link time is using DYNAMIC declaration in .prg code but before you will use it you should understand how it really works. Please forget about everything what you have done so far and start with clean mind ;-) No problem. AFAIK this aproach uses to give good results! BTW xHarbour users can also read it because most of things below are also valid for this compiler. Let's consider on MinGW only. Other C compilers are very similar but they cannot use .DLL libraries directly and need import libraries so such library have to be created together with PCODE DLLs using -implib hbmk2 option. 1. Main application is linked in shared mode with harbour*-dll using -shared hbmk2 switch. It is suggested method to use PCODE DLL. In such case everything is trivial and works out of the box without any hacks and modifications in the code. i.e.: /*** dllcode.prg ***/ proc MY_PROC() ? PROCNAME() + ": hello !!!" return init proc start ? "INIT PROC", PROCNAME() return exit proc end ? "EXIT PROC", PROCNAME() return /*** maincode.prg ***/ proc main() ? "start" my_proc() ? "end" ? return to create PCODE dll simply use: hbmk2 -shared -strip -hbdyn dllcode.prg -n -w -es2 and dllcode.dll is generated, if you are using other then MinGW C compiler then you should add -cflag=-DHB_DYNLIB (to force exporting public functions inside .prg code - only MinGW supports auto export feature) and -implib switches (to create import library - only MinGW supports direct DLL usage by linker), to compile and link final application use: hbmk2 -shared -strip -L. -ldllcode maincode.prg -n -w -es2 Please note that both DLL and final code are linked with harbour*.dll (-shared switch) and to link final application I added -L. and -ldllcode so linker was able to find dllcode.dll in current directory and MY_PROC() function inside. As you can see all works without any problems and you do not need any tricks and/or hacks and/or additional code. You do not have to even touch original code. It's possible because linker was able to cleanly resolve all references at link time. No manual hacks which can only cause unexpected crash. In this version code inside PCODE DLL can access all Harbour exported functions (in case of MinGW all public functions when automatic export feature is enabled). 2. Main application is linked in shared mode with harbour*-dll using -shared hbmk2 switch but PCODE dll is not linked statically at link time but rather loaded dynamically by HB_LIBLOAD(). /*** dllcode.prg ***/ DYNAMIC QOUT, PROCNAME // added to inform compiler and linker that // references to above functions have to be // resolved dynamically at runtime proc MY_PROC() ? PROCNAME() + ": hello !!!" return init proc start ? "INIT PROC", PROCNAME() return exit proc end ? "EXIT PROC", PROCNAME() return /*** maincode.prg ***/ DYNAMIC MY_PROC // declare functions from dynamically loaded DLLs // as DYNAMIC proc main() local hLib ? "start" hLib := hb_libload( "dllcode" ) if empty( hLib ) ? "Cannot load library." else my_proc() hb_libfree( hLib ) endif ? "end" ? return to create PCODE dll use: hbmk2 -nohblib -strip -hbdyn -lhbmaindllp dllcode.prg -n -w -es2 please note that I added hbmaindllp which is linked with final PCODE DLL binaries and used -nohblib to not link any harbour libraries. With this switch I'm sure that I do not link the same core code twice with PCODE DLL and with final binaries and if I forget to declare some functions as DYNAMIC then I will have link time error so I can easy add missing declarations. To compile and link final application use: hbmk2 -shared -strip maincode.prg -n -w -es2 Please note that in this version I haven't added -ldllcode because now it will be loaded dynamically by hb_libload() and linker does not have to know about it. And that's all. You can test maincode.exe to see how it works. This version needs to declare functions called from external modules as DYNAMIC to inform compiler and linker that they are bound dynamically at runtime so it should not create any static references and special code from hbmaindllp linke
Re: [Harbour] How to build and use pCode DLL with hbmk2
Very good Viktor! This text will be really very helpfull to many people! Brgds Leandro -- From: "Viktor Szakáts" Sent: Monday, February 08, 2010 8:27 PM To: "Harbour Project Main Developer List." Subject: Re: [Harbour] How to build and use pCode DLL with hbmk2 Hi Przemek, to create PCODE dll simply use: hbmk2 -shared -strip -hbdyn dllcode.prg -n -w -es2 and dllcode.dll is generated, if you are using other then MinGW C compiler then you should add -cflag=-DHB_DYNLIB (to force exporting public functions inside .prg code - only MinGW supports auto export feature) and -implib switches (to create import library - only MinGW supports direct DLL usage by linker), Minor note: -cflag=-DHB_DYNLIB is automatically enabled for non-mingw compilers when -hbdyn is used, so it's not necessary to add it manually. I believe the rest of this nice description should definitely go into doc/pcodedll.txt. You can even commit as is. Brgds, Viktor ___ 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:[13823] trunk/harbour
Revision: 13823 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13823&view=rev Author: vszakats Date: 2010-02-09 01:13:25 + (Tue, 09 Feb 2010) Log Message: --- 2010-02-09 02:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/runner.c * src/vm/garbage.c * src/vm/classes.c * src/rtl/cdpapi.c * src/rtl/cdpapihb.c * src/rdd/dbcmd.c * include/hbapicdp.h * include/hbapiitm.h * include/hbextern.ch * include/hbdefs.h * include/hbsetup.h * include/hbapi.h - Deleted code guarded with (previously disabled) HB_LEGACY_LEVEL2 * include/rdd.api * include/clipdefs.h + Permanently enabled HB_LEGACY_LEVEL2 related changes. * contrib/xhb/bkgtsks.c - Deleted HB_OS_WIN_USED. It wasn't used. * include/hbapi.h * src/vm/cmdarg.c * hb_winmainArgGet() changed to not use Windows types. This function is declared in hbapi.h and this header shouldn't depend on windows.h. * include/hbwince.h * include/hbsetup.h * HB_OS_HAS_DRIVE_LETTER is now configured in central place (hbsetup.h) for WinCE platform also. * include/hbwince.h * include/hbdefs.h * Windows (CE and not-CE) specific declarations moved from hbwince.h to hbdefs.h. * include/hbdefs.h % hbwince.h inclusion now better guarded to not include it for non WinCE platforms. + HB_OS_WIN_USED macro will now autodetected by checking whether windows.h was included before this header. This is required for hbwince.h. I don't like it, since hbapi.h still depends on windows.h for WinCE platform, which still ties us to unnecessary windows.h inclusion rules. Rather, hbwince.h should be included directly by .c files when needed and when HB_OS_WIN_CE is defined. After all this our little Windows API implementation for compilers which need it. * include/hbdefs.h * include/hbwmain.c + hb_winmainArgInit() declaration moved to hbwmain.c, the only place where this is used. * Deleted HB_EXPORT from hb_winmainArgInit. Pls speak up if this is wrong. It's possible to move this back to hbdefs.h, but parameter types should be changed to ANSI ones. * contrib/gtwvg/gtwvg.c * contrib/gtwvg/gtwvg.h * contrib/gtwvg/wvggui.c * contrib/gtwvg/wvgcuig.c * contrib/gtwvg/wvggui.h * contrib/gtwvg/wvgwin.c * contrib/gtwvg/wvgutils.c * contrib/gtwvg/wvgcore.c * contrib/gtwvg/wvgwing.c - Deleted HB_OS_WIN_USED. Now it should work without it. windows.h was already included in non-official method, so it's now okay also. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/gtwvg.h trunk/harbour/contrib/gtwvg/wvgcore.c trunk/harbour/contrib/gtwvg/wvgcuig.c trunk/harbour/contrib/gtwvg/wvggui.c trunk/harbour/contrib/gtwvg/wvggui.h trunk/harbour/contrib/gtwvg/wvgutils.c trunk/harbour/contrib/gtwvg/wvgwin.c trunk/harbour/contrib/gtwvg/wvgwing.c trunk/harbour/contrib/xhb/bkgtsks.c trunk/harbour/include/clipdefs.h trunk/harbour/include/hbapi.h trunk/harbour/include/hbapicdp.h trunk/harbour/include/hbapiitm.h trunk/harbour/include/hbdefs.h trunk/harbour/include/hbextern.ch trunk/harbour/include/hbsetup.h trunk/harbour/include/hbwince.h trunk/harbour/include/hbwmain.c trunk/harbour/include/rdd.api trunk/harbour/src/rdd/dbcmd.c trunk/harbour/src/rtl/cdpapi.c trunk/harbour/src/rtl/cdpapihb.c trunk/harbour/src/vm/classes.c trunk/harbour/src/vm/cmdarg.c trunk/harbour/src/vm/garbage.c trunk/harbour/src/vm/runner.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:[13824] trunk/harbour
Revision: 13824 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13824&view=rev Author: vouchcac Date: 2010-02-09 01:43:47 + (Tue, 09 Feb 2010) Log Message: --- 2010-02-08 17:16 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbxbp/xbp.ch * contrib/hbxbp/xbpparthandler.prg * contrib/hbxbp/xbpstatusbar.prg * contrib/hbxbp/xbptoolbar.prg * contrib/hbxbp/xbpwindow.prg ! Fixed a rare parent/child relation issue in XbpStatusBar() and XbpToolBar() classes. + Implemented Harbour extension: Method :hbLayout( HBPLAYOUT_TYPE_* ) Currently HBPLAYOUT_TYPE_HORZBOX and HBPLAYOUT_TYPE_VERTBOX are supported. This is essentially executed after :create(). When executed class attemps to all children of it to be laid accordingly, if some are already created. Any other Xbp part created with "this" object as parent, that is also laid appropriately. This reduces a lot of code writing. Example: oStatic := XbpStatic():new():create( oDlg,... ) oStatic:hbLayout := HBPLAYOUT_TYPE_HORZBOX oBtn := XbpPushButton():new( oStatic ):create( ... ) oBtn1 := XbpPushButton():new( oStatic ):create( ... ) oBtn2 := XbpPushButton():new( oStatic ):create( ... ) Then, these buttons will be nicely placed inside oStatic. No need to go for complex calculations. * contrib/hbxbp/tests/demoxbp.prg + Applied :hbLayout for :drawingArea and tabPages. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbxbp/tests/demoxbp.prg trunk/harbour/contrib/hbxbp/xbp.ch trunk/harbour/contrib/hbxbp/xbpparthandler.prg trunk/harbour/contrib/hbxbp/xbpstatusbar.prg trunk/harbour/contrib/hbxbp/xbptoolbar.prg trunk/harbour/contrib/hbxbp/xbpwindow.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:[13825] trunk/harbour
Revision: 13825 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13825&view=rev Author: vouchcac Date: 2010-02-09 02:45:05 + (Tue, 09 Feb 2010) Log Message: --- 2010-02-08 18:44 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/idedocks.prg * contrib/hbide/ideeditor.prg * contrib/hbide/ideobject.prg % More ground cover in preperation of multiple views. Just to versionize changes. ;NOTE: Unreleased memory blocks have reduced considerably after parent/child relations fix in prev commit. This implies that in sometime in near future, memory issue is going to be the ghost of past. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idedocks.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/ideobject.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:[13826] trunk/harbour
Revision: 13826 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13826&view=rev Author: vszakats Date: 2010-02-09 02:58:53 + (Tue, 09 Feb 2010) Log Message: --- 2010-02-09 03:55 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/common/Makefile * src/common/hbwince.c + src/common/hbwin.c ! Moved Windows UNICODE helper function into new source, leaving WinCE API local emulation into separate source file. * include/hbwince.h + Now automatically includes windows.h. (since it depends on it) * include/hbdefs.h - Deleted HB_OS_WIN_USED autodetection. Not needed anymore. ! Fixed to not include hbwince.h anymore. It should be included directly from source files, where needed. * include/hbdefs.h * contrib/hbodbc/odbc.c * contrib/rddsql/sddodbc/odbcdd.c + Always defining HB_TCHAR_*() macros. They will be dummies in non-Windows or non-UNICODE builds. * include/clipdefs.h ! Legacy Clipper types moved to the bottom, because it's no longer true that hbapi.h defines their dependent types (our legacy ones). * contrib/hbwin/win_bmpd.c * contrib/hbwin/wapi_wingdi.c * contrib/hbwin/win_misc.c * contrib/hbwin/wapi_winbase.c * contrib/hbwin/wapi_alloc.c * contrib/hbwin/wapi_winuser.c * contrib/hbwin/hbwin.h * contrib/hbwin/hbwinole.h * contrib/hbwin/mapi.c * contrib/hbwin/wapi_wingdi_font.c * contrib/hbwin/olecore.c * contrib/hbwin/wce_simc.c * contrib/hbwin/wapi_winnls.c * contrib/hbwin/win_bmp.c * contrib/hbwin/win_com.c * contrib/hbwin/Makefile * contrib/hbwin/win_regc.c * contrib/hbwin/win_prn1.c * contrib/hbwin/win_prn2.c * contrib/hbwin/win_prn3.c * contrib/hbwin/wapi_commctrl.c * contrib/hbwin/win_osc.c * contrib/hbwin/wce_smsc.c * contrib/hbwin/wapi_err.c * contrib/hbwin/legacycd.c * contrib/hbwin/hbwapi.h * contrib/hbwin/wapi_shellapi.c * contrib/hbwin/win_dlg.c * contrib/hbwin/legacyco.c * contrib/hbwin/win_dll.c * contrib/hbwin/wapi_winbase_mutex.c + Reworked the way windows.h is included and headers are organized. New types allow complete control and flexibility. Finally. * src/vm/mainwin.c * src/vm/maindll.c * src/vm/maindllh.c * src/vm/cmdarg.c * src/vm/maindllp.c * src/vm/task.c * src/vm/fm.c * src/vm/extrap.c * src/vm/thread.c * src/vm/hvmall.c * src/vm/dynlibhb.c * src/common/hbgete.c * src/common/hbffind.c * src/common/hbver.c * src/common/hbtrace.c * src/common/hbfsapi.c * src/common/hbdate.c * src/rtl/gtwin/gtwin.c * src/rtl/fstemp.c * src/rtl/gttone.c * src/rtl/fserr.c * src/rtl/filesys.c * src/rtl/lang.c * src/rtl/diskspac.c * src/rtl/console.c * src/rtl/cputime.c * src/rtl/gtclip.c * src/rtl/oemansi.c * src/rtl/disksphb.c * src/rtl/net.c * src/rtl/gtgui/gtgui.c * src/rtl/hbproces.c * src/rtl/gtwvt/gtwvt.h * src/rtl/gtwvt/gtwvt.c * src/rtl/gtkbstat.c * contrib/hbct/ctnet.c * contrib/hbct/dattime3.c * contrib/hbct/disk.c * contrib/hbodbc/odbc.c * contrib/xhb/hboutdbg.c * contrib/xhb/xhberrc.c * contrib/xhb/filestat.c * contrib/xhb/hbserv.c * contrib/hbtpathy/tpwin.c * contrib/hbmzip/hbmzip.c * contrib/hbqt/hbqt_base.cpp * contrib/hbnf/getenvrn.c * contrib/rddsql/sddodbc/odbcdd.c * contrib/rddads/adsx.c * contrib/rddads/adsfunc.c * contrib/rddads/rddads.h * contrib/rddads/ads1.c * contrib/rddads/adsmgmnt.c * examples/hbapollo/apollo.c + HB_OS_WIN_USED trick replaced with direct windows.h inclusion, just like we do for all other OSes. + Also inclded hbwince.h in source files which required it. Please test it. * contrib/hbqt/gtqtc/gtqtc.cpp - Deleted commented code to not create false grep hits all the time. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/ctnet.c trunk/harbour/contrib/hbct/dattime3.c trunk/harbour/contrib/hbct/disk.c trunk/harbour/contrib/hbmzip/hbmzip.c trunk/harbour/contrib/hbnf/getenvrn.c trunk/harbour/contrib/hbodbc/odbc.c trunk/harbour/contrib/hbqt/gtqtc/gtqtc.cpp trunk/harbour/contrib/hbqt/hbqt_base.cpp trunk/harbour/contrib/hbtpathy/tpwin.c trunk/harbour/contrib/hbwin/Makefile trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/hbwinole.h trunk/harbour/contrib/hbwin/legacycd.c trunk/harbour/contrib/hbwin/legacyco.c trunk/harbour/contrib/hbwin/mapi.c trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/contrib/hbwin/wapi_alloc.c trunk/harbour/contrib/hbwin/wapi_commctrl.c trunk/harbour/contrib/hbwin/wapi_err.c trunk/harbour/contrib/hbwin/wapi_shellapi.c trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/wapi_winbase_mutex.c trunk/harbour/contrib/hbwin/wapi_wingdi.c trunk/harbour/contrib/hbwin/wapi_wingdi_font.c trunk/harbour/contrib/hbwin/wap
[Harbour] SF.net SVN: harbour-project:[13827] trunk/harbour
Revision: 13827 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13827&view=rev Author: vszakats Date: 2010-02-09 03:30:30 + (Tue, 09 Feb 2010) Log Message: --- 2010-02-09 04:30 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h ! Fixed remaining 'LONG' type on 64-bit non-Windows systems. ! Indentation fixes. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbdefs.h 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:[13828] trunk/harbour
Revision: 13828 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13828&view=rev Author: vszakats Date: 2010-02-09 03:35:53 + (Tue, 09 Feb 2010) Log Message: --- 2010-02-09 04:35 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h ! Fixed missing HB_EXTERN_* Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbdefs.h 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
