[Harbour] SF.net SVN: harbour-project:[13195] trunk/harbour
Revision: 13195 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13195&view=rev Author: vszakats Date: 2009-12-10 01:10:11 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 02:08 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/generator/hbqtgen.prg % Changed to only save files which have indeed changed (to avoid unnecessary rebuilds) * contrib/hbqt/Makefile * contrib/hbqt/hbqt.h * contrib/hbqt/hbqt_slots.h - contrib/hbqt/hbqt_hbqtdbfmodel.cpp + contrib/hbqt/hbqt_hbdbfmodel.cpp - contrib/hbqt/hbqt_hbqtsyntaxhighlighter.cpp + contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp - contrib/hbqt/hbqt_hbqtmymainwindow.cpp + contrib/hbqt/hbqt_hbqmainwindow.cpp - contrib/hbqt/hbqt_hbqtmydrawingarea.cpp + contrib/hbqt/hbqt_hbdrawingarea.cpp - contrib/hbqt/hbqt_hbqttableview.cpp + contrib/hbqt/hbqt_hbqtableview.cpp * contrib/hbqt/qth/QAbstractItemModel.qth * contrib/hbqt/qth/QSyntaxHighlighter.qth * contrib/hbqt/qth/QTableView.qth * Following class renames done: - HbSyntaxHighlighter -> HBQSyntaxHighlighter (HBIDE) - HbDbfModel -> HBDbfModel (HBXBP) - MyDrawingArea -> HBDrawingArea(UNUSED) - MyMainWindow-> HBQMainWindow - HbTableView -> HBQTableView (HBXBP) ; TOFIX: These classes seem to be the problematic parts of HBQT. They violate layering, there are naming inconsistencies (standard QT .prg level class internally refers to inherited special Harbour class, they implement HBXBP and IDE functionality embedded in HBQT to hack around the rule to not place .c code in HBXBP/HBIDE, they are not using GC collected pointers, they require mutexes which initialization isn't properly solved, one class is nowhere used. etcect) * contrib/hbxbp/xbpbrowse.prg * contrib/hbxbp/xbpwindow.prg * contrib/hbxbp/xbpdialog.prg * Renames applied to HBXBP code. * contrib/hbqt/qtgui/TQTableView.prg * contrib/hbqt/qtgui/QSyntaxHighlighter.cpp * contrib/hbqt/qtgui/QTableView.cpp * contrib/hbqt/qtcore/TQAbstractItemModel.prg * contrib/hbqt/qtcore/QAbstractItemModel.cpp * Regenerated after .qth changes. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/Makefile trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt_slots.h trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp trunk/harbour/contrib/hbqt/qtcore/TQAbstractItemModel.prg trunk/harbour/contrib/hbqt/qtgui/QSyntaxHighlighter.cpp trunk/harbour/contrib/hbqt/qtgui/QTableView.cpp trunk/harbour/contrib/hbqt/qtgui/TQTableView.prg trunk/harbour/contrib/hbqt/qth/QAbstractItemModel.qth trunk/harbour/contrib/hbqt/qth/QSyntaxHighlighter.qth trunk/harbour/contrib/hbqt/qth/QTableView.qth trunk/harbour/contrib/hbxbp/xbpbrowse.prg trunk/harbour/contrib/hbxbp/xbpdialog.prg trunk/harbour/contrib/hbxbp/xbpwindow.prg Added Paths: --- 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 Removed Paths: - trunk/harbour/contrib/hbqt/hbqt_hbqtdbfmodel.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtmydrawingarea.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtmymainwindow.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtsyntaxhighlighter.cpp trunk/harbour/contrib/hbqt/hbqt_hbqttableview.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:[13194] trunk/harbour
Revision: 13194 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13194&view=rev Author: vszakats Date: 2009-12-10 00:27:47 + (Thu, 10 Dec 2009) Log Message: --- 2009-12-10 01:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt.h % Minor cleanup after prev. * contrib/hbqt/generator/hbqtgen.prg * Changed to use HB_TRACE() instead of hbqt_debug(). ; NOTE: IMPORTANT: Now to enabled debug trace calls, you have to use the standard Harbour method: HB_USER_CFLAGS=-DHB_TR_LEVEL_DEBUG It's enough to enable this setting when build hbqt lib, to get HBQT trace calls. In addition, following setting stil works to enable .prg level debug trace calls: HB_USER_PRGFLAGS=-D__HB_DEBUG__ * contrib/hbqt/qtgui/QPageSetupDialog.cpp * contrib/hbqt/qtgui/QGridLayout.cpp * contrib/hbqt/qtgui/QItemSelectionModel.cpp * contrib/hbqt/qtgui/QTextLength.cpp * contrib/hbqt/qtgui/QConicalGradient.cpp * contrib/hbqt/qtgui/QStandardItemModel.cpp * contrib/hbqt/qtgui/QItemSelection.cpp * contrib/hbqt/qtgui/QTransform.cpp * contrib/hbqt/qtgui/QPicture.cpp * contrib/hbqt/qtgui/QAction.cpp * contrib/hbqt/qtgui/QPaintEvent.cpp * contrib/hbqt/qtgui/QStyledItemDelegate.cpp * contrib/hbqt/qtgui/QWidget.cpp * contrib/hbqt/qtgui/QFontDialog.cpp * contrib/hbqt/qtgui/QToolBox.cpp * contrib/hbqt/qtgui/QTextListFormat.cpp * contrib/hbqt/qtgui/QTextEdit.cpp * contrib/hbqt/qtgui/QMouseEvent.cpp * contrib/hbqt/qtgui/QFontComboBox.cpp * contrib/hbqt/qtgui/QStyleOptionHeader.cpp * contrib/hbqt/qtgui/QListView.cpp * contrib/hbqt/qtgui/QRadialGradient.cpp * contrib/hbqt/qtgui/QCursor.cpp * contrib/hbqt/qtgui/QLabel.cpp * contrib/hbqt/qtgui/QPainterPath.cpp * contrib/hbqt/qtgui/QStylePainter.cpp * contrib/hbqt/qtgui/QStyleOptionToolButton.cpp * contrib/hbqt/qtgui/QBrush.cpp * contrib/hbqt/qtgui/QLinearGradient.cpp * contrib/hbqt/qtgui/QProgressBar.cpp * contrib/hbqt/qtgui/QStyleOptionToolBox.cpp * contrib/hbqt/qtgui/QStyleOptionTabBarBase.cpp * contrib/hbqt/qtgui/QToolBar.cpp * contrib/hbqt/qtgui/QFontMetricsF.cpp * contrib/hbqt/qtgui/QToolButton.cpp * contrib/hbqt/qtgui/QWindowsStyle.cpp * contrib/hbqt/qtgui/QColor.cpp * contrib/hbqt/qtgui/QListWidget.cpp * contrib/hbqt/qtgui/QTextLayout.cpp * contrib/hbqt/qtgui/QTextCursor.cpp * contrib/hbqt/qtgui/QTextDocument.cpp * contrib/hbqt/qtgui/QPolygon.cpp * contrib/hbqt/qtgui/QRadioButton.cpp * contrib/hbqt/qtgui/QStyleOptionViewItem.cpp * contrib/hbqt/qtgui/QFileIconProvider.cpp * contrib/hbqt/qtgui/QTextFrameFormat.cpp * contrib/hbqt/qtgui/QTextBlockFormat.cpp * contrib/hbqt/qtgui/QStyleOptionToolBar.cpp * contrib/hbqt/qtgui/QBitmap.cpp * contrib/hbqt/qtgui/QCalendarWidget.cpp * contrib/hbqt/qtgui/QStyleOptionTitleBar.cpp * contrib/hbqt/qtgui/QHeaderView.cpp * contrib/hbqt/qtgui/QScrollBar.cpp * contrib/hbqt/qtgui/QStyleOptionButton.cpp * contrib/hbqt/qtgui/QCommandLinkButton.cpp * contrib/hbqt/qtgui/QFocusFrame.cpp * contrib/hbqt/qtgui/QSizePolicy.cpp * contrib/hbqt/qtgui/QApplication.cpp * contrib/hbqt/qtgui/QTextFragment.cpp * contrib/hbqt/qtgui/QPlainTextEdit.cpp * contrib/hbqt/qtgui/QInputDialog.cpp * contrib/hbqt/qtgui/QKeySequence.cpp * contrib/hbqt/qtgui/QPrinter.cpp * contrib/hbqt/qtgui/QActionGroup.cpp * contrib/hbqt/qtgui/QTextCharFormat.cpp * contrib/hbqt/qtgui/QStyleOptionSlider.cpp * contrib/hbqt/qtgui/QInputEvent.cpp * contrib/hbqt/qtgui/QWidgetItem.cpp * contrib/hbqt/qtgui/QMenu.cpp * contrib/hbqt/qtgui/QStyleOptionSizeGrip.cpp * contrib/hbqt/qtgui/QStyleOptionGroupBox.cpp * contrib/hbqt/qtgui/QImage.cpp * contrib/hbqt/qtgui/QFontInfo.cpp * contrib/hbqt/qtgui/QIcon.cpp * contrib/hbqt/qtgui/QPolygonF.cpp * contrib/hbqt/qtgui/QHBoxLayout.cpp * contrib/hbqt/qtgui/QTreeWidget.cpp * contrib/hbqt/qtgui/QCommonStyle.cpp * contrib/hbqt/qtgui/QProgressDialog.cpp * contrib/hbqt/qtgui/QStyleFactory.cpp * contrib/hbqt/qtgui/QButtonGroup.cpp * contrib/hbqt/qtgui/QSystemTrayIcon.cpp * contrib/hbqt/qtgui/QStyleOptionDockWidget.cpp * contrib/hbqt/qtgui/QColorDialog.cpp * contrib/hbqt/qtgui/QListWidgetItem.cpp * contrib/hbqt/qtgui/QStyleOptionTabWidgetFrame.cpp * contrib/hbqt/qtgui/QDateTimeEdit.cpp * contrib/hbqt/qtgui/QInputMethodEvent.cpp * contrib/hbqt/qtgui/QStyleOptionFocusRect.cpp * contrib/hbqt/qtgui/QMainWindow.cpp * contrib/hbqt/qtgui/QDesktopWidget.cpp * contrib/hbqt/qtgui/QTableWidgetSelectionRange.cpp * contrib/hbqt/qtgui/QWidgetAction.cpp * contrib/hbqt/qtgui/QStringListModel.cpp * contrib/hbqt/qtgui/QDockWidget.cpp * contrib/hbqt/qtgui/QTextBrowser.cpp * contrib/hbqt/qtgui/QTableWidget.cpp * contrib/hbqt/qtgui/QErrorMessage.cpp * contrib/hbqt/qtgui/QWizard.cpp * contrib/hbqt/qtgui/QFileSystemModel.cpp * contrib/hbqt/qtgui/QDial.cpp * c
Re: [Harbour] SF.net SVN: harbour-project:[13171] trunk/harbour
Hi Istvan, > An another test case with full positive results with latest SVN and Qt 4.6 > for VS2008. The MinGW with Qt 4.6 and Qt 4.5.3 follows... > hbide, demoxbp and demoqt are executed crash free, so we should concentrate > on the functional issues from now, I think. Is there any final result for the three different memory handling modes? IMO we should only leave one, the one which works the most efficiently and without leaks. Is it time to make the decision yet? There are still a few remaining issue with HBQT: - Eliminating all GPFs resulting from .prg coding errors. - Initialization/deinitialization (mutex, slots, events) is currently not foolproof and violates wrapper layer levels. This may cause any sort of random crashes AFAICT. - Potential (and real) leaks due to non-collected pointers used in a few places: QT_MYDRAWINGAREA() QT_MYMAINWINDOW() QT_HBDBFMODEL() QT_HBTABLEVIEW() QT_HBTABLEVIEW_NAVIGATE() - Violation of layering by few object: MyDrawingArea(), MyMainWindow(), DbfMode(), TableView(), SyntaxHighlighter(). 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, >I guess this should either be: >@win-make clean install HB_USER_CFLAGS=-MD >OR kept as is, and the trick suggested by Andi could be >used when building hbide: >@hbmk2 -rebuild hbide.hbp -ldflag=-nodefaultlib:MSVCRT.LIB -ldflag=-defaultlib:LIBCMT.LIB Thank you Viktor, Andi. The Andi's solution is less 'intrusive', so see the merged script variant below with the same very positive results: @echo PREREQUISITES: @echo Installed Qt 4.6 for vs2008 to the default directory: C:/Qt/4.6.0/ ... @echo from: http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe @echo Updated c:\download\harbour with the latest SVN @pause @set HB_WITH_QT=C:/Qt/4.6.0/include @set HB_INSTALL_PREFIX=c:\harbour\msvc @call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 @cd c:\downloads\harbour @win-make clean install @set PATH=%PATH%;C:\harbour\msvc\bin @cd c:\downloads\harbour\contrib\hbide @rem @hbmk2 -rebuild hbide.hbp -cflag=-MD @rem the above line is commented and replaced by the trick suggested by Andi: @hbmk2 -rebuild hbide.hbp -ldflag=-nodefaultlib:MSVCRT.LIB -ldflag=-defaultlib:LIBCMT.LIB -info -trace @cd c:\downloads\harbour\contrib\hbxbp\tests @hbmk2 demoxbp.prg -info -trace @cd c:\downloads\harbour\contrib\hbqt\tests @hbmk2 demoqt.prg -info -trace @set PATH=%PATH%;C:\Qt\4.6.0\bin @cd c:\downloads\harbour\contrib\hbide @hbide @pause @cd c:\downloads\harbour\contrib\hbxbp\tests @demoxbp @pause @cd c:\downloads\harbour\contrib\hbqt\tests @demoqt @pause Best regards, István ___ 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:[13193] trunk/harbour
Revision: 13193 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13193&view=rev Author: vszakats Date: 2009-12-09 23:45:23 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-10 00:44 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_destruct.cpp * contrib/hbqt/hbqt_base.cpp * Moved some non-destructor related stuff to hbqt_base.cpp. - Deleted hbqt_debug() low level call. (this temporarily break build, pls be patient) * C level hbqt_getmemused() is now always defined in Windows builds. * Harbour level HBQT_GETMEMUSED() now always works (not just special debug builds). * contrib/hbqt/hbqt_hbqtdbfmodel.cpp * contrib/hbqt/hbqt_hbqttableview.cpp * contrib/hbqt/hbqt_hbqtmymainwindow.cpp * contrib/hbqt/hbqt_slots.cpp * Replaced hbqt_debug() with HB_TRACE() calls. ; NOTE: IMPORTANT: -D__HB_DEBUG__ works no more. Now for debug builds, you have to use the standard Harbour method: HB_USER_CFLAGS=-DHB_TR_LEVEL_DEBUG It's enough to enable this setting when build hbqt lib, to get HBQT trace calls. * contrib/hbqt/hbqt.h ! Added missing 'extern' keywords. ! Added missing 'extern int hbqt_getmemused( void )'. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt_base.cpp trunk/harbour/contrib/hbqt/hbqt_destruct.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtdbfmodel.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtmymainwindow.cpp trunk/harbour/contrib/hbqt/hbqt_hbqttableview.cpp trunk/harbour/contrib/hbqt/hbqt_slots.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
Re: [Harbour] SF.net SVN: harbour-project:[13171] trunk/harbour
Hi, > An another test case with full positive results with latest SVN and Qt 4.6 > for VS2008. The MinGW with Qt 4.6 and Qt 4.5.3 follows... > hbide, demoxbp and demoqt are executed crash free, so we should concentrate > on the functional issues from now, I think. > See below the script used for my tests, please tune/comment it: > > @echo PREREQUISITES: > @echo Installed Qt 4.6 for vs2008 to the default directory: C:/Qt/4.6.0/ > ... > @echo from: > http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe > @echo Updated c:\download\harbour with the latest SVN > @pause > > @set HB_WITH_QT=C:/Qt/4.6.0/include > @set HB_INSTALL_PREFIX=c:\harbour\msvc > call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 > @cd c:\downloads\harbour > @win-make clean install I guess this should either be: @win-make clean install HB_USER_CFLAGS=-MD OR kept as is, and the trick suggested by Andi could be used when building hbide: @hbmk2 -rebuild hbide.hbp -ldflag=-nodefaultlib:MSVCRT.LIB -ldflag=-defaultlib:LIBCMT.LIB > @set PATH=%PATH%;C:\harbour\msvc\bin > @cd c:\downloads\harbour\contrib\hbide > @hbmk2 -rebuild hbide.hbp -cflag=-MD > @cd c:\downloads\harbour\contrib\hbxbp\tests > @hbmk2 -rebuild demoxbp.prg > @cd c:\downloads\harbour\contrib\hbqt\tests > @hbmk2 -rebuild demoqt.prg Just a minor note, -rebuild only has an effect in -inc mode, and -inc mode is currently enabled only inside hbide.hbp, so it's not needed for the other two cases. It doesn't do any harm though. 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:[13192] trunk/harbour
Revision: 13192 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13192&view=rev Author: vszakats Date: 2009-12-09 22:37:41 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 23:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * ChangeLog - examples/hbapollo/ChangeLog - Deleted redundant old local ChangeLog. ; We have only one ChangeLog now. Modified Paths: -- trunk/harbour/ChangeLog Removed Paths: - trunk/harbour/examples/hbapollo/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13191] trunk/harbour
Revision: 13191 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13191&view=rev Author: vszakats Date: 2009-12-09 22:34:52 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 23:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * ChangeLog - contrib/hbtip/ChangeLog * Old local ChangeLog merged into the central one. - examples/hbvpdf/ChangeLog + examples/hbvpdf/readme.txt * Renamed. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/examples/hbvpdf/readme.txt Removed Paths: - trunk/harbour/contrib/hbtip/ChangeLog trunk/harbour/examples/hbvpdf/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[13171] trunk/harbour
Hi An another test case with full positive results with latest SVN and Qt 4.6 for VS2008. The MinGW with Qt 4.6 and Qt 4.5.3 follows... hbide, demoxbp and demoqt are executed crash free, so we should concentrate on the functional issues from now, I think. See below the script used for my tests, please tune/comment it: @echo PREREQUISITES: @echo Installed Qt 4.6 for vs2008 to the default directory: C:/Qt/4.6.0/ ... @echo from: http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe @echo Updated c:\download\harbour with the latest SVN @pause @set HB_WITH_QT=C:/Qt/4.6.0/include @set HB_INSTALL_PREFIX=c:\harbour\msvc call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 @cd c:\downloads\harbour @win-make clean install @set PATH=%PATH%;C:\harbour\msvc\bin @cd c:\downloads\harbour\contrib\hbide @hbmk2 -rebuild hbide.hbp -cflag=-MD @cd c:\downloads\harbour\contrib\hbxbp\tests @hbmk2 -rebuild demoxbp.prg @cd c:\downloads\harbour\contrib\hbqt\tests @hbmk2 -rebuild demoqt.prg @set PATH=%PATH%;C:\Qt\4.6.0\bin @cd c:\downloads\harbour\contrib\hbide @hbide @pause @cd c:\downloads\harbour\contrib\hbxbp\tests @demoxbp @pause @cd c:\downloads\harbour\contrib\hbqt\tests @demoqt @pause 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:[13174] trunk/harbour
Hi Mindaugas, >> All non static functions from linked .prg module are automatically >> registered in global symbol table so I guess you are talking about >> C code. > > Yes, you are right. I should remember myself, that his effect happens > if functions are implemented in C. > > 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. Sorry to jump in, but wouldn't it be cleaner to add hbcaiext.ch (or some other 8.3 name) just like we do for other contrib and core? It seems more straightforward to use to me, it's also cleaner to maintain, as the separate file can be much easier generated by automated tool. 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:[13174] trunk/harbour
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(). All non static functions from linked .prg module are automatically registered in global symbol table so I guess you are talking about C code. Yes, you are right. I should remember myself, that his effect happens if functions are implemented in C. 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. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13190] trunk/harbour
Revision: 13190 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13190&view=rev Author: vszakats Date: 2009-12-09 21:27:11 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 22:26 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * ChangeLog - contrib/hbtpathy/ChangeLog * Old local ChangeLog merged into the central one. Modified Paths: -- trunk/harbour/ChangeLog Removed Paths: - trunk/harbour/contrib/hbtpathy/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13189] trunk/harbour
Revision: 13189 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13189&view=rev Author: vszakats Date: 2009-12-09 21:22:35 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 22:22 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * INSTALL * Minor cleanups. * ChangeLog - contrib/hbpgsql/ChangeLog * Old local ChangeLog merged into the central one. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL Removed Paths: - trunk/harbour/contrib/hbpgsql/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13188] trunk/harbour
Revision: 13188 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13188&view=rev Author: druzus Date: 2009-12-09 20:26:18 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 21:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/xhb/fparse.c ! fixed few GPF traps and memory leaks % added some minor optimization I strongly suggest to use hb_aTokens() and hb_token*() functions. They have more options and for really large data many times (even hundreds times) faster. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/fparse.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:[13187] trunk/harbour
Revision: 13187 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13187&view=rev Author: vszakats Date: 2009-12-09 20:18:31 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 21:17 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbgd/gdwrp.c * Formatting (deleted unnecessary returns and blocks). * ChangeLog - contrib/hbgd/ChangeLog * Merged local ChangeLog into central one. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbgd/gdwrp.c Removed Paths: - trunk/harbour/contrib/hbgd/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] FPARSELINE from xhb.lib & Application Internal Error
Hi All PROCEDURE Main() LOCAL cText, aData cText := '"Jones, Mr",Male,"Oklahoma","IL",20041231,"Director, President"' aData := FParseLine( cText ) FOR EACH cText IN aData ? LTrim( Str( HB_EnumIndex() ) ), cText NEXT Application Internal Error - E:\harbour-mingw\bin\test.exe Terminated at: 2009.12.09 21:52:52 Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:00425B9E EAX:004D7030 EBX: ECX: EDX: ESI: EDI:0001 EBP:0022FD1C CS:EIP:001B:00425B9E SS:ESP:0023:0022FC90 DS:0023 ES:0023 FS:003B GS: Flags:00010206 CS:EIP: 8B 06 25 05 B4 FF FF 66 85 C0 0F 85 C5 00 00 00 SS:ESP: 00A5E6B4 004D8464 0003 00483EBE 00A59B54 0022FCC0 001F 00483EBE 00A5106C 00A513A0 0001 00401ACC C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... Modules: 0x0040 0x000F4000 E:\harbour-mingw\bin\fn.exe 0x7C90 0x000B C:\WINDOWS\system32\ntdll.dll 0x7C80 0x000F8000 C:\WINDOWS\system32\kernel32.dll 0x77C0 0x00058000 C:\WINDOWS\system32\msvcrt.dll 0x7E36 0x00091000 C:\WINDOWS\system32\USER32.dll 0x77F1 0x00049000 C:\WINDOWS\system32\GDI32.dll 0x7636 0x0001D000 C:\WINDOWS\system32\IMM32.DLL 0x77DC 0x000AC000 C:\WINDOWS\system32\ADVAPI32.dll 0x77E7 0x00092000 C:\WINDOWS\system32\RPCRT4.dll 0x77FE 0x00011000 C:\WINDOWS\system32\Secur32.dll Called from FPARSELINE(0) Called from MAIN(6) in fn.prg Regards, Petr -- View this message in context: http://old.nabble.com/FPARSELINE-from-xhb.lib---Application-Internal-Error-tp26716657p26716657.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13186] trunk/harbour
Revision: 13186 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13186&view=rev Author: druzus Date: 2009-12-09 19:55:17 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 20:55 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/rddsql/sqlbase.c ! fixed yet another typo Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/rddsql/sqlbase.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:[13185] trunk/harbour
Revision: 13185 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13185&view=rev Author: druzus Date: 2009-12-09 19:41:10 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 20:40 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/Makefile ! added missing newly added header files - thanks to Itamar for information about the problem * harbour/include/hbmsgreg.h ! fixed typo - thanks to Toninho for information about the problem Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/Makefile trunk/harbour/include/hbmsgreg.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] Re: Re: Re: SF.net SVN: harbour-project:[13174]trunk/harbour
On Wed, 09 Dec 2009, Itamar Lins wrote: Hi, > I found the problem. > D:\harbour\trunk\harbour\include>copy hbiniseg.h d:\DEV\harbour\include > 1 arquivo(s) copiado(s). > D:\harbour\trunk\harbour\include> > And now working fine. > Because initial process of making harbour not copying new file. Yes, you are right and I was wrong. Thank you very much for the information. It will be fixed in next commit. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Re: Re: SF.net SVN: harbour-project:[13174]trunk/harbour
Hi! I found the problem. D:\harbour\trunk\harbour\include>copy hbiniseg.h d:\DEV\harbour\include 1 arquivo(s) copiado(s). D:\harbour\trunk\harbour\include> And now working fine. Because initial process of making harbour not copying new file. Best Regards, Itamar M. Lins Jr. "Przemyslaw Czerpak" escreveu na mensagem news:20091209192617.ga5...@linux-4bod.home.aster.pl... > On Wed, 09 Dec 2009, Itamar Lins wrote: > > Hi, > >> But, working fine at: >> >Log Message: >> >--- >> >2009-12-09 12:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > > That's very bad news for you because it confirms that you are building > Harbour using wrong header files in some places. Some of them comes from > current code and some of them are taken from old builds. Probably from > old install directory which for sure cannot contain newly added files > like hbiniseg.h so you have above error message. > Using invalid header files may cause any unpredictable results. > As long as you do not clean your environment settings you should > expect that Harbour binaries you are creating are broken. > > best regards, > Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Re: SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 09 Dec 2009, Itamar Lins wrote: Hi! > hbiniseg.h is new file update harbour make for count on it. You are right. My fault. I'm really sorry. I'll fix it in a while. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Undefined symbol 'hb_lang_Init_'
On Wed, 09 Dec 2009, Antonio Carlos wrote: Hi, > I have an error with clean build and latest SVN: > bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS > -Ov -Oi -Oc -I"c:\harbour\bcc55\bin\..\Include" > -DHB_GUI -DHB_NO_PROFILER -DADS_LIB_VERSION=700 -DHB_HASH_MSG_ITEMS > -DHB_NO_DEBUG -DHB_LEGACY_OFF -DHB_FM_STD_ALLOC -omsgbe866.obj -c > ../../../msgbe866.c > ../../../msgbe866.c: > Error E2451 ../../../../../include\hbmsgreg.h 68: Undefined symbol > 'hb_lang_Init_' > + Full parser context > + ../../../msgbe866.c, line 204: #include ../../../../../include\hbmsgreg.h > *** 1 errors in Compile *** Thank you for the information. I'll fix it ASAP. 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Re: SF.net SVN: harbour-project:[13174] trunk/harbour
Hi! Please look. > * harbour/include/hbinit.h > + harbour/include/hbiniseg.h >* replaced HB_MSC_STARTUP code with more universal HB_DATASEG_STARTUP >* moved HB_DATASEG_STARTUP code to separate header file to reduce > modifications in other files when this code has to be changed or > extended hbiniseg.h is new file update harbour make for count on it. Best regards, Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Re: SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 09 Dec 2009, Itamar Lins wrote: Hi, > But, working fine at: > >Log Message: > >--- > >2009-12-09 12:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) That's very bad news for you because it confirms that you are building Harbour using wrong header files in some places. Some of them comes from current code and some of them are taken from old builds. Probably from old install directory which for sure cannot contain newly added files like hbiniseg.h so you have above error message. Using invalid header files may cause any unpredictable results. As long as you do not clean your environment settings you should expect that Harbour binaries you are creating are broken. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 09 Dec 2009, Itamar Lins wrote: Hi! > > * modified to use HB_DATASEG_STARTUP instead of HB_MSC_STARTUP > > Now HB_MSC_STARTUP is local macro used only in hbinit.h. > > Please make MSVC build tests. > ! Making D:\DEV\HARBOUR\bin\hbmk.cfg... > .\bin\postinst.bat > ! Making shared version of Harbour binaries... > Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 > Copyright (C) Microsoft Corporation. All rights reserved. > hbrun.c > hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > suc Thank you for your tests but above problem you created yourself in your local SVN copy. It's not Harbour problem at all. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Undefined symbol 'hb_lang_Init_'
Hi friends, I have an error with clean build and latest SVN: bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -I"c:\harbour\bcc55\bin\..\Include" -DHB_GUI -DHB_NO_PROFILER -DADS_LIB_VERSION=700 -DHB_HASH_MSG_ITEMS -DHB_NO_DEBUG -DHB_LEGACY_OFF -DHB_FM_STD_ALLOC -omsgbe866.obj -c ../../../msgbe866.c ../../../msgbe866.c: Error E2451 ../../../../../include\hbmsgreg.h 68: Undefined symbol 'hb_lang_Init_' + Full parser context + ../../../msgbe866.c, line 204: #include ../../../../../include\hbmsgreg.h *** 1 errors in Compile *** TIA and best regards, Toninho. Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com ___ 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:[13184] trunk/harbour
Revision: 13184 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13184&view=rev Author: vszakats Date: 2009-12-09 19:13:10 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 20:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/wapi_winbase.c + WAPI_WAITFORSINGLEOBJECT() + WAPI_WAITFORSINGLEOBJECTEX() + WAPI_WAITFORMULTIPLEOBJECT() + WAPI_WAITFORMULTIPLEOBJECTEX() Added new wrappers. Untested. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/wapi_winbase.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:[13183] trunk/harbour
Revision: 13183 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13183&view=rev Author: vszakats Date: 2009-12-09 18:38:42 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 19:36 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/Makefile * contrib/hbqt/hbqt.ch - contrib/hbqt/hbqt_misc.prg * contrib/hbxbp/xbp.ch * contrib/hbxbp/xbpgeneric.prg + Replaced local trace solution with HB_TRACESTRING(). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/Makefile trunk/harbour/contrib/hbqt/hbqt.ch trunk/harbour/contrib/hbxbp/xbp.ch trunk/harbour/contrib/hbxbp/xbpgeneric.prg Removed Paths: - trunk/harbour/contrib/hbqt/hbqt_misc.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: Re: SF.net SVN: harbour-project:[13174] trunk/harbour
Hi! But, working fine at: >Log Message: >--- >2009-12-09 12:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbwin/legacyco.c > * contrib/hbwin/wapi_winuser.c > ! Added missing header. Now new make.bat --->8 set include= call "%ProgramFiles%\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" win-make clean install 8<- I get same problem below. >hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': >No > suc > h file or directory >... Best regards, Itamar M. Lins Jr. "Viktor Szakáts" escreveu na mensagem news:117bd1d5-7926-46b2-8f87-785a693a1...@syenar.hu... I guess you're still using 'set INCLUDE' in your environment. Delete it. Brgds, Viktor On 2009 Dec 9, at 19:07, Itamar Lins wrote: > Hi! > >> * modified to use HB_DATASEG_STARTUP instead of HB_MSC_STARTUP >> Now HB_MSC_STARTUP is local macro used only in hbinit.h. >> Please make MSVC build tests. > > ! Making D:\DEV\HARBOUR\bin\hbmk.cfg... > .\bin\postinst.bat > ! Making shared version of Harbour binaries... > Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > hbrun.c > hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > suc > h file or directory > hbmk2: Error: Running C compiler. 2 > hbmk2.c > hbmk2.c(623) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > suc > h file or directory > hbmk2: Error: Running C compiler. 2 > hbtest.c > hbtest.c(233) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_array.c > rt_array.c(80) : fatal error C1083: Cannot open include file: > 'hbiniseg.h': > No s > uch file or directory > rt_date.c > rt_date.c(54) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_file.c > rt_file.c(65) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_hvm.c > rt_hvm.c(66) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > suc > h file or directory > rt_hvma.c > rt_hvma.c(71) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_math.c > rt_math.c(64) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_misc.c > rt_misc.c(149) : fatal error C1083: Cannot open include file: > 'hbiniseg.h': > No s > uch file or directory > rt_mt.c > rt_mt.c(56) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > such > file or directory > rt_str.c > rt_str.c(94) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > suc > h file or directory > rt_stra.c > rt_stra.c(59) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_trans.c > rt_trans.c(38) : fatal error C1083: Cannot open include file: > 'hbiniseg.h': > No s > uch file or directory > rt_class.c > rt_class.c(140) : fatal error C1083: Cannot open include file: > 'hbiniseg.h': > No > such file or directory > rt_miscc.c > Generating Code... > hbmk2: Error: Running C compiler. 2 > hbi18n.c > hbi18n.c(108) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > hbmk2: Error: Running C compiler. 2 > hbformat.c > hbformat.c(233) : fatal error C1083: Cannot open include file: > 'hbiniseg.h': > No > such file or directory > hbformac.c > Generating Code... > hbmk2: Error: Running C compiler. 2 > ! Making hbrun with application icon... > Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > hbrun.c > hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > suc > h file or directory > hbmk2: Error: Running C compiler. 2 > > D:\harbour\trunk\harbour> > > Best regards, > Itamar M. Lins Jr. > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13174] trunk/harbour
I guess you're still using 'set INCLUDE' in your environment. Delete it. Brgds, Viktor On 2009 Dec 9, at 19:07, Itamar Lins wrote: > Hi! > >> * modified to use HB_DATASEG_STARTUP instead of HB_MSC_STARTUP >> Now HB_MSC_STARTUP is local macro used only in hbinit.h. >> Please make MSVC build tests. > > ! Making D:\DEV\HARBOUR\bin\hbmk.cfg... > .\bin\postinst.bat > ! Making shared version of Harbour binaries... > Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > hbrun.c > hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > suc > h file or directory > hbmk2: Error: Running C compiler. 2 > hbmk2.c > hbmk2.c(623) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > suc > h file or directory > hbmk2: Error: Running C compiler. 2 > hbtest.c > hbtest.c(233) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_array.c > rt_array.c(80) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No s > uch file or directory > rt_date.c > rt_date.c(54) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_file.c > rt_file.c(65) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_hvm.c > rt_hvm.c(66) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > suc > h file or directory > rt_hvma.c > rt_hvma.c(71) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_math.c > rt_math.c(64) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_misc.c > rt_misc.c(149) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No s > uch file or directory > rt_mt.c > rt_mt.c(56) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > such > file or directory > rt_str.c > rt_str.c(94) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > suc > h file or directory > rt_stra.c > rt_stra.c(59) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > rt_trans.c > rt_trans.c(38) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No s > uch file or directory > rt_class.c > rt_class.c(140) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > such file or directory > rt_miscc.c > Generating Code... > hbmk2: Error: Running C compiler. 2 > hbi18n.c > hbi18n.c(108) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No su > ch file or directory > hbmk2: Error: Running C compiler. 2 > hbformat.c > hbformat.c(233) : fatal error C1083: Cannot open include file: 'hbiniseg.h': > No > such file or directory > hbformac.c > Generating Code... > hbmk2: Error: Running C compiler. 2 > ! Making hbrun with application icon... > Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > hbrun.c > hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No > suc > h file or directory > hbmk2: Error: Running C compiler. 2 > > D:\harbour\trunk\harbour> > > Best regards, > Itamar M. Lins Jr. > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ 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:[13182] trunk/harbour
Revision: 13182 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13182&view=rev Author: vszakats Date: 2009-12-09 18:16:36 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 19:13 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/common/hbtrace.c + Added support for HB_TR_WINOUT envvar (on Windows platform-only) to enable pushing trace output via OutputDebugString() calls. Use this before running an app: set HB_TR_WINOUT=yes (anything non-empty would work, not just 'yes') * src/rtl/trace.c + HB_TRACESTRING(): Added support to accept multiple parameters, it also handles non-string parameters, just like OUTSTD()/QOUT(). % Minor optimization to HB_TRACE() call. ; NOTE: Above two changes make it unnecessary to use custom made debug/trace solutions inside each contrib, and it also makes it unnecessary to use xhb lib for other proprietary trace solutions. * src/rtl/console.c * Variable scope optimization. * contrib/hbgd/gdwrp.c * Minor formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbgd/gdwrp.c trunk/harbour/src/common/hbtrace.c trunk/harbour/src/rtl/console.c trunk/harbour/src/rtl/trace.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] Re: SF.net SVN: harbour-project:[13174] trunk/harbour
Hi! > * modified to use HB_DATASEG_STARTUP instead of HB_MSC_STARTUP > Now HB_MSC_STARTUP is local macro used only in hbinit.h. > Please make MSVC build tests. ! Making D:\DEV\HARBOUR\bin\hbmk.cfg... .\bin\postinst.bat ! Making shared version of Harbour binaries... Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 Copyright (C) Microsoft Corporation. All rights reserved. hbrun.c hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No suc h file or directory hbmk2: Error: Running C compiler. 2 hbmk2.c hbmk2.c(623) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No suc h file or directory hbmk2: Error: Running C compiler. 2 hbtest.c hbtest.c(233) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory rt_array.c rt_array.c(80) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No s uch file or directory rt_date.c rt_date.c(54) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory rt_file.c rt_file.c(65) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory rt_hvm.c rt_hvm.c(66) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No suc h file or directory rt_hvma.c rt_hvma.c(71) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory rt_math.c rt_math.c(64) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory rt_misc.c rt_misc.c(149) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No s uch file or directory rt_mt.c rt_mt.c(56) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No such file or directory rt_str.c rt_str.c(94) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No suc h file or directory rt_stra.c rt_stra.c(59) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory rt_trans.c rt_trans.c(38) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No s uch file or directory rt_class.c rt_class.c(140) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No such file or directory rt_miscc.c Generating Code... hbmk2: Error: Running C compiler. 2 hbi18n.c hbi18n.c(108) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No su ch file or directory hbmk2: Error: Running C compiler. 2 hbformat.c hbformat.c(233) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No such file or directory hbformac.c Generating Code... hbmk2: Error: Running C compiler. 2 ! Making hbrun with application icon... Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 Copyright (C) Microsoft Corporation. All rights reserved. hbrun.c hbrun.c(165) : fatal error C1083: Cannot open include file: 'hbiniseg.h': No suc h file or directory hbmk2: Error: Running C compiler. 2 D:\harbour\trunk\harbour> Best regards, Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Create Process API - Brief Overview Requested
On Wed, 09 Dec 2009, Szak�ts Viktor wrote: Hi, > > Just to show the other benefits it renders. > > I am simply short of process API in Harbour, > > examined hbprocfn.c to go through all the details, > > but I could not find how to capture process output > > in buffer which process is in running state. hProcess := HB_PROCESSOPEN( , NIL, @hStdOut, @hStderr, lDeatch ) It creates new process and you can read form hStdOut and hStderr the process output. You can check running process state using nState := HB_PROCESSVALUE( hProcess, lWait ) Do not forget to close all handles passed by reference to HB_PROCESSOPEN() using FCLOSE() function when they are not longer necessary. Please only remember that HB_PROCESSOPEN() does not work for platforms which do not support simultaneous multiprocessing. HB_PROCESSRUN() works for all platforms and if necessary standard files are used to exchange stdin/stdout/stderr data. > > I can see that stdout and stderr andles but do not > > know hoe effectively I can use them. > > Plus hb_processRun() opens the console window > > which I do not want to. It's not true. Neither hb_processRun() nor hb_processOpen() creates console window. Such window can be created only by executed application and it's out of calling process control. It doesn't matter how you will call it. You can only try to pass to executed application request to minimize such window using lDetach or some parameter like //gtnul for [x]Harbour applications which disables default GT. > > I must be missing on this front, that's why > > I had requested the api syntax. QT is only upper level wrapper to the same low level CreateProcess() function. > > Qt process implementation will take only two minutes > > to remove from SVN, I was just comparing the results > > from both impleentations. > Okay. IMO you should ask above things from Przemek > to see how process API can be used for such things > like catching stdout/err in real-time. HB_PROCESSOPEN() then FREAD() until HB_PROCESSVALUE() == -1 and then FCLOSE() for open handles. If you plan to implement everything in single thread and make in the loop some other things then probably you will need sth like wrapper to WAPI WaitForSingleObject() or WaitForMultipleObjects() to avoid freezing the process on FREAD( hStdOut, @cBuff, len( cBuff ) ) That's all. 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:[13174] trunk/harbour
On Wed, 09 Dec 2009, Vailton Renato wrote: Hi, > On xHarbour they have the /vd parameter to automatically convert all > external functions as dynamic functions. The final application has to > behave as the Clipper, generating a RTE when the function is not > found. -vd switch is interesting feature which is really usable in some cases though I would prefer a little bit more flexible method of generating references list. Probably a tool to manage .hrb files and create .hrl libraries which will have an option to generate external dependencies list is much better idea. .ext files generated by xHarbour when -vd switch is used are usable only if .hrb file does not have any references to functions in other .hrb files and this problem can be resolved only by external program which will generate such list for group of .hrb files. Maybe I'll add support for -vd switch to Harbour but rather without generating .ext files or at least they will be activated optionally, i.e. by -vd+ > But in Harbour I have been testing a tool what I developed to > analyze the C code from my PRG sources, that are external to the > current code but what not exist inside hbextern.ch and make statements > DYNAMIC for me ... but do not think this tool an elegant solution. Without replicating the full C preprocessor such tools can always be confused by some code. It may not be big problem for creating documentation or some other data which later can be manually corrected but it does not allow to use such solution as automatized part of build process for any source code. It's much easier to extract such information from final .hrb, .o (.obj), .a (.lib) files because we data in some strictly defined formats. 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:[13181] trunk/harbour
Revision: 13181 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13181&view=rev Author: vszakats Date: 2009-12-09 16:52:49 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 17:51 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbnf/dispc.c * contrib/hbfimage/fi_winfu.c * contrib/hbfimage/fi_wrp.c * contrib/hbgd/gdwrp.c * Changed to use HB_IS*() macros to check parameter types instead of using hb_parinfo() & HB_IT_*. * Formatting. (deleted unnecessary blocks, returns, spaces) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbfimage/fi_winfu.c trunk/harbour/contrib/hbfimage/fi_wrp.c trunk/harbour/contrib/hbgd/gdwrp.c trunk/harbour/contrib/hbnf/dispc.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:[13174] trunk/harbour
On Wed, 09 Dec 2009, Tamas TEVESZ wrote: Hi, > wcc386 -zq -bt=nt -bm -w3 -3s -i. -i../../../../../include -d2 > -DHB_TR_LEVEL_DEBUG -DHB_STATIC_STARTUP -fo=pplib3.obj > ../../../pplib3.c > ../../../pplib3.c(68): Error! E1054: Expression must be constant > ../../../pplib3.c(68): Warning! W202: Symbol 'symbols' has been > defined, but not referenced > make[3]: *** [pplib3.obj] Error 1 > make[2]: *** [descend] Error 2 > make[1]: *** [pp] Error 2 > make: *** [src] Error 2 > > this same symptoms show also with os2, dos and linux (native build) > targets as well. > > full build logs available if need be, but they all very much look the > same as this above. You created the problem using HB_STATIC_STARTUP macro. It forces using C++ startup initialization which is not available in pure C mode. Please remove this macro. 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:[13174] trunk/harbour
Hi! On xHarbour they have the /vd parameter to automatically convert all external functions as dynamic functions. The final application has to behave as the Clipper, generating a RTE when the function is not found. But in Harbour I have been testing a tool what I developed to analyze the C code from my PRG sources, that are external to the current code but what not exist inside hbextern.ch and make statements DYNAMIC for me ... but do not think this tool an elegant solution. Sorry for bad English. Best regards, Vailton Renato ___ 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, 9 Dec 2009, Tamas TEVESZ wrote: > ! HB_USER_CFLAGS: -DHB_STATIC_STARTUP i am so shutting up right about now. i forgot this in from a previous experiment ;( sorry for the noise. -- [-] mkdir /nonexistent ___ 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 Bisz István wrote: > > 3. demoqt crash at exit (x button pressed) just in ST; in MT is crash > free. > At present demoqt employs HBQT_RELEASE_WITH_DELETE method to free the pointers. Can you test with other methods too? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13171--trunk-harbour-tp26704226p26712856.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13180] trunk/harbour
Revision: 13180 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13180&view=rev Author: vouchcac Date: 2009-12-09 16:09:11 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 08:07 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbxbp/xbpdataref.prg ! Fix in XbpMLE():setData() method, omitted in prev change. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbxbp/xbpdataref.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
Re: [Harbour] SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 09 Dec 2009, Mindaugas Kavaliauskas wrote:
Hi,
> > * harbour/contrib/hbmemio/memio.c
> >! declare s_fileFuncs structure as static
> >* removed unnecessary code to directly register HB_MEMIO symbol.
> > Mindaugas if you need it for some reasons then I can reactivate it
> > but I would like to know why it's necessary for you.
> 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. It's "more or less" Clipper
compatible method to register RDD and it's working. If you think it's
usable then we can replace it with alternative method which do not use
global symbol table.
> Another question: many functions of some module are used from
> runtime loaded .hrb files. I use REQUEST to force linking this
> module into .exe. I current code I need to explicitly request every
> function to make it available in .hrb. Is where a way to include all
> functions of module into global symbol table? All of the functions
> are inside .exe anyway.
All non static functions from linked .prg module are automatically
registered in global symbol table so I guess you are talking about
C code. Here we do not have any information about existing functions
if module does not register such list itself using:
HB_INIT_SYMBOLS_BEGIN( ... )
[...]
HB_INIT_SYMBOLS_END( ... )
Of course module stored in libraries is linked with final application
if this application uses at least one of the module's public functions.
For core code functions you can use:
#include "hbextern.ch"
or:
REQUEST __HB_EXTERN__ /* force linking symbols by hbextern library */
For you own code you may try to generate such list automatically
from standard binaries. F.e. I was using this code to create list
of DYNAMIC symbols to include in .HRB files:
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
You can easy modify it to generate list ofREQUEST-ed functions
if you you simply replace "DYNAMIC " with "REQUEST "
Tou can even use the same file for both things if you add some
header like:
#ifdef __HRB__
#define SYM_SCOPE DYNAMIC
#else
#define SYM_SCOPE REQUEST
#endif
and then generate list for "SYM_SCOPE ".
In the future it will be good to create some tool to manage
compiled .hrb files and generate such lists from given .hrb modules.
For some C compilers like GCC you can quite easy create simply
script which extracts public internal and external function
from given .o and .a files using tools like 'nm'
But we do not have anything to create such list dynamically during
linking. In practice it will be necessary to integrate such code
with linker to make it.
We can also fully change the method of function encapsulation
and register each single function in C code. Such alternative
method can be also used to eliminate current startup initialization
code. Maybe we will try to make sth like that in the future.
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:[13171] trunk/harbour
Hi Bisz István wrote: > > 1. hbide crash free in both MT and ST. > Good news. > 2. demoxbp crash at startup in both MT and ST. > A last minute change in XbpMLE() - QTextEdit() => QPlainTextEdit(). Will fix in a while. > 3. demoqt crash at exit (x button pressed) just in ST; in MT is crash > free. > I could not get why this error. I will dig deep later. Thank you for reports. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13171--trunk-harbour-tp26704226p26712494.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 9 Dec 2009, dru...@users.sourceforge.net wrote: hi, > Revision: 13174 something is not quite right. i have added c builds to my test suite (they are all cross-builds on a linux host), and they do not build: ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: make 3.81 /bin/sh ! HB_USER_CFLAGS: -DHB_STATIC_STARTUP ! HB_INSTALL_PREFIX: /home/ice/w/xhb/hbci/inst/win/watcom/c ! HB_BUILD_DEBUG: yes ! HB_BUILD_OPTIM: no ! HB_BUILD_MODE: c ! HB_BUILD_EXTDEF: no ! HB_CONTRIBLIBS: no ! HB_HOST_PLAT: linux (x86_64) HB_SHELL: sh ! HB_PLATFORM: win (x86) ! HB_COMPILER: watcom ! HB_BIN_COMPILE not specified. Automatically set to: /usr/bin ! Component: 'zlib' found in /home/ice/w/xhb/hbci/harbour-build/external/zlib (local) ! Component: 'pcre' found in /home/ice/w/xhb/hbci/harbour-build/external/pcre (local) ! Component: 'openssl' not supported with watcom compiler ! Component: 'gpm' not supported on win platform ! Component: 'slang' not found ! Component: 'curses' not found ! Component: 'x11' not found ! Component: 'wattcp/watt-32' not supported on win platform ! REVISION: 13177 [...] wcc386 -zq -bt=nt -bm -w3 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -DHB_STATIC_STARTUP -fo=pplib2_dyn.obj -DHB_DYNLIB ../../../pplib2.c wcc386 -zq -bt=nt -bm -w3 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -DHB_STATIC_STARTUP -fo=pplib3.obj ../../../pplib3.c ../../../pplib3.c(68): Error! E1054: Expression must be constant ../../../pplib3.c(68): Warning! W202: Symbol 'symbols' has been defined, but not referenced make[3]: *** [pplib3.obj] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [pp] Error 2 make: *** [src] Error 2 this same symptoms show also with os2, dos and linux (native build) targets as well. full build logs available if need be, but they all very much look the same as this above. -- [-] mkdir /nonexistent ___ 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:[13179] trunk/harbour
Revision: 13179 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13179&view=rev Author: vszakats Date: 2009-12-09 15:43:37 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 16:43 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/olecore.c * Changed to use HB_SIZE instead of ULONG. ; Please review me, I wouldn't like to break OLE code. ; Only one place remains in hbwin which uses ULONG, as return value of hb_fsSeek(). In this case we need to think about it some more. * contrib/hbqt/hbqt.ch * Minor formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.ch trunk/harbour/contrib/hbwin/olecore.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:[13178] trunk/harbour
Revision: 13178 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13178&view=rev Author: vszakats Date: 2009-12-09 15:35:07 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 16:33 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_slots.cpp % Eliminated two variables. * contrib/hbwin/oleinit.c * contrib/hbwin/win_misc.c * contrib/hbwin/wapi_winuser.c * contrib/hbwin/axcore.c * contrib/hbwin/olecore.c * contrib/hbwin/win_com.c * contrib/hbwin/wapi_commctrl.c * Using HB_TRUE / HB_FALSE consistenly everywhere. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbwin/axcore.c trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/contrib/hbwin/oleinit.c trunk/harbour/contrib/hbwin/wapi_commctrl.c trunk/harbour/contrib/hbwin/wapi_winuser.c trunk/harbour/contrib/hbwin/win_com.c trunk/harbour/contrib/hbwin/win_misc.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:[13177] trunk/harbour
Revision: 13177 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13177&view=rev Author: vszakats Date: 2009-12-09 15:17:22 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 16:16 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * INSTALL + Updated Open Watcom product names to reflect that now plain C is supported as well. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL 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:[13174] trunk/harbour
>>> * harbour/contrib/hbmemio/memio.c >>> ! declare s_fileFuncs structure as static >>> * removed unnecessary code to directly register HB_MEMIO symbol. >>> Mindaugas if you need it for some reasons then I can reactivate it >>> but I would like to know why it's necessary for you. >> I'm using code like 'Type( "HB_MEMIO()" ) == "UI"' to >> detect presence of HB_MEMIO in executable. >> Would this still work, or is there a superior way for >> detection? > > Yes, > HB_MEMIO() is the only one public symbol in hbmemio library > so it's linked only when you have in source code: > REQUEST HB_MEMIO > which also registers this symbols in global symbol table. Very good. Thank you! 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:[13174] trunk/harbour
On Wed, 09 Dec 2009, Szak�ts Viktor wrote: Hi, > > * harbour/contrib/hbmemio/memio.c > >! declare s_fileFuncs structure as static > >* removed unnecessary code to directly register HB_MEMIO symbol. > > Mindaugas if you need it for some reasons then I can reactivate it > > but I would like to know why it's necessary for you. > I'm using code like 'Type( "HB_MEMIO()" ) == "UI"' to > detect presence of HB_MEMIO in executable. > Would this still work, or is there a superior way for > detection? Yes, HB_MEMIO() is the only one public symbol in hbmemio library so it's linked only when you have in source code: REQUEST HB_MEMIO which also registers this symbols in global symbol table. 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:[13176] trunk/harbour
Revision: 13176 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13176&view=rev Author: vszakats Date: 2009-12-09 15:10:58 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 16:09 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * INSTALL * utils/hbmk2/hbmk2.prg * config/dos/watcom.mk * config/win/watcom.mk * config/linux/watcom.mk * config/os2/watcom.mk + Switched back plain C mode for watcom compiler. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/dos/watcom.mk trunk/harbour/config/linux/watcom.mk trunk/harbour/config/os2/watcom.mk trunk/harbour/config/win/watcom.mk 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
Re: [Harbour] SF.net SVN: harbour-project:[13174] trunk/harbour
Hi, Great commit, thanks. On 2009 Dec 9, at 15:33, dru...@users.sourceforge.net wrote: > Revision: 13174 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13174&view=rev > > * harbour/contrib/hbmemio/memio.c >! declare s_fileFuncs structure as static >* removed unnecessary code to directly register HB_MEMIO symbol. > Mindaugas if you need it for some reasons then I can reactivate it > but I would like to know why it's necessary for you. I'm using code like 'Type( "HB_MEMIO()" ) == "UI"' to detect presence of HB_MEMIO in executable. Would this still work, or is there a superior way for detection? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Can we bind variables in sql?
Hi, Horodyski Marek (PZUZ) wrote: can we bind variable in selects with SQLMIX ? ... Select * ftom table where Field1 = :var1 and Fiefd2 between :var2 and :var3 ... No, you can use request with already bound variables. Regards, Mindaugas ___ 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
Hi, * harbour/contrib/hbmemio/memio.c ! declare s_fileFuncs structure as static * removed unnecessary code to directly register HB_MEMIO symbol. Mindaugas if you need it for some reasons then I can reactivate it but I would like to know why it's necessary for you. Perhaps copy-paste from some of my contrib RDDS. BTW, why RDD has this in symbol table? Another question: many functions of some module are used from runtime loaded .hrb files. I use REQUEST to force linking this module into .exe. I current code I need to explicitly request every function to make it available in .hrb. Is where a way to include all functions of module into global symbol table? All of the functions are inside .exe anyway. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13175] trunk/harbour
Revision: 13175 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13175&view=rev Author: vszakats Date: 2009-12-09 14:45:54 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 15:41 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_regc.c * contrib/hbwin/win_prn3.c * contrib/hbwin/win_dll.c + Using new UNICODE parameter passing macros instead of HB_TCHAR*() ones. ; Please review me. The transition is not yet full, as there were some problematic cases, which I've left as is. ! Added UNICODE support for WIN_REGQUERYVALUEEX()'s string return values. * contrib/hbwin/tests/testreg.prg + Added one more test call. ! Fixed to not use legacy registry call. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/tests/testreg.prg trunk/harbour/contrib/hbwin/win_dll.c trunk/harbour/contrib/hbwin/win_prn3.c trunk/harbour/contrib/hbwin/win_regc.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:[13174] trunk/harbour
Revision: 13174
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13174&view=rev
Author: druzus
Date: 2009-12-09 14:33:48 + (Wed, 09 Dec 2009)
Log Message:
---
2009-12-09 15:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapilng.h
+ harbour/include/hbmsgreg.h
+ added common for all Harbour lang modules (msg*.c) header file
with initialization code
* harbour/src/lang/msgbe866.c
* harbour/src/lang/msgbewin.c
* harbour/src/lang/msgbg866.c
* harbour/src/lang/msgbgiso.c
* harbour/src/lang/msgbgmik.c
* harbour/src/lang/msgbgwin.c
* harbour/src/lang/msgca.c
* harbour/src/lang/msgcs852.c
* harbour/src/lang/msgcsiso.c
* harbour/src/lang/msgcskam.c
* harbour/src/lang/msgcswin.c
* harbour/src/lang/msgde.c
* harbour/src/lang/msgdewin.c
* harbour/src/lang/msgel.c
* harbour/src/lang/msgelwin.c
* harbour/src/lang/msgeo.c
* harbour/src/lang/msges.c
* harbour/src/lang/msgeswin.c
* harbour/src/lang/msgeu.c
* harbour/src/lang/msgfr.c
* harbour/src/lang/msggl.c
* harbour/src/lang/msghe862.c
* harbour/src/lang/msghewin.c
* harbour/src/lang/msghr437.c
* harbour/src/lang/msghr852.c
* harbour/src/lang/msghriso.c
* harbour/src/lang/msghrwin.c
* harbour/src/lang/msghu852.c
* harbour/src/lang/msghucwi.c
* harbour/src/lang/msghuiso.c
* harbour/src/lang/msghuwin.c
* harbour/src/lang/msgid.c
* harbour/src/lang/msgis850.c
* harbour/src/lang/msgit.c
* harbour/src/lang/msgko.c
* harbour/src/lang/msgltwin.c
* harbour/src/lang/msgnl.c
* harbour/src/lang/msgpl852.c
* harbour/src/lang/msgpliso.c
* harbour/src/lang/msgplmaz.c
* harbour/src/lang/msgplwin.c
* harbour/src/lang/msgpt.c
* harbour/src/lang/msgptiso.c
* harbour/src/lang/msgro.c
* harbour/src/lang/msgru866.c
* harbour/src/lang/msgrukoi.c
* harbour/src/lang/msgruwin.c
* harbour/src/lang/msgsk852.c
* harbour/src/lang/msgskiso.c
* harbour/src/lang/msgskkam.c
* harbour/src/lang/msgskwin.c
* harbour/src/lang/msgsl437.c
* harbour/src/lang/msgsl852.c
* harbour/src/lang/msgsliso.c
* harbour/src/lang/msgslwin.c
* harbour/src/lang/msgsr852.c
* harbour/src/lang/msgsriso.c
* harbour/src/lang/msgsrwin.c
* harbour/src/lang/msg_tpl.c
* harbour/src/lang/msgtr857.c
* harbour/src/lang/msgtrwin.c
* harbour/src/lang/msgua866.c
* harbour/src/lang/msguados.c
* harbour/src/lang/msguakoi.c
* harbour/src/lang/msguawin.c
* harbour/src/lang/msgzhb5.c
* harbour/src/lang/msgzhgb.c
* modified to use initialization code defined in common for all
lang modules header file.
* harbour/contrib/gtwvg/wvggui.c
* harbour/contrib/hbqt/qtgui/QApplication.cpp
* harbour/contrib/hbqt/qth/QApplication.qth
* use default GT startup cvode (#include "hbgtreg.h")
* harbour/include/hbinit.h
+ harbour/include/hbiniseg.h
* replaced HB_MSC_STARTUP code with more universal HB_DATASEG_STARTUP
* moved HB_DATASEG_STARTUP code to separate header file to reduce
modifications in other files when this code has to be changed or
extended
+ added support for startup code in OpenWatcom C builds. Now we can
create OpenWatcom Harbour binaries without forcing C++ mode.
I've tested Linux and Win32 builds and they works correctly.
Probably similar solution can be used also for other C compilers
which do not have native interface to define starup code.
* harbour/src/compiler/genc.c
* harbour/utils/hbmk2/hbmk2.prg
* harbour/include/hbcdpreg.h
* harbour/include/hbgtreg.h
* harbour/src/rtl/hbregex.c
* harbour/src/rdd/dbf1.c
* harbour/src/rdd/dbfcdx/dbfcdx1.c
* harbour/src/rdd/dbffpt/dbffpt1.c
* harbour/src/rdd/dbfnsx/dbfnsx1.c
* harbour/src/rdd/dbfntx/dbfntx1.c
* harbour/src/rdd/delim1.c
* harbour/src/rdd/sdf1.c
* harbour/src/pp/pplib3.c
* harbour/contrib/rddads/ads1.c
* harbour/contrib/rddads/adsx.c
* harbour/contrib/rddsql/sddfb/fbirddd.c
* harbour/contrib/rddsql/sddmy/mysqldd.c
* harbour/contrib/rddsql/sddodbc/odbcdd.c
* harbour/contrib/rddsql/sddpg/pgsqldd.c
* harbour/contrib/rddsql/sqlbase.c
* harbour/contrib/rddsql/sqlmix.c
* harbour/contrib/hbbmcdx/bmdbfcdx.c
* harbour/contrib/hbmemio/memio.c
* harbour/contrib/hbnetio/netiocli.c
* harbour/contrib/hbbtree/hb_btree.c
* harbour/contrib/hbwin/olecore.c
* harbour/contrib/hbwin/win_com.c
* modified to use HB_DATASEG_STARTUP instead of HB_MSC_STARTUP
Now HB_MSC_STARTUP is local macro used only in hbinit.h.
Please make MSVC build tests.
* harbour/contrib/hbmemio/memio.c
! declare s_fileFuncs structure as static
* removed unnecessary code to directly register HB_MEMIO symbol.
Mindaugas if you need it for some reasons then I can reactivate it
but I would like to know why it's necessary for you.
* harbour/src/vm/task.c
! added missing {}
* harbour/src/vm/fm.c
* locally disabled "unreachable code" warnings for dlmallo
[Harbour] Fileattr function
Hi all, fileattr( existing_directory ) in clipper return 16 and in harbour return 0. Tested under windows XP. Is this normal? Vitor -- ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Can we bind variables in sql?
Mindaugas, can we bind variable in selects with SQLMIX ? ... Select * ftom table where Field1 = :var1 and Fiefd2 between :var2 and :var3 ... Regards, Marek Horodyski ___ 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:[13173] trunk/harbour
Revision: 13173 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13173&view=rev Author: vszakats Date: 2009-12-09 11:51:26 + (Wed, 09 Dec 2009) Log Message: --- 2009-12-09 12:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/legacyco.c * contrib/hbwin/wapi_winuser.c ! Added missing header. * ChangeLog + Missed change added to prev entry. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/legacyco.c trunk/harbour/contrib/hbwin/wapi_winuser.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] MSVC legacyco.c problem.
Hi! * $Id: ChangeLog 13172 2009-12-09 03:09:59Z vszakats $ MSVC 2008 express. make-win with clean flag cl.exe -I. -I../../../../../include -nologo -Gs -TP -W4 -wd4127 -Ot2b1 -EHs-c- -DUNICODE -DUNICODE -Folegacyco.obj -c ../../../legacyco.c legacyco.c ../../../legacyco.c(119) : error C3861: 'HB_PARSTR': identifier not found ../../../legacyco.c(119) : error C3861: 'HB_PARSTR': identifier not found ../../../legacyco.c(120) : error C3861: 'hb_strfree': identifier not found ../../../legacyco.c(121) : error C3861: 'hb_strfree': identifier not found win-make[3]: *** [legacyco.obj] Error 2 win-make[2]: *** [descend] Error 2 win-make[1]: *** [hbwin.inst] Error 2 win-make: *** [contrib.inst] Error 2 D:\harbour\trunk\harbour> Best regards, Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13162
Przemek: >There are two types of warnings only. >I can only guess that someone left some wrong assert code in GCC >source which generates this warning when line number if 0 and it's >exploited by some type of code like inline assembler. Anyhow it's >not Harbour problem but should it be reported to GCC-OS2 port authors. >We cannot fix it. I send report to Paul Smedley, porter of os2gcc432, os2gcc433, os2gcc440, os2gcc442, ... For me problems seem related to ports after April 2009 (434,442) Thanks for your help David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Create Process API - Brief Overview Requested
>> Note: "for me". I have my own (actually quite simple) system >> which sets tool environment, so any tool which tries to >> replicate that, is just a nuisance and double effort for me, >> since I have keep my system configured, plus keep hbide >> configuration update so that it can also configure my system. >> > > Believe me, I do not want to configure anything in HBIDE. > This was the first commandant I wrote on my scratch book. > I am trying to gather all information how and what HBIDE must > supply to HBMK2 to compile projects under different compiler > settings. I know nothing about make system at all. And the answer is that you have to pass nothing more to it than it's necessary to define the project: input components and build switches. Nothing else is required. It's good if you add some means to add user-defined, extra hbmk2 invokation switches to allow to do everything with hbmk2 which can be done from regular command line. Notice that some switches can only be passed from command line directly (no .hb* file). >> Now, there is a way to avoid all above pitfalls and create hbide's >> integrated configuration system in a generic way (although even >> this has some dangers). I'll try to describe it in a few points: >> >> - Default state: No configuration is done by hbide, it uses what >> it gets from environment and let hbmk2 do it's autodetection job. >> (default/automatic/system mode) >> > > Probably this is not what HBIDE is intended for. > _no configuration on its part_ is a valid point, and I want to > stick to it, but it is not valid that it accepts what user has > set before executing it. I need a way to forward HBMK2 > _what user want to configure_ plus _what he want to build_. > This way HBIDE could be executed from any location. > >> - Support for 'compiler profile's: >> User can add, delete, edit such named profiles, each >> profile does nothing more than have a list of system commands, >> which get executed before calling hbmk2. >> > > This is exactly hbide.env is thought of, though I > am not sure, yet, what contents it will hold finally. ideally nothing by default. At least I hope. Otherwise someone will have to update it and yet it will never be correct for all users. IMO the only place where we should mention anything user specific is in INSTALL file, and even in this file it's listed as "EXAMPLE", as it's impossible to tell these things for Windows system. Plus HBIDE is meant to support Linux and OS X also, where such example don't make any sense. >> - No hard-wired 'compiler profile' in hbide .prg code. >> > > 100% correct. > > > >> - No preset 'compiler profile's in hbide SVN area (f.e. in .ini). >> > > At present also it is not, nor it will be in the future. Okay. >> This is quite flexible and makes it possible for everyone to >> customize profiles in an easy way, using existing methods or >> documentation. Here the only challenge is executing shell >> commands and then calling hbmk2. This needs to be done >> differently on different platforms. Maybe the easiest is >> to create a platform dependent .sh / .bat / .cmd file on the >> fly and call that with hb_process*() API. >> > > Agreed. > Now the point is the design time considerations. > > 1. User will write commands in a profile ( say .env ) Maybe the cleanest solution, is to have a /profiles (name tentative) dir and inside this dir, you allow to have any number of .env files. Each .env file describes a C compiler profile. I'd suggest .ini file, as .env file is not very standard. In this file all you have is _plain script lines_: --- profiles/win_bcc.ini: set PATH=C:\bcc;%PATH% --- --- profiles/osx_clang.ini: export CCPREFIX=/Developer/usr/bin --- --- profiles/myprofile.ini: export HB_COMP=msvc --- > 2. This profile is essentially a replica what he otherwise > will invoke via .bat/.sh/.cmd before executing HBMK2. Yes. > 3. HBIDE or HBMK2 ( I would like HBMK2 ) process this > profile before invoking the next step. Yes, hbide, would create a script like this, when selecting win_bcc.ini: --- _temp_.bat set PATH=C:\bcc;%PATH% hbmk2 _temp_.hbp --- > 4. HBIDE simply forwards two files 1) .env and 2) .hbp > to HBMK2. Only .hbp. .env contains shell commands. > 5. HBMK2 runs silently in the background supplying > compile/link output to HBIDE via some callback mechanism. Yes. Input from other developers would be welcome. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Watcom C and starup code
On Wed, 09 Dec 2009, Szak�ts Viktor wrote: Hi, > > Unlike #pragma startup this initialization does not use > > in #pragma directive so we can also store above definition > > in single header file hbiniseg.h and then use in other code: > > #elif defined( HB_DATASEG_STARTUP ) > > #define HB_DATASEG_BODY HB_DATASEG_FUNC( init_func ) > > #include "hbiniseg.h" > > #endif > > Such solution will resolve the problem with updating many different files > > when we want to make some modifications in data segment based startup code. > > Viktor what do you think about it? > > I'd be very good if we could move the init logic > to a .h file. And also if could avoid forced C++ for > watcom. For MSVC forced mode, it's very useful to > keep code clean from C++ warnings though. OK, I'll make this modification. > With MSVC 2008, it says this for #pragma on/off: > a.c(4) : warning C4068: unknown pragma Thank you and Alex for the tests. > I hope it's possible to work around it. Yes, it's not big problem if we move whole HB_DATASEG_STARTUP to .h file so only one file will have to be update. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Create Process API - Brief Overview Requested
>>> No need to use QProcess(), we have everything in Harbour core. >>> >>> >>> Yep, this is exactly what I want too. >> >> Anyhow you added QProcess to slots system :( >> > > Just to show the other benefits it renders. > I am simply short of process API in Harbour, > examined hbprocfn.c to go through all the details, > but I could not find how to capture process output > in buffer which process is in running state. > I can see that stdout and stderr andles but do not > know hoe effectively I can use them. > Plus hb_processRun() opens the console window > which I do not want to. > > I must be missing on this front, that's why > I had requested the api syntax. > > Qt process implementation will take only two minutes > to remove from SVN, I was just comparing the results > from both impleentations. Okay. IMO you should ask above things from Przemek to see how process API can be used for such things like catching stdout/err in real-time. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Watcom C and starup code
Przemysław Czerpak wrote:
and I need to know if MSC supports:
#pragma off (unreferenced)/* to disable unused variable warnings */
#pragma on (unreferenced) /* to enable unused variable warnings */
or at least silently ignores them.
Can someone using MS[V]C check it?
With MSVC 2008:
#include "stdafx.h"
void warn()
{
int i;
}
void badpragma()
{
#pragma off (unreferenced)
int i;
#pragma on (unreferenced)
}
int main(int argc, char * argv[])
#pragma warning( push )
#pragma warning( disable : 4101 )
{
int i;
printf("Hello, pragma test");
return 0;
}
#pragma warning( pop )
results in:
c:\users\alex\documents\visual studio
2008\projects\pragmatest\pragmatest\pragmatest.cpp(5) : warning C4101: 'i' :
unreferenced local variable
c:\users\alex\documents\visual studio
2008\projects\pragmatest\pragmatest\pragmatest.cpp(10) : warning C4068: unknown
pragma
c:\users\alex\documents\visual studio
2008\projects\pragmatest\pragmatest\pragmatest.cpp(12) : warning C4068: unknown
pragma
c:\users\alex\documents\visual studio
2008\projects\pragmatest\pragmatest\pragmatest.cpp(11) : warning C4101: 'i' :
unreferenced local variable
Regards
Alex
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Watcom C and starup code
Hi Przemek, > Unlike #pragma startup this initialization does not use > in #pragma directive so we can also store above definition > in single header file hbiniseg.h and then use in other code: > > #elif defined( HB_DATASEG_STARTUP ) > #define HB_DATASEG_BODY HB_DATASEG_FUNC( init_func ) > #include "hbiniseg.h" > #endif > > Such solution will resolve the problem with updating many different files > when we want to make some modifications in data segment based startup code. > Viktor what do you think about it? I'd be very good if we could move the init logic to a .h file. And also if could avoid forced C++ for watcom. For MSVC forced mode, it's very useful to keep code clean from C++ warnings though. With MSVC 2008, it says this for #pragma on/off: a.c(4) : warning C4068: unknown pragma I hope it's possible to work around it. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: Harbour 13162
On Wed, 09 Dec 2009, David Arturo Macias Corona wrote: Hi, > I made tests with > * $Id: ChangeLog 13162 2009-12-08 03:08:08Z druzus $ > 2009-12-08 04:07 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > and new os2gcc434, os2gcc442 > Both gave 0 errors and lot of warnings which does not happen in os2gcc433 > Warnings are below, so you can confirm if they must be cleared or not There are two types of warnings only. > gcc -I. -I../../../../../include -Zomf -Wall -W -O3 -DHB_HAS_PCRE > -IE:/harbour912/harbour/external/pcre -DPCRE_STATIC -DHB_HAS_ZLIB > -IE:/harbour912/harbour/external/zlib -DTCPV40HDRS > -DHB_FM_STATISTICS_OFF -ohbsocket.o -c ../../../hbsocket.c > E:/usr/include/386/endian.h: Assembler messages: > E:/usr/include/386/endian.h:118: Warning: line numbers must be positive; > line number 0 rejected > E:/usr/include/386/endian.h:118: Warning: line numbers must be positive; > line number 0 rejected I can only guess that someone left some wrong assert code in GCC source which generates this warning when line number if 0 and it's exploited by some type of code like inline assembler. Anyhow it's not Harbour problem but should it be reported to GCC-OS2 port authors. We cannot fix it. > gcc -I. -I../../../../../include -Zomf -Wall -W -O3 -DHB_HAS_PCRE > -IE:/harbour912/harbour/external/pcre -DPCRE_STATIC -DHB_HAS_ZLIB > -IE:/harbour912/harbour/external/zlib -DTCPV40HDRS > -DHB_FM_STATISTICS_OFF -ofilesys.o -c ../../../filesys.c > ../../../filesys.c: In function 'hb_fsSetFileTime': > ../../../filesys.c:1161: warning: 'ftime.twosecs' may be used > uninitialized in this function > ../../../filesys.c:1161: warning: 'ftime.minutes' may be used > uninitialized in this function > ../../../filesys.c:1161: warning: 'ftime.hours' may be used > uninitialized in this function This is false alarm but I'll change the code to pacify these warnings. Thank you for information. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
