* harbour/contrib/hbxbp/Makefile
* harbour/contrib/hbxbp/xbp.ch
* harbour/contrib/hbxbp/xbpfiledialog.prg
* harbour/contrib/hbxbp/xbpfontdialog.prg
+ harbour/contrib/hbxbp/xbphtmlviewer.prg
+ Implemented XbpFileDialog() class - almost Xbase++ compatible.
+ Implemented XbpHTMLViewer() class with all its features.
* harbour/contrib/hbxbp/tests/demoxbp.prg
+ Demonstrated XbpFileDialog() usage - click on toolbar buttons.
+ Demonstrated XbpHTMLViewer() class.
Hi, can someone play with all callbacks of XbpHTMLViewer() and
can look into details of XbpFileDialog()?
* INSTALL
- Deleted QT version number from example settings to
ease on maintenance without making the doc look outdated.
* source/rtl/hbmd5.c
! Minor typo in comment.
* config/win/global.cf
* config/wce/global.cf
% Removed unnecessary @ chars.
* contrib/hbmisc/Makefile
+ contrib/hbmisc/fcomma.prg
- source/rdd/usrrdd/rdds/fcomma.prg
* source/rdd/usrrdd/rdds/Makefile
* fcomma.prg moved to hbmisc, since it depends on
hbmisc features.
* examples/hbextern/hbextern.prg
- Removed special treatment of fcomma.prg.
+ harbour/include/hbtask.h
+ harbour/source/vm/task.c
* harbour/include/hbthread.h
* harbour/include/hbatomic.h
* harbour/source/vm/thread.c
* harbour/source/vm/hvm.c
* harbour/source/vm/fm.c
* harbour/source/rtl/idle.c
* harbour/source/rtl/filesys.c
+ implemented OS independent task switching system - it gives PTHREAD
compatible basic API so it can be used in HVM as alternative MT support
which does not use any OS threads. As long as Harbour does not call
any blocking OS function then it's possible to create and execute
simultaneously many threads though only one CPU is used and switched
between HVM threads. It gives similar scalability to xbase++ threads
and also similar behavior in item protection at .prg level.
Now it's possible to use HVM threads in any OS.
Of course it does not mean that Harbour adds in some magic way
thread support to OS-es which does not support threads like DOS.
It only means that HVM supports threads for .prg code just like
in native MT environment as long as some C code does not block
task switching or process execution will not be frozen by sth, i.e.
executing other process (__run()) in single process OS like DOS.
In some cases it can be interesting alternative even in OS which
have native thread support.
All tests/mttest*.prg programs and speedtst --thread=<n> --scale
are executed correctly with new task switching just like with
OS native MT support.
Compilation with task switching in hbvmmt library can be forced
by HB_TASK_THREAD macro which also disable native OS threads
support.
For task context switching two alternative methods are used:
1) getcontext()/makecontext()/swapcontext() (SUSv2, POSIX.1-2001)
which is preferable because does not need any additional
hacks but not all OS-es supports these functions.
It's enabled by default in Linux builds.
2) setjmp()/longjmp() (POSIX, ISO 9899 (C99)) otherwise.
These functions are supported by most of C compilers
but there is no function to set new stack in saved context
so it's necessary to introduce for each architecure/C compiler
peace of code which makes it. Macro HB_TASK_STACK_INIT() in
task.c makes it. I defined this macro for x86@32 in DJGPP
Linux GCC and OpenWatcom builds. I tested OpenWatcom builds only
in DOS and Linux but probably it works in all x86@32 builds.
If someone is interesting in adding support for some other
platforms which does not support ucontext.h and 1-st methods
then please define above macro for them.
Have a fun with new toy ;-)
* harbour/source/vm/Makefile
* enabled hbvmmt in DJGPP and OpenWatcom DOS builds. It works well.
Viktor if possible please add support for -mt switch in hbmk2
in all builds even if we do not compile hbvmmt by default so
it can be used with DJGPP and OW and any other builds for which
someone enable hbtask.c though OS does not support threads.
* harbour/contrib/hbmzip/hbmzip.c
! fixed '[const] char|BYTE *' casting in DOS and OS2 builds
* harbour/source/macro/macro.y
* harbour/source/macro/macro.yyc
* harbour/source/compiler/harbour.y
* harbour/source/compiler/harbour.yyc
% reduced INASSING definition - thanks to Xavi for information
* harbour/source/compiler/hbopt.c
! fixed stupid bug in logical expression optimization - thanks to Randy
for self contain example
* harbour/include/hbapi.h
* harbour/include/hbmacro.h
* harbour/include/hbexprb.c
* harbour/source/vm/macro.c
* harbour/source/vm/hvm.c
* harbour/source/macro/macro.y
* harbour/source/macro/macro.yyc
+ added direct support for pushing references to macro expressions.
It resolves the problem with Clipper compatibility (thanks to Alex
for information and example) in code like:
m->var := {0}
&("var[1]") += 10
and also many other things, f.e. now Harbour can cleanly compile
and execute this code:
proc main
local s
m->o := errorNew()
s:="o:tries"
? m->o:tries
? &s
? &(s+"+=2")
? m->o:tries
? &(s+":=3")
? m->o:tries
?
&s := 4
? m->o:tries
&s -= 2
? m->o:tries
&s++
? m->o:tries
?
s := "o"
m->o := 1
? &s
&s := &s + 4
? &s
? &s += 5
? --&s
?
s := "o[2]"
m->o := { 1, 2 }
? &s
&s := &s + 4
? &s
? &s += 5
? --&s
return
* harbour/utils/hbtest/Makefile
* force hbtest compilation with line numbers - information about line
numbers is important part of this test.
* contrib/hbxbp/tests/demoxbp.prg
* contrib/hbxbp/xbpstatic.prg
+ Implemented XBPSTATIC_TYPE_BITMAP. It is not Xbase++ compatible
in the sense it is pulled from a disk file. But by attributes wise
it is exactly like Xbase++.
SUGGESSIONS: Should I implement Harbour extensions to the Xbp* classes?
I find a wide scope to add few more instance variables to the
class.
* include/hbcomp.h
* include/hbcompdf.h
* include/hbapifs.h
* include/hbexprop.h
* include/hbmacro.h
* include/hbapi.h
* include/hbapiitm.h
* include/hbdate.h
* source/pp/ppcore.c
* source/vm/itemapi.c
* source/vm/arrays.c
* source/vm/extend.c
* source/common/expropt1.c
* source/rtl/philes.c
* source/rtl/empty.c
* source/rtl/minmax.c
* source/rtl/dates.c
* source/rtl/filesys.c
* source/rdd/dbfnsx/dbfnsx1.c
* source/rdd/dbfcdx/dbfcdx1.c
* source/rdd/dbf1.c
* source/rdd/dbffpt/dbffpt1.c
* source/rdd/hbsix/sxdate.c
* source/compiler/hbmain.c
* source/compiler/complex.c
* source/compiler/harbour.yyc
* source/compiler/harbour.y
* contrib/hbct/files.c
* contrib/hbct/dattime2.c
* contrib/hbct/datetime.c
* contrib/xhb/filestat.c
* contrib/hbtip/utils.c
* examples/hboleold/win_ole.c
* LONG -> long for date/time related values
(julian, date, type, millisec)
; This is an effort to clean Harbour sources from
Windows/legacy-Clipper basic types and replace
them with own or ANSI C ones.
In the above case, usage wasn't consistent,
LONG and long were mixed.
* source/main/harbour.c
* source/vm/fm.c
* LONG -> long for some stat counters.
* contrib/gtqtc/gtqtc.cpp
- Deleted commented Windows specific parts.
* contrib/hbtip/utils.c
* UINT -> unsigned int
* examples/hbmsql/msql.ch
* Minor in comment.
* utils/hbmk2/hbmk2.prg
! Fixed regression (when implementing filename escaping)
with forming libnames specified with an absolute path on
gcc-family compilers. This broke building qt apps on darwin,
and -shared support on *nix.
* examples/hbextern/hbextern.prg
* Excluding all HB_ARCHITECTURE dirs explicitly.
(this resolves the recursion problem)
* Excluding fcomma.prg explicitly.
- Deleted 'example' from exclusion list.
- source/rdd/usrrdd/example
+ tests/usrrdd
* Moved examples under test dir.
* source/rdd/usrrdd/rdds/Makefile
- Removed fcomma.prg from builds since it depends on
hbmisc contrib libs, on functions which aren't MT
compatible and have other problems too.
* config/none.cf
* config/win/global.cf
* config/wce/global.cf
! Attempt to fix problem where 'COMSPEC' envvar wasn't picked
by GNU Make on default XP installation, where this envvar
is defined as 'ComSpec', and mingw GNU Make is case-sensitive
for envvar names. This patch is needed to make Harbour build
with clean PATH (without OS).
Thanks to April White for discovering this.
* harbour/contrib/hbxbp/xbpstatic.prg
+ Implemented more static styles.
* harbour/contrib/hbxbp/tests/demoxbp.prg
! Demonstrated newly implemented static styles.
NOTE: Remaining styles are :
XBPSTATIC_TYPE_ICON
XBPSTATIC_TYPE_SYSICON
XBPSTATIC_TYPE_BITMAP
As these styles are mainly resource based, we need to
think of a system where existing applns could use its
resource files.
If anyone has any clue about how system defined icons
can be manipulated in QT please speak out. A quick search
has not led me to any significant clue.
* contrib/Makefile
* Moved hbxbp to the end of list as a workaround for potentially
outdated hbqt.ch reference, if it's before hbqt build.
Still not prefect though. We should probably fix the ordering
of -I option in build process, but it doesn't seem trivial.
Or avoid installing headers into central include dir, but that
also leads far.
* utils/hbmk2/hbmk2.prg
* Minor step to fix a recent regression.
* source/rtl/hbzlibgz.c
* HB_GZDIRECT() is now always defined in core, if it's built against
older zlib version, it will simply do nothing.
We can discuss how to handle this situation, all have pros and cons:
1) Always define: Throw RTE at runtime.
2) Always define: Return error at runtime.
3) Don't define if low-level wrapper isn't present. Makes it
easy to catch missing dependencies on .prg level, but it
break Harbour to provide a consistent higher level API.
* examples/hbextern/hbextern.prg
! Minor fix in generated comment.
* examples/hbextern/hbextern.hbp
+ -w2 -> -w3
* ChangeLog
! Wrong header in previous entry.
* contrib/hbqt/hbqt_qimage.cpp
* contrib/hbqt/hbqt_qtextdocument.cpp
* contrib/hbqt/hbqt_qapplication.cpp
* contrib/hbqt/hbqt_qtextcursor.cpp
* contrib/hbqt/hbqt_qclipboard.cpp
* contrib/hbqt/hbqt_qurl.cpp
* contrib/hbqt/hbqt_qwebhistoryitem.cpp
* contrib/hbqt/hbqt_qvariant.cpp
* contrib/hbqt/hbqt_qfont.cpp
* contrib/hbqt/hbqt_qimagereader.cpp
* contrib/hbqt/hbqt_qcursor.cpp
* contrib/hbqt/hbqt_qfontdatabase.cpp
* contrib/hbqt/hbqt_qcoreapplication.cpp
* contrib/hbqt/hbqt_qobject.cpp
* contrib/hbqt/hbqt_qtextframe.cpp
* contrib/hbqt/hbqt_qabstractitemmodel.cpp
* Minor EOF change after regerenating them with hbqtgen.
(probably it would be better to generate only one EOLs at
EOF by hbqtgen)
* contrib/hbqt/hbqt.h
* contrib/hbqt/hbqt_qabstractitemmodel.cpp
* contrib/hbqt/hbqt_qapplication.cpp
* contrib/hbqt/hbqt_qclipboard.cpp
* contrib/hbqt/hbqt_qcoreapplication.cpp
* contrib/hbqt/hbqt_qcursor.cpp
* contrib/hbqt/hbqt_qfont.cpp
* contrib/hbqt/hbqt_qfontdatabase.cpp
* contrib/hbqt/hbqt_qimage.cpp
* contrib/hbqt/hbqt_qimagereader.cpp
* contrib/hbqt/hbqt_qobject.cpp
* contrib/hbqt/hbqt_qurl.cpp
* contrib/hbqt/hbqt_qvariant.cpp
* contrib/hbqt/qth/QAbstractItemModel.qth
* contrib/hbqt/qth/QApplication.qth
* contrib/hbqt/qth/QClipboard.qth
* contrib/hbqt/qth/QCoreApplication.qth
* contrib/hbqt/qth/QCursor.qth
* contrib/hbqt/qth/QFont.qth
* contrib/hbqt/qth/QFontDatabase.qth
* contrib/hbqt/qth/QImage.qth
* contrib/hbqt/qth/QImageReader.qth
* contrib/hbqt/qth/QObject.qth
* contrib/hbqt/qth/QUrl.qth
* contrib/hbqt/qth/QVariant.qth
% Optimized header usage. Now QWidget isn't included in all
files, just two where it's needed, the rest uses only those
granular headers which they really require.
Compilation may be a little bit faster now.
; TODO: We'd still need to try precomiled headers here to
further speed up build.
* examples/hbextern/hbextern.hbp
* build flags
* examples/hbextern/hbextern.prg
* significant updates
; default params works mostly like original version
; TOFIX: produces this 'bad' code (harbour reports "hbextern.ch_(1019) Error E0025 Error in #if expression"
#if ZLIB_VERNUM >= 0x1230
EXTERNAL HB_GZDIRECT
#endif /* #if ZLIB_VERNUM >= 0x1230 */
% Question: do I upload a new hbextern.ch or can/should a user with more experience with it do so?
* source/rtl/gtwvt/gtwvt.c
! Fixed maximize button state when HB_GTI_RESIZABLE is set to .T.
before the window is drawn.
Please test.
% Cleaned windows style definitions in source.
* include/hbstack.h
* include/hbapi.h
* Formatting in comment.
