[Harbour] SF.net SVN: harbour-project:[13209] trunk/harbour
Revision: 13209 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13209&view=rev Author: druzus Date: 2009-12-11 03:37:42 + (Fri, 11 Dec 2009) Log Message: --- 2009-12-11 04:37 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/thread.c ! added missing HB_STACK_TLS_PRELOAD Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/vm/thread.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:[13208] trunk/harbour
Revision: 13208 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13208&view=rev Author: druzus Date: 2009-12-11 03:13:24 + (Fri, 11 Dec 2009) Log Message: --- 2009-12-11 04:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapiitm.h * harbour/src/vm/classes.c * added new internal HVM macro * harbour/src/vm/thread.c + added new function hb_threadOnceInit( @ ) -> It assigns to if is NIL in MT safe way so it's assigned only once. It's reduced but faster version of hb_threadOnce() * harbour/include/hbapicdp.h * define HB_WCHAR as wchar_t on Windows platforms for compilers which refuse to make conversions between types using the same base type. * harbour/contrib/hbwin/win_dll.c * code cleanup Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_dll.c trunk/harbour/include/hbapicdp.h trunk/harbour/include/hbapiitm.h trunk/harbour/src/vm/classes.c trunk/harbour/src/vm/thread.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13198] trunk/harbour
On Thu, 10 Dec 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-12-10 15:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
> * hbwin/win_misc.c
> * hbwin/win_prn1.c
> + Using new UNICODE parameter passing macros instead of HB_TCHAR*() ones.
> (where possible)
Thank you for your modifications but I would like to ask you about
two things:
1. please do not leave any unnecessary casting like:
( LPCTSTR ) HB_PARSTRDEF( ... )
such casting does not give anything (it cannot converts strings
between different formats) but can hide very serious bugs like wrong
HB_PARSTRDEF() body.
2. please use HB_PARSTRDEF() only in places where is strictly necessary.
some of this code comes from xHarbour where few years ago all hb_parc()
where replaced with hb_parcx() by global S&R. From that time I always
used to check and replace unnecessary hb_parcx() with hb_parc().
If you will make mechanical translations all hb_parcx() to HB_PARSTRDEF()
then I will have to also verify HB_PARSTRDEF() calls. So please try
to already clean it at least for such basic things like:
if( HB_ISCHAR( 1 ) )
{
void * hName;
xec->hDLL = LoadLibrary( HB_PARSTRDEF( 1, &hName, NULL ) );
hb_strfree( hName );
}
BTW We can add to strapi.c two very simple functions:
const char * hb_strnull( const char * str )
{
return str ? str : "";
}
const HB_WCHAR * hb_strnull_u16( const HB_WCHAR * str )
{
return str ? str : s_szConstStr;
}
which can be used in HB_PARSTRDEF() macro.
best regards,
Przemek
ps. Now I'm making some minor modifications in win_dll.c so please
do not change it.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBQT demoqt
Just to report D:\harbour\contrib\hbqt\tests>hbmk2 demoqt -Lc:\qt\4.5.3\lib hbmk2: Processing local make script: hbmk.hbm Harbour 2.0.0beta3 (Rev. 13207) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'demoqt.prg'... Lines 3236, Functions/Procedures 23 Generating C source output to 'demoqt.c'... Done. demoqt.o:demoqt.c:(.data+0x98): undefined reference to `HB_FUN_QT_SETEVENTFILTER ' demoqt.o:demoqt.c:(.data+0xa8): undefined reference to `HB_FUN_QT_SETEVENTSLOTS' collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc.exe demoqt.o hbmk_2gzple.o-mwindows -Wl,--start-group -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lversion -lshlwapi -lQtCore4 -lQtGui4 -lQtNetwork4 -lQt UiTools -lpsapi -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -l rddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lh bpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomc tl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm 32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group -odemoqt.exe -LC:/HARB OUR/lib/win/mingw -L/../lib -Lc:/qt/4.5.3/lib -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ 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:[13207] trunk/harbour
Revision: 13207 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13207&view=rev Author: vszakats Date: 2009-12-10 23:22:00 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-11 00:20 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) + contrib/hbqt/hbqt_hbdbfmodel.h + Missed from prev commits. * contrib/hbqt/hbqt_slots.cpp * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_slots.cpp Added Paths: --- trunk/harbour/contrib/hbqt/hbqt_hbdbfmodel.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:[13206] trunk/harbour
Revision: 13206 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13206&view=rev Author: vszakats Date: 2009-12-10 22:23:10 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 23:22 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/qth/QAbstractItemModel.qth * contrib/hbqt/qth/QTableView.qth * contrib/hbqt/hbqt_events.cpp * contrib/hbqt/hbqt_slots.cpp * contrib/hbqt/hbqt_hbqmainwindow.cpp + Added TOFIX (also one QUESTION) to these code parts. All of them are potential leak or GPF generator issues. Could someone take a look at these? * contrib/hbqt/Makefile - contrib/hbqt/hbqt_hbdrawingarea.h - contrib/hbqt/hbqt_hbdrawingarea.cpp - Deleted unused custom class. * contrib/hbqt/qtgui/QTableView.cpp * contrib/hbqt/qtcore/QAbstractItemModel.cpp * Regenerated. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/Makefile trunk/harbour/contrib/hbqt/hbqt_events.cpp trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.cpp trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp trunk/harbour/contrib/hbqt/qtgui/QTableView.cpp trunk/harbour/contrib/hbqt/qth/QAbstractItemModel.qth trunk/harbour/contrib/hbqt/qth/QTableView.qth Removed Paths: - trunk/harbour/contrib/hbqt/hbqt_hbdrawingarea.cpp trunk/harbour/contrib/hbqt/hbqt_hbdrawingarea.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:[13205] trunk/harbour
Revision: 13205 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13205&view=rev Author: vszakats Date: 2009-12-10 21:50:20 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 22:46 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_events.cpp * contrib/hbqt/hbqt_slots.cpp ! Fixed events/slots handling to make sure the objects always exist on access. % This also made explicit initialization from .prg code unnecessary, so these two functions got deleted: QT_SETEVENTFILTER(), QT_SETEVENTSLOTS() ! Fixed events/slots handling to reset thread local object pointer to NULL after destruction. * contrib/hbxbp/xbpsle.prg * contrib/hbxbp/xbplistbox.prg * contrib/hbxbp/xbpwindow.prg * contrib/hbxbp/xbptreeview.prg * contrib/hbxbp/xbpdialog.prg * contrib/hbxbp/xbpspinbutton.prg * contrib/hbxbp/xbpgeneric.prg % Simple wrapper named HBXBP_SETEVENTFILTER() deleted and replaced with QT_GETEVENTFILTER() calls. (name still subject to change) ; NOTE: 1) In demoxbp MT mode build, the second dialog behaves strangely. It updates the screen slowly and not at all. Pritpal, please check it to make sure not some recent change broke it. 2) Forgot to mention in prev entry, but removing HBQMainWindow() mutex altogether didn't cause any change/loss of functionality in my tests, so my question is: Is it really needed? Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_events.cpp trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbxbp/xbpdialog.prg trunk/harbour/contrib/hbxbp/xbpgeneric.prg trunk/harbour/contrib/hbxbp/xbplistbox.prg trunk/harbour/contrib/hbxbp/xbpsle.prg trunk/harbour/contrib/hbxbp/xbpspinbutton.prg trunk/harbour/contrib/hbxbp/xbptreeview.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:[13204] trunk/harbour
Revision: 13204 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13204&view=rev Author: vszakats Date: 2009-12-10 21:23:25 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 22:22 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_hbqmainwindow.cpp * contrib/hbxbp/xbpgeneric.prg + Replaced HB_MUTEXCREATE() and HB_MUTEXDESTROY() with automatic initialization and deinitialization. ; NOTE: From now on HBQT needs to be requested by apps willing to use HBQT, with: REQUEST HB_QT This will ensure in the future that all init and deinit procedure are done correctly. It also makes it safe to use QT even from INIT and EXIT PROCECUREs. * contrib/hbqt/tests/demoqt.prg * contrib/hbxbp/tests/demoxbp.prg * contrib/hbide/hbide.prg + Added REQUEST HB_QT. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.cpp trunk/harbour/contrib/hbqt/tests/demoqt.prg trunk/harbour/contrib/hbxbp/tests/demoxbp.prg trunk/harbour/contrib/hbxbp/xbpgeneric.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:[13203] trunk/harbour
Revision: 13203 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13203&view=rev Author: druzus Date: 2009-12-10 20:49:23 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 21:49 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbatomic.h * removed 'static inline' from OpenWatcom ASM functions defined by '#pragma aux ...' to make OpenWatcom < 1.8 happy. Version 1.8 ignores 'static inline' attributes in such declarations. * harbour/config/dos/watcom.mk * harbour/utils/hbmk2/hbmk2.prg * switched from DOS/4GW to DOS/32A extender. It's faster what is noticeable also in final Harbour binaries, does not have DOS4G command line limitations and has nice tools which allow to easy set different runtime parameters (ss.exe) or compress final executable (sc.exe) BTW people having problem with maximum command line size in OpenWatcom tools can replace DOS/4GW with DOS/32A in this tools It can be made also globally by coping dos32a.exe to dos4gw.exe. NOTE: I've found why DOS Harbour OpenWatcom application created in my Linux box were not working. Just simply the directory with DOS extender setup files was not in PATH. Creating DOS OpenWatcom applications in other systems (i.e. Linux or OS2) do not forget to add directory with DOS binaries '%WATCOM%\binw' to PATH after directory with platform native OpenWatcom binaries '%WATCOM%\bin*' or copy DOS extender (dos32a.exe) to one of PATH directories. * harbour/config/dos/watcom.mk * added workaround for not included automatically by linker CLIB library when Harbour is compiler in pure C mode. I hope it's only temporary hack which we can remove in the future. I haven't added it to hbmk2 so linking DOS applications using hbmk2 user will have to add -lclib3r to hbmk2 parameters. * harbour/config/common/watcom.mk * disable DOS/32A banner messages Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/common/watcom.mk trunk/harbour/config/dos/watcom.mk trunk/harbour/include/hbatomic.h trunk/harbour/utils/hbmk2/hbmk2.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:[13202] trunk/harbour
Revision: 13202 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13202&view=rev Author: vszakats Date: 2009-12-10 20:00:34 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 21:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_slots.h - Deleted unnecessary headers. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_slots.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:[13201] trunk/harbour
Revision: 13201 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13201&view=rev Author: vszakats Date: 2009-12-10 19:48:17 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 20:35 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/Makefile + Added generic support to MOC compile headers. ; If this works out well, it makes it possible to use granular (non-monolythic) headers for 'Q_OBJECT' classes. It's also possible to move this logic into sub-libs. This may also mean that some hacks which were currently employed can be solved cleanly. Please test/review. * contrib/hbqt/hbqt_slots.h + contrib/hbqt/hbqt_hbqtableview.h * contrib/hbqt/hbqt_hbqtableview.cpp * contrib/hbqt/qth/QTableView.qth * contrib/hbqt/hbqt_hbdbfmodel.cpp * contrib/hbqt/qth/QAbstractItemModel.qth + contrib/hbqt/hbqt_hbdrawingarea.h * contrib/hbqt/hbqt_hbdrawingarea.cpp + contrib/hbqt/hbqt_hbqmainwindow.h * contrib/hbqt/hbqt_hbqmainwindow.cpp + contrib/hbqt/hbqt_hbqsyntaxhighlighter.h * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp * contrib/hbqt/qth/QSyntaxHighlighter.qth + contrib/hbqt/hbqt_events.h * contrib/hbqt/hbqt_events.cpp * Split monolithic hbqt_slots.h header to distinct class headers. * contrib/hbqt/generator/hbqtgen.prg - contrib/hbqt/filelist.mk * contrib/hbqt/Makefile * Changed to not generate central filelist.mk. (no dynamic files in central lib) * config/rules.mk - Deleted .l reference. * contrib/hbqt/qtgui/QSyntaxHighlighter.cpp * contrib/hbqt/qtgui/QTableView.cpp * contrib/hbqt/qtcore/QAbstractItemModel.cpp * Regenerated. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/rules.mk trunk/harbour/contrib/hbqt/Makefile trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/hbqt_events.cpp trunk/harbour/contrib/hbqt/hbqt_hbdbfmodel.cpp trunk/harbour/contrib/hbqt/hbqt_hbdrawingarea.cpp trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.cpp trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtableview.cpp trunk/harbour/contrib/hbqt/hbqt_slots.h trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp trunk/harbour/contrib/hbqt/qtgui/QSyntaxHighlighter.cpp trunk/harbour/contrib/hbqt/qtgui/QTableView.cpp trunk/harbour/contrib/hbqt/qth/QAbstractItemModel.qth trunk/harbour/contrib/hbqt/qth/QSyntaxHighlighter.qth trunk/harbour/contrib/hbqt/qth/QTableView.qth Added Paths: --- trunk/harbour/contrib/hbqt/hbqt_events.h trunk/harbour/contrib/hbqt/hbqt_hbdrawingarea.h trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.h trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.h trunk/harbour/contrib/hbqt/hbqt_hbqtableview.h Removed Paths: - trunk/harbour/contrib/hbqt/filelist.mk 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: Re: [Harbour] Undefined symbol 'hb_lang_Init_'
>BTW HB_NO_PROFILER is default and HB_FM_STD_ALLOC in BCC is slower, >consumes more memory and it's very inefficient in MT mode. Thank you. I'll try new settings. Regards, Toninho. __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ ___ 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:[13171] trunk/harbour
Hi Viktor, >Thank you for the explanation. >Probably some short docs would be nice to see the difference between these methods though, as without it, it's very difficult for users to make use of this feature or decide whether > yit's needed at all for real Harbour QT apps/users. Sorry, I can't help here, the destruction method targets just the next level like hbxbp and similar in the future, who knows... >For the most part this is true, however (and I wonder if anyone >reads my mails on this list :( ): >- There are some inherited/HBQT-only classes which are not equipped > with automatic GC collection. >- Some resources still need manual deallocation (like mutex, slots y and events, per app and/or per thread) >Making a little mistake on the .prg-level can easily cause a leak, >and there are signs that such leaks are present even in current .prg >code (posted about it already: MyMainWindow in HBXBP). Ok, Viktor, this is not just our problem, just consult the Qt sites, but don't forget that we are using an live SW now. >IMO above issues should be inspected, and a generic >solution developed to cover them and avoid repeating >them in the future. I completely agree with you, but please define the solution taking into consideration that the target is so complex... If somebody has some ideas how to handle this issue is welcome... Best regards, István ___ 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:[13171] trunk/harbour
Hi Istvan, > Yes, this is the final structure, as the handling mode should be dynamic, > please consult the Qt documents. Is in specified cases is recommended to use > the "delete later" feature what is the default for the actual interface > implementation. After consulting the actual Qt documentation and discussions > on the adequate sites please live it at is, is a conscious decision from my > side, to offer the flexibility to adopt the existing and future decisions of > the Qt developers. > >> IMO we should only leave one, the one which works >> the most efficiently and without leaks. > >> Is it time to make the decision yet? > > This is not black or white issue, it's not a race situation here, studying > the Qt documentations, we need a dynamic approach here. In some situation > the best solution can be different, so please close this issue, I > intentionally put that things in the code, maybe we are less informed, but > studying the Qt documents... Thank you for the explanation. Probably some short docs would be nice to see the difference between these methods though, as without it, it's very difficult for users to make use of this feature or decide whether it's needed at all for real Harbour QT apps/users. Until then to me it looks like passing a sophisticated decision onto users. > But as a final conclusion, WE ARE NOT FACING WITH MEMO LEAK ISSUES regarding > the Qt interface automatically generated. The problem is with our > measurement instruments! We will need help here to demonstrate it, if is the > case. The actual Windows implementation is not adequate to decide the memory > "consumption" as the windows internal are so complicated. I tried to tune > somehow the Pritpals algorithms but without success after studying some > sites, sorry. For the most part this is true, however (and I wonder if anyone reads my mails on this list :( ): - There are some inherited/HBQT-only classes which are not equipped with automatic GC collection. - Some resources still need manual deallocation (like mutex, slots and events, per app and/or per thread) Making a little mistake on the .prg-level can easily cause a leak, and there are signs that such leaks are present even in current .prg code (posted about it already: MyMainWindow in HBXBP). > So my general feeling is that the 'memory' problem is solved by the > automatic generated code! For these things demonstration we have to work > hardly. IMO above issues should be inspected, and a generic solution developed to cover them and avoid repeating them in the future. 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:[13171] trunk/harbour
Hi Viktor, >Is there any final result for the three different >memory handling modes? Yes, this is the final structure, as the handling mode should be dynamic, please consult the Qt documents. Is in specified cases is recommended to use the "delete later" feature what is the default for the actual interface implementation. After consulting the actual Qt documentation and discussions on the adequate sites please live it at is, is a conscious decision from my side, to offer the flexibility to adopt the existing and future decisions of the Qt developers. > IMO we should only leave one, the one which works > the most efficiently and without leaks. >Is it time to make the decision yet? This is not black or white issue, it's not a race situation here, studying the Qt documentations, we need a dynamic approach here. In some situation the best solution can be different, so please close this issue, I intentionally put that things in the code, maybe we are less informed, but studying the Qt documents... But as a final conclusion, WE ARE NOT FACING WITH MEMO LEAK ISSUES regarding the Qt interface automatically generated. The problem is with our measurement instruments! We will need help here to demonstrate it, if is the case. The actual Windows implementation is not adequate to decide the memory "consumption" as the windows internal are so complicated. I tried to tune somehow the Pritpals algorithms but without success after studying some sites, sorry. So my general feeling is that the 'memory' problem is solved by the automatic generated code! For these things demonstration we have to work hardly. I stopped temporally my thinking... Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: [Viktor] Suggestions on How to Get Help
>> 1) The sf.net page > Ultra slow:= not usable Don't mix whole sf.net page performance with the forum's. >> 2) www.harbour-project.org > Not possible to hosting restriction Yes. But I guess you and many others are satisfied with Wikipedia's performance. Yet the page wasn't updated in... well let it speak for itself: http://en.wikipedia.org/w/index.php?title=Harbour_(software)&action=history >> With little effort one can find the sf.net page, where >> the forum is listed. One can open INSTALL, which has >> an updated list of links to all important Harbour >> resource. > In speed google group is to sf like cycle to ferrari testarossa As is our user's mailing list. It also has gmane and whatever else interfaces you've been promoting in the past. Yet, there is only 10-20 messages a month. >> So it's _still_ not a shortage of _technical resources_ >> or lack of mediums. Pls let's not open new ones, but >> try to exploit existing ones. > I not open anything is only a proposal > tryed and defined as not usable > Can you/we search positive experiences from other languages? You seem to shout for a new online service every month. I'm not sure our goal is to have a Harbour account registered on every possible online services and maintaining a configured copy of all popular online communication tool. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: [Viktor] Suggestions on How to Get Help
2009/12/10 Viktor Szakáts : > > 1) The sf.net page Ultra slow:= not usable > 2) www.harbour-project.org Not possible to hosting restriction > With little effort one can find the sf.net page, where > the forum is listed. One can open INSTALL, which has > an updated list of links to all important Harbour > resource. In speed google group is to sf like cycle to ferrari testarossa > So it's _still_ not a shortage of _technical resources_ > or lack of mediums. Pls let's not open new ones, but > try to exploit existing ones. I not open anything is only a proposal tryed and defined as not usable Can you/we search positive experiences from other languages? > > Brgds, > Viktor > > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Some changes on Harbour Web Page
2009/12/10 Vailton Renato > > I've changed some details of the site as requested here on ML. I am > reviewing the page to enter other details but before you change'll > post a few ideas and suggestions for everyone to say what they think. > > * We must change the text "Development" to "Support"? Or is there > another text more appropriate for this item on the menu? Suggestions? Yes support is right > > * Include a link to the file-xhb diff.txt (Yes / No)? Absolutely yes Imo not a link but i suggest you creating a page > > * Review the examples from the "Sample Applications" for some details updated. > > * How about creating a section called "articles" on our site? In order > to add it to the tutorials and articles about Harbor? IMO In documentation menu > > In this way we could accept contributions from users such as Francesco > Perillo would like to contribute a tutorial on MinGW, or others wanting to > write about something like "Starting in hbxbp Harbotr + with Qt" and so on. > Sending me the texts in. DOC, TXT, PDF or something I can convert them to > html without problems ... The idea here was to unite some knowledge that is > useful for the project. > We need a wiki area with high number of administrator (wikipeduia corner) harbour is an anvanced languages for software and database application developers who want made fast application harbour langages is easy-to-maintain reduce development time allow create multi-threaded application allow create web application > > Comments? > > Best Regards, > Vailton Renato > ___ Regard -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: [Viktor] Suggestions on How to Get Help
> This is a common problem for harbour we have High Power with few information > This problem can be resolved having dinamic forum with integrated wiki/web > Can we start something like a Google group with hign number of administrator? We have tons of tech. resources, we even have two homepages with overlapping content: 1) The sf.net page 2) www.harbour-project.org With little effort one can find the sf.net page, where the forum is listed. One can open INSTALL, which has an updated list of links to all important Harbour resource. So it's _still_ not a shortage of _technical resources_ or lack of mediums. Pls let's not open new ones, but try to exploit existing ones. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Some changes on Harbour Web Page
Hi Vailton, > * We must change the text "Development" to "Support"? Or is there > another text more appropriate for this item on the menu? Suggestions? If possible, IMO we should have both "Development" and "Support". > * Include a link to the file-xhb diff.txt (Yes / No)? IMO the best would be to add a new news article with a link into the SVN browser to this file. > * Review the examples from the "Sample Applications" for some details updated. > * How about creating a section called "articles" on our site? In order > to add it to the tutorials and articles about Harbor? > In this way we could accept contributions from users such as Francesco > Perillo would like to contribute a tutorial on MinGW, or others > wanting to write about something like "Starting in hbxbp Harbotr + > with Qt" and so on. Sending me the texts in. DOC, TXT, PDF or > something I can convert them to html without problems ... The idea > here was to unite some knowledge that is useful for the project. I'm a little sceptic here. Even our Wikipedia article wasn't updated since years and is in a terrible state. First some kind volunteers should clean it and extend it. I think there is nothing worse than an "article" section without articles, so I'd reverse the process and encourage writing ppl such documents, and if we have enough to merit their own homepage section, we can add it and include all existing ones. Until then, there are quite a few place to add these articles even by users themselves (f.e. a forum topic). Just my 2 cents. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: [Viktor] Suggestions on How to Get Help
This is a common problem for harbour we have High Power with few information This problem can be resolved having dinamic forum with integrated wiki/web Can we start something like a Google group with hign number of administrator? 2009/12/10 Barry Jackson > > >> Why is the user forum not even mentioned on the Harbour web site? > It will see little use if nobody knows about it. > If I did not read this ML then I would never have found it. :-( > > -- Massimo Belgrano I ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Some changes on Harbour Web Page
I've changed some details of the site as requested here on ML. I am reviewing the page to enter other details but before you change'll post a few ideas and suggestions for everyone to say what they think. * We must change the text "Development" to "Support"? Or is there another text more appropriate for this item on the menu? Suggestions? * Include a link to the file-xhb diff.txt (Yes / No)? * Review the examples from the "Sample Applications" for some details updated. * How about creating a section called "articles" on our site? In order to add it to the tutorials and articles about Harbor? In this way we could accept contributions from users such as Francesco Perillo would like to contribute a tutorial on MinGW, or others wanting to write about something like "Starting in hbxbp Harbotr + with Qt" and so on. Sending me the texts in. DOC, TXT, PDF or something I can convert them to html without problems ... The idea here was to unite some knowledge that is useful for the project. Comments? Best Regards, Vailton Renato ___ 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:[13200] trunk/harbour
Revision: 13200 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13200&view=rev Author: vszakats Date: 2009-12-10 15:11:48 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 16:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/Makefile * contrib/hbqt/generator/hbqtgen.prg + Moved static source files from filelist.mk to Makefile. * contrib/hbqt/Makefile * contrib/hbqt/hbqt_slots.cpp + contrib/hbqt/hbqt_events.cpp + Moved event filter related stuff to separate file. % Cleaned lots of unnecessary QT headers includes. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/Makefile trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/hbqt_slots.cpp Added Paths: --- trunk/harbour/contrib/hbqt/hbqt_events.cpp 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:[13199] trunk/harbour
Revision: 13199 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13199&view=rev Author: vszakats Date: 2009-12-10 15:00:30 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 15:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_slots.cpp * contrib/hbxbp/xbpgeneric.prg * Rename: QT_QEVENTFILTER() -> QT_GETEVENTFILTER(). There will be some more renames to cleanup prefix usage. * contrib/hbwin/win_regc.c * Minor formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbwin/win_regc.c trunk/harbour/contrib/hbxbp/xbpgeneric.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Error building HbIDE
Bisz István escribió: You're welcome. But see last commit now is default thanks to Viktor. Ok. Thank very much BestRegards GVS ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Error building HbIDE
sorry for my typing: no -> now... -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István Sent: 2009. december 10. 15:47 To: 'Harbour Project Main Developer List.' Subject: RE: [Harbour] Re: Error building HbIDE You're welcome. But see last commit no is default thanks to Viktor. -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Guillermo Varona Silupú Sent: 2009. december 10. 15:46 To: harbour@harbour-project.org Subject: [Harbour] Re: Error building HbIDE Bisz István escribió: > Without having so much time to analyze your details... Please try: > d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi Thanks very much, now work ok. BestRegards GVS ___ 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] Re: Error building HbIDE
You're welcome. But see last commit no is default thanks to Viktor. -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Guillermo Varona Silupú Sent: 2009. december 10. 15:46 To: harbour@harbour-project.org Subject: [Harbour] Re: Error building HbIDE Bisz István escribió: > Without having so much time to analyze your details... Please try: > d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi Thanks very much, now work ok. BestRegards GVS ___ 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: Error building HbIDE
Bisz István escribió: Without having so much time to analyze your details... Please try: d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi Thanks very much, now work ok. BestRegards GVS ___ 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:[13198] trunk/harbour
Revision: 13198 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13198&view=rev Author: vszakats Date: 2009-12-10 14:41:37 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 15:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * hbwin/win_misc.c * hbwin/win_prn1.c + Using new UNICODE parameter passing macros instead of HB_TCHAR*() ones. (where possible) WIN_RUNDETACHED(), WIN_LOADRESOURCE(), WIN_CREATEDC(), WIN_GETPRINTERFONTNAME() * hbwin/wapi_winbase.c ! Fixed typo in two recently added WAPI function names. * contrib/hbqt/hbqt.hbc * contrib/hbqt/hbqts.hbc + Added psapi for win platform, until it's needed for memory debugging purposes. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.hbc trunk/harbour/contrib/hbqt/hbqts.hbc trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/win_misc.c trunk/harbour/contrib/hbwin/win_prn1.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] Error building HbIDE
Without having so much time to analyze your details... Please try: d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Guillermo Varona Silupú Sent: 2009. december 10. 14:58 To: harbour@harbour-project.org Subject: [Harbour] Error building HbIDE Hi, This is: C:\harbour\contrib\hbide>d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -LC:\Qt\2009.04\qt\lib hbmk2: Processing environment options: -compiler=mingw hbmk2: Compiling Harbour sources... Harbour 2.0.0beta3 (Rev. 13197) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'hbide.prg'... Lines 6388, Functions/Procedures 52 Generating C source output to '.hbmk\win\mingw\hbide.c'... Done. Compiling 'idestylesheets.prg'... Lines 6620, Functions/Procedures 1 Generating C source output to '.hbmk\win\mingw\idestylesheets.c'... Done. Compiling 'idetags.prg'... Lines 9786, Functions/Procedures 4 Generating C source output to '.hbmk\win\mingw\idetags.c'... Done. Compiling 'idemisc.prg'... Lines 13142, Functions/Procedures 22 Generating C source output to '.hbmk\win\mingw\idemisc.c'... Done. Compiling 'ideactions.prg'... Lines 16030, Functions/Procedures 2 Generating C source output to '.hbmk\win\mingw\ideactions.c'... Done. hbmk2: Compiling... hbmk2: Linking... hbide.exe d:/hrbMinGW/lib/libhbqt.a(hbqt_base.o):hbqt_base.cpp:(.text+0xeb): undefined ref erence to `getprocessmemoryi...@12' d:/hrbMinGW/lib/libhbqt.a(hbqt_base.o):hbqt_base.cpp:(.text+0x17b): undefined reference to `getprocessmemoryi...@12' collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc.exe .hbmk\win\mingw\hbide.o .hbmk\win\mingw\idestylesheets.o .hbmk\win\mingw \idetags.o .hbmk\win\mingw\idemisc.o .hbmk\win\mingw\ideactions.o .hbmk\win\ming w\ideparseexpr.o .hbmk\win\mingw\_hbmkaut.o-mwindows -Wl,--start-group -lhbx bp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lversion -lshlwapi -lQtCore4 -lQtG ui4 -lQtNetwork4 -lQtUiTools -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhbla ng -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwi nspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm - lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group -ohbide.e xe -Ld:/hrbMinGW/lib -L/../lib -LC:/Qt/2009.04/qt/lib C:\harbour\contrib\hbide> Any TIP? TIA BestRegards GVS ___ 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] Fwd: [Viktor] Suggestions on How to Get Help
On 09/11/09 23:00, Viktor Szakáts wrote: Hi Teo, Please think about this, and try to find a way you can help, after all, you got an excellent, stable, robust, feature-rich and industrial level product *for free*, which can help to even create profit (cash), save time (which is also money). In such case it's not devil to ask to return some of these benefits to the product itself to keep it alive and well on the long run. I'm sure it's everyone's interest to not let the project just vanish. Viktor, I'll start from now on, to check the Harbour phpBB Harbour forum to give support. Why not to use the MediaWiki facility that SF offers ?, Probably it will be a very good way to centralize the documentation/support efforts, also to store there (a copy) the documentation work that April is currently doing and start to contributing there to enhancing/updating it. Overall, I think the medium (= software) is not a significant issue here. IMO if there are users seeking help and users offering help, they will be able to work either on a mailing list or a forum, or a wiki, or chat, google wave, or anything which makes it possible to communicate. If such community is built and we know actual experiences from actual contributors, we can start to think about how to make it better, move it to a medium which is easier to work with, faster, sleeker, easier to search, whatever, but we should stop sinking back into a 'tool war' all the time. As for a wiki, we already have one inside the Trac app on sf.net, ready to use since quite some time. I can also enable MediaWiki with a few clicks (I don't know about its performance), but by itself these won't solve any problems, so before I do, I'd suggest to settle on forum vs. mailing list topic. BTW, a very nice start would be to cleanup our Wikipedia article, as by its current state it isn't too informative, it's outdated and by far doesn't convey any of the strength of Harbour. http://en.wikipedia.org/wiki/Harbour_(software) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Why is the user forum not even mentioned on the Harbour web site? It will see little use if nobody knows about it. If I did not read this ML then I would never have found it. :-( ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error building HbIDE
Hi, This is: C:\harbour\contrib\hbide>d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -LC:\Qt\2009.04\qt\lib hbmk2: Processing environment options: -compiler=mingw hbmk2: Compiling Harbour sources... Harbour 2.0.0beta3 (Rev. 13197) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'hbide.prg'... Lines 6388, Functions/Procedures 52 Generating C source output to '.hbmk\win\mingw\hbide.c'... Done. Compiling 'idestylesheets.prg'... Lines 6620, Functions/Procedures 1 Generating C source output to '.hbmk\win\mingw\idestylesheets.c'... Done. Compiling 'idetags.prg'... Lines 9786, Functions/Procedures 4 Generating C source output to '.hbmk\win\mingw\idetags.c'... Done. Compiling 'idemisc.prg'... Lines 13142, Functions/Procedures 22 Generating C source output to '.hbmk\win\mingw\idemisc.c'... Done. Compiling 'ideactions.prg'... Lines 16030, Functions/Procedures 2 Generating C source output to '.hbmk\win\mingw\ideactions.c'... Done. hbmk2: Compiling... hbmk2: Linking... hbide.exe d:/hrbMinGW/lib/libhbqt.a(hbqt_base.o):hbqt_base.cpp:(.text+0xeb): undefined ref erence to `getprocessmemoryi...@12' d:/hrbMinGW/lib/libhbqt.a(hbqt_base.o):hbqt_base.cpp:(.text+0x17b): undefined reference to `getprocessmemoryi...@12' collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc.exe .hbmk\win\mingw\hbide.o .hbmk\win\mingw\idestylesheets.o .hbmk\win\mingw \idetags.o .hbmk\win\mingw\idemisc.o .hbmk\win\mingw\ideactions.o .hbmk\win\ming w\ideparseexpr.o .hbmk\win\mingw\_hbmkaut.o-mwindows -Wl,--start-group -lhbx bp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lversion -lshlwapi -lQtCore4 -lQtG ui4 -lQtNetwork4 -lQtUiTools -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhbla ng -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwi nspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm - lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group -ohbide.e xe -Ld:/hrbMinGW/lib -L/../lib -LC:/Qt/2009.04/qt/lib C:\harbour\contrib\hbide> Any TIP? TIA BestRegards GVS ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour logo for the SF project page
Vailton, > Attached 2 images in PNG format 48x48 256 colors Thanks, I think it looks Ok (HB.png) http://sourceforge.net/projects/harbour-project/ Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour logo for the SF project page
Hi, There is an option in SF to add a 48x48 PNG as the project logo. If someone have something suitable, please zip it and sent it to the list. Thank, Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How Unicode works in harbour?
Wich kind of unicode support have harbour? What can be with HB_BUILD_UNICODE=yes? Possible have a table a unicode filed, search editing, save, print -- Massimo Belgrano ___ 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:[13174] trunk/harbour
On Wed, 09 Dec 2009, Mindaugas Kavaliauskas wrote: Hi, > Przemysław Czerpak wrote: > >>Perhaps copy-paste from some of my contrib RDDS. BTW, why RDD has > >>this in symbol table? > >It's necessary for *_GETFUNCTABLE function which is accessed from > >hb_rddRegister() by global symbol table. > Yes, but this answers why f.e. DBFCDX_GETFUNCTABLE is included into > symbol table in dbfcdx1.c. But why DBFCDX is also in symbol table? I > can not find any usage of this symbol in hb_rddRegister(). There are no technical reasons to register it. I can only guess that at the beginning when someone created code to register _GETFUNCTABLE() then he also added () to the symbol table and so far we are using the same method. The exception is only RDDADS library where only one of ADS* RDDs can be requested but all are available so it's good to register all symbols to make type( cRddName+"()" ) working for all available RDDs not only the one which was explicitly REQUESTed. > Do you think it will be a good practice to add a define like: > #define HB_CAIRO_REQUEST_EXTERN > #include "hbcairo.ch" > and put request for all library functions into hbcairo.ch inside ifdef? > Define name can have another structure is this is not suitable: > HB_CAIRO_EXTERN, HB_CAIRO_REQUEST_LIBRARY, HB_EXTERN_CAIRO, etc. Probably HB_CAIRO_EXTERN and HB_CAIRO_DYNAMIC so in the header file we can make: #undef HB_CAIRO_REF #if defined( HB_CAIRO_DYNAMIC ) #define HB_CAIRO_REFEXTERN #elif defined( HB_CAIRO_EXTERN ) #define HB_CAIRO_REFDYNAMIC #endif #ifdef HB_CAIRO_REF HB_CAIRO_REF HB_CAIRO_REF [...] HB_CAIRO_REF #endif and use one list for DYNAMIC and EXTERN declaration. For sure it can be usable but such list have to be synced with library code so it's some additional job. It will be also more flexible to keep them in separated files without any other definitions for 2 main reasons: 1. it's much easier to write helper tool creating automatically file with such list from scratch then tool updating existing file which contains also other definitions and PP directives. In the future we may try to create such tool for few compilers, i.e. I wrote sth like that for my own use as few lines shell script which creates such list for GCC libraries using 'nm'. 2. in some cases different libraries can use incompatible preporcessor directives so their header files cannot be mixed but programmer may need to include extern function declaration for both libraries to create final binaries which will have references to all functions. Keeping function lists in separated files without any other PP directives which may cause collisions resolves the problem. 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:[13197] trunk/harbour
Revision: 13197 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13197&view=rev Author: vszakats Date: 2009-12-10 10:33:15 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 11:24 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/common/hbver.c * Minor cleanup. * contrib/hbqt/generator/hbqtgen.prg ! Fixed typo in TRACE text. * contrib/hbqt/qtgui/* * contrib/hbqt/qtcore/* * contrib/hbqt/qtnetwork/* * Regenerated. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/qtcore/QBitArray.cpp trunk/harbour/contrib/hbqt/qtcore/QByteArray.cpp trunk/harbour/contrib/hbqt/qtcore/QDataStream.cpp trunk/harbour/contrib/hbqt/qtcore/QDate.cpp trunk/harbour/contrib/hbqt/qtcore/QDateTime.cpp trunk/harbour/contrib/hbqt/qtcore/QDir.cpp trunk/harbour/contrib/hbqt/qtcore/QEvent.cpp trunk/harbour/contrib/hbqt/qtcore/QEventLoop.cpp trunk/harbour/contrib/hbqt/qtcore/QFile.cpp trunk/harbour/contrib/hbqt/qtcore/QFileInfo.cpp trunk/harbour/contrib/hbqt/qtcore/QLatin1Char.cpp trunk/harbour/contrib/hbqt/qtcore/QLatin1String.cpp trunk/harbour/contrib/hbqt/qtcore/QLine.cpp trunk/harbour/contrib/hbqt/qtcore/QLineF.cpp trunk/harbour/contrib/hbqt/qtcore/QList.cpp trunk/harbour/contrib/hbqt/qtcore/QLocale.cpp trunk/harbour/contrib/hbqt/qtcore/QMimeData.cpp trunk/harbour/contrib/hbqt/qtcore/QModelIndex.cpp trunk/harbour/contrib/hbqt/qtcore/QObject.cpp trunk/harbour/contrib/hbqt/qtcore/QPoint.cpp trunk/harbour/contrib/hbqt/qtcore/QPointF.cpp trunk/harbour/contrib/hbqt/qtcore/QProcess.cpp trunk/harbour/contrib/hbqt/qtcore/QRect.cpp trunk/harbour/contrib/hbqt/qtcore/QRectF.cpp trunk/harbour/contrib/hbqt/qtcore/QRegExp.cpp trunk/harbour/contrib/hbqt/qtcore/QResource.cpp trunk/harbour/contrib/hbqt/qtcore/QSignalMapper.cpp trunk/harbour/contrib/hbqt/qtcore/QSize.cpp trunk/harbour/contrib/hbqt/qtcore/QSizeF.cpp trunk/harbour/contrib/hbqt/qtcore/QStringList.cpp trunk/harbour/contrib/hbqt/qtcore/QTextBoundaryFinder.cpp trunk/harbour/contrib/hbqt/qtcore/QTextDecoder.cpp trunk/harbour/contrib/hbqt/qtcore/QTextEncoder.cpp trunk/harbour/contrib/hbqt/qtcore/QTextStream.cpp trunk/harbour/contrib/hbqt/qtcore/QThread.cpp trunk/harbour/contrib/hbqt/qtcore/QTime.cpp trunk/harbour/contrib/hbqt/qtcore/QTimer.cpp trunk/harbour/contrib/hbqt/qtcore/QTranslator.cpp trunk/harbour/contrib/hbqt/qtcore/QUiLoader.cpp trunk/harbour/contrib/hbqt/qtcore/QUrl.cpp trunk/harbour/contrib/hbqt/qtcore/QVariant.cpp trunk/harbour/contrib/hbqt/qtgui/QAction.cpp trunk/harbour/contrib/hbqt/qtgui/QActionGroup.cpp trunk/harbour/contrib/hbqt/qtgui/QApplication.cpp trunk/harbour/contrib/hbqt/qtgui/QBitmap.cpp trunk/harbour/contrib/hbqt/qtgui/QBoxLayout.cpp trunk/harbour/contrib/hbqt/qtgui/QBrush.cpp trunk/harbour/contrib/hbqt/qtgui/QButtonGroup.cpp trunk/harbour/contrib/hbqt/qtgui/QCalendarWidget.cpp trunk/harbour/contrib/hbqt/qtgui/QCheckBox.cpp trunk/harbour/contrib/hbqt/qtgui/QColor.cpp trunk/harbour/contrib/hbqt/qtgui/QColorDialog.cpp trunk/harbour/contrib/hbqt/qtgui/QComboBox.cpp trunk/harbour/contrib/hbqt/qtgui/QCommandLinkButton.cpp trunk/harbour/contrib/hbqt/qtgui/QCommonStyle.cpp trunk/harbour/contrib/hbqt/qtgui/QCompleter.cpp trunk/harbour/contrib/hbqt/qtgui/QConicalGradient.cpp trunk/harbour/contrib/hbqt/qtgui/QContextMenuEvent.cpp trunk/harbour/contrib/hbqt/qtgui/QCursor.cpp trunk/harbour/contrib/hbqt/qtgui/QDateEdit.cpp trunk/harbour/contrib/hbqt/qtgui/QDateTimeEdit.cpp trunk/harbour/contrib/hbqt/qtgui/QDesktopWidget.cpp trunk/harbour/contrib/hbqt/qtgui/QDial.cpp trunk/harbour/contrib/hbqt/qtgui/QDialog.cpp trunk/harbour/contrib/hbqt/qtgui/QDirModel.cpp trunk/harbour/contrib/hbqt/qtgui/QDockWidget.cpp trunk/harbour/contrib/hbqt/qtgui/QDoubleSpinBox.cpp trunk/harbour/contrib/hbqt/qtgui/QErrorMessage.cpp trunk/harbour/contrib/hbqt/qtgui/QFileDialog.cpp trunk/harbour/contrib/hbqt/qtgui/QFileIconProvider.cpp trunk/harbour/contrib/hbqt/qtgui/QFileSystemModel.cpp trunk/harbour/contrib/hbqt/qtgui/QFocusFrame.cpp trunk/harbour/contrib/hbqt/qtgui/QFont.cpp trunk/harbour/contrib/hbqt/qtgui/QFontComboBox.cpp trunk/harbour/contrib/hbqt/qtgui/QFontDatabase.cpp trunk/harbour/contrib/hbqt/qtgui/QFontDialog.cpp trunk/harbour/contrib/hbqt/qtgui/QFontInfo.cpp trunk/harbour/contrib/hbqt/qtgui/QFontMetrics.cpp trunk/harbour/contrib/hbqt/qtgui/QFontMetricsF.cpp trunk/harbour/contrib/hbqt/qtgui/QFormLayout.cpp trunk/harbour/contrib/hbqt/qtgui/QFrame.cpp trunk/harbour/contrib/hbqt/qtgui/QGridLayout.cpp trunk/harbour/contrib/hbqt/qtgui/QGroupBox.cpp trunk/harbour/contrib/hbqt/qtgui/QHBoxLayout.cpp trunk/harbour/con
[Harbour] SF.net SVN: harbour-project:[13196] trunk/harbour
Revision: 13196 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13196&view=rev Author: druzus Date: 2009-12-10 09:42:34 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 10:42 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/xhb/fparse.c * pacified BCC warning * harbour/src/rtl/base64c.c * harbour/src/rtl/diskspac.c * harbour/src/rtl/filesys.c * harbour/src/rtl/hbproces.c * harbour/src/rtl/gtos2/gtos2.c * harbour/src/rdd/dbffpt/dbffpt1.c * harbour/contrib/xhb/freadlin.c * harbour/contrib/xhb/txtline.c * harbour/contrib/hbbtree/hb_btree.c * harbour/contrib/rddsql/sqlbase.c * harbour/contrib/rddsql/sddodbc/odbcdd.c * pacified OpenWatcom C warnings * harbour/include/hbatomic.h % rewritten OpenWatcom atomic ASM macros. Now they precisely informs compiler about used and modified registered and also force passing arguments in strictly defined what simplify ASM code. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbtree/hb_btree.c trunk/harbour/contrib/rddsql/sddodbc/odbcdd.c trunk/harbour/contrib/rddsql/sqlbase.c trunk/harbour/contrib/xhb/fparse.c trunk/harbour/contrib/xhb/freadlin.c trunk/harbour/contrib/xhb/txtline.c trunk/harbour/include/hbatomic.h trunk/harbour/src/rdd/dbffpt/dbffpt1.c trunk/harbour/src/rtl/base64c.c trunk/harbour/src/rtl/diskspac.c trunk/harbour/src/rtl/filesys.c trunk/harbour/src/rtl/gtos2/gtos2.c trunk/harbour/src/rtl/hbproces.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
