* contrib/gtqtc/gtqtc.hbp
* contrib/hbssl/ssl_hbcon.prg
* contrib/gtqtc/hbmk2_qtmoc.hb -> contrib/gtqtc/hbmk2_qtgt.hb
* more syncs with 3.4 fork. One rename, some content syncs
after renames.
+ src/rdd/usrrdd/rdds/arrayrdd.prg -> contrib/rddmisc/arrayrdd.prg
+ src/rdd/usrrdd/rdds/dbtcdx.prg -> contrib/rddmisc/dbtcdx.prg
+ src/rdd/usrrdd/rdds/fptcdx.prg -> contrib/rddmisc/fptcdx.prg
+ src/rdd/usrrdd/rdds/hscdx.prg -> contrib/rddmisc/hscdx.prg
+ src/rdd/usrrdd/rdds/logrdd.prg -> contrib/rddmisc/logrdd.prg
+ src/rdd/usrrdd/rdds/rlcdx.prg -> contrib/rddmisc/rlcdx.prg
+ src/rdd/usrrdd/rdds/smtcdx.prg -> contrib/rddmisc/smtcdx.prg
+ src/rdd/usrrdd/rdds/vfpcdx.prg -> contrib/rddmisc/vfpcdx.prg
* src/rdd/usrrdd/rdds/arrayrdd.prg
* src/rdd/usrrdd/rdds/dbtcdx.prg
* src/rdd/usrrdd/rdds/fptcdx.prg
* src/rdd/usrrdd/rdds/hscdx.prg
* src/rdd/usrrdd/rdds/logrdd.prg
* src/rdd/usrrdd/rdds/rlcdx.prg
* src/rdd/usrrdd/rdds/smtcdx.prg
* src/rdd/usrrdd/rdds/vfpcdx.prg
* move usrrdd sources to contrib/rddmisc to have the source tree
in sync with 3.4 fork, where these were converted to a contrib.
In 3.2 they will still be compiled into core with an #include
trick.
* contrib/gtwvg/*.prg
* contrib/gtwvg/gtwgud.c
* contrib/gtwvg/gtwvg.hbx
* contrib/gtwvg/gtwvgd.c
* contrib/gtwvg/wvgcore.c
* contrib/gtwvg/wvgcuig.c
* more sync with 3.4 fork, mostly code-style/whitespace with
some minor optimizations
* *
* partial sync with the 3.4 fork codebase. These are the things
synces for the most part:
- copyright headers
- grammar/typos in comments and some readmes
- comment/whitespace/decorations
- variable scoping in C files
- DO CASE/SWITCH and some other alternate syntax usage
- minimal amount of human readable text in strings
- minor code updates
- HB_TRACE() void * casts for pointers and few other changes to
avoid C compiler warnings
- various other, minor code cleanups
- only Harbour/C code/headers were touched in src, utils, contrib,
include. No 3rd party code, no make files, and with just a few
exceptions, no 'tests' code was touched.
- certain components were not touched were 3.4 diverged too much
already, like f.e. hbmk2, hbssl, hbcurl, hbexpat
- the goal was that no actual program logic should be altered by
these changes. Except some possible minor exceptions, any such
change is probably a bug in this patch.
It's a massive patch, if you find anything broken after it, please
open an Issue with the details. Build test was done on macOS.
The goal is make it easier to see what actual code/logic was changed
in 3.4 compared to 3.2 and to make patches easier to apply in both
ways.
* contrib/gtwvg/gtwgud.c
* contrib/gtwvg/gtwvgd.c
+ Added : hb_gtinfo( HB_GTI_WINTITLE ) now returns Windows handle.
Was a missing implementation since long.
* src/rtl/dirscan.prg
! fixed type in hb_DirRemoveAll() result - it always returned .F.
* src/rtl/itemseri.c
! fixed internal error when HB_SERIALIZE_COMPRESS is passed to
hb_Serialize() and ZLIB was not linked with application
* src/rtl/tpersist.prg
! fixed deserialization of multidimensional arrays - thanks to Peter
* contrib/rddads/ads1.c
* pacified 'fall through' warnings
* contrib/hbexpat/3rd/expat/_hbconf.h
* contrib/hbexpat/3rd/expat/xmlparse.c
! fixed WINCE builds
! fixed OpenWatcom DOS builds
! fixed OpenWatcom OS2 builds
* contrib/hbexpat/3rd/expat/expat.dif
* rediffed
* include/harbour.hbx
* include/hbvm.h
* src/harbour.def
* src/vm/hvm.c
* src/vm/thread.c
+ added new C function
HB_BOOL hb_vmThreadIsMain( void * );
it checks if given or current thread is main HVM thread
+ added new PRG function
hb_threadIsMain( [ <pThID> ] ) -> <lMainHvmThread>
it returns true if given or current thread is main HVM thread
+ added new PRG function
hb_mutexExists( <pMtx> ) -> <lExists>
it returns true if passed <pMtx> parameter is pointer item to
fully functional mutex
* src/rtl/tpersist.prg
! fixed problem with array item deserialization - many thanks
to Peter Rees for exact information about the problem.
* src/rtl/val.c
* minor simplification
* contrib/hbwin/olecore.c
! reverted order of indexes and dimensions in conversions of
multidimensional arrays.
This modification affects both conversions (1) from Harbour array
to OLE variant SafeArray and (2) from OLE variant SafeArray to Harbour
array. The first one is new Harbour extension of __oleVariantNew() so
here above modification should not create any backward compatibility
problems but the second interacts with code which existed in Harbour
from early OLE implementation so if someone already encoded hacks
to revert array indexes and dimensions at .prg level then now he has
to remove it.
Please not that above modification affects only for multidimensional
OLE typed arrays. It does not change anything for single dimension
arrays or single dimension arrays of variants which contains other
similar arrays in their items.
* contrib/hbwin/olecore.c
+ added support for multidimensional typed OLE arrays, now
__oleVariantNew() accepts the following parameters:
__oleVariantNew( <nVariantType>, [<xInitValue>], [<nDims,...>] )
-> <pVariant>
i.e.:
pOleArray := __oleVariantNew( WIN_VT_VARIANT, aVal, ;
len( aVal ), len( aVal[ 1 ] ) )
pOleArray2 := __oleVariantNew( WIN_VT_I4, ;
{ { 1, 2, 3 }, { 4, 5, 6 } }, 2, 3 )
If initialization array is smaller the declared size then in OLE array
uninitialized items have default value for given type. NIL array items
are ignored other non array values in nodes generate errors. Strings
can be used on last level to initialize OLE arrays with ASCII values of
their characters.
Please test it in real MS-Window environment.
* contrib/hbexpat/3rd/expat/_hbconf.h
! fixed MS-Windows builds
* contrib/hbexpat/3rd/expat/*
! updated to 2.2.1 (from 2.1.0) using 3rdpatch.hb, expat.dif(f) from
Viktor's 3.4 fork was used - but adapted for DOS 8.3 naming
scheme. According to issue #157, previous revisions of expat have
security vulnerabilities, for more information refer to:
https://github.com/libexpat/libexpat/blob/master/expat/Changes
Many thanks to Sebastian Pipping for the information.
* contrib/hbexpat/hbexpat.ch
+ new constant HB_XML_ERROR_INVALID_ARGUMENT added
* utils/hbmk2/hbmk2.prg
* remove `_HBSHELL_EXEC_PRE` macro
+ add `_HBSHELL_EXTRA_HEADER` macro that can be defined to a header
(.ch) filename which will be included in all dot prompt and script
execution sessions. The header will also be embedded in
hbmk2/hbrun at build-time, so it's not necessary to be present at
runtime. The macro may also be defined in the `hbmk2_extra.prg`
source.
* utils/hbmk2/hbmk2.prg
+ add ability to inject extra code/directives to the hbmk2/hbrun source
code at build time. It can be enabled by defining
`_HBMK2_EXTRA_CODE`, when a source file named `hbmk2_extra.prg` will
be included between the header and code section of hbmk2.prg.
+ display note when above option is enabled
+ add ability to prepend extra code before the shell execution stub via
the `_HBSHELL_EXEC_PRE` macro. It's initialized by an empty string in
a default build. This macro can be redefined at will by
`hbmk2_extra.prg`.
; commit backported to 3.2 from the 3.4 fork:
2017-05-14 19:35 UTC Viktor Szakats (vszakats users.noreply.github.com)
1ee9a9c6dc
* config/android/gcc.mk
* config/global.mk
* config/linux/gcc.mk
* config/postinst.hb
* contrib/hbpost.hbm
! removed version number from dynamic libraries for Android.
Pure Linux style dynamic library numbers in Android systems can be used
only with system libraries but it's not supported inside .apk packages
so our dynamic libraries were unusable for Android programmers unless
someone plans to install more then one version of Harbour dynamic
libraries as Android system libraries. It's rather unusual situation
and I believe that in such case he can easy create such libraries
building Harbour for Linux with NDK.
* enabled by default building contrib dynamic libraries in Harbour
Android build.
+ added -Wl,--no-undefined to linker parameters when dynamic libraries
are created to verify if dynamic libraries can be used in Android .apk
packages during Harbour build process.
; After above modification dynamic (*.so) libraries created in Harbour
build process can be used in .apk packages. It means that projects
like HDroidGUI do not longer need their own custom versions of
libharbour.so but can use the one from standard Harbour Android build.
They can also use Harbour contrib dynamic libraries.
; TODO: add support for automatic NDK detection in Harbour build process
; TODO: add to HBMK2 basic support for generating .apk packages
* contrib/gtqtc/gtqtc.hbp
* disabled dynamic GTQTC library in Android builds until we set explicit
bindings with QT/C++ dynamic libs
* contrib/rddads/ads1.c
+ added support for "VarCharFox" and "VarBinaryFox" field types.
! fixed accessing "VarChar" fields longer then their size defined in
table header (rest of longer fields is stored in memo file)
! do not reduce size of data stored in "VarChar" fields to the size
of region allocated for them in table record. Such fields allows
to store up to 64000 bytes and rest is saved in memo file.
! fixed RTE when strings longer then 64000 bytes are assigned to
"VarChar" fields.
! fixed RTE when strings longer then declared field size are assigned
to Unicode character fields (i.e. "nChar" or "C:U")
! fixed possible use of memcpy() with the same source and destination
addresses
* contrib/hbgs/hbgs.hbp
! respect HB_BUILD_3RDEXT=no
* contrib/hbwin/olecore.c
! fixed updating unnamed parameters passed by reference together
with named parameters
* contrib/hbwin/olecore.c
* changed tagVARIANT member used in hack extracting variant value
address from ullVal to bVal to avoid problems with some old header
files which do not support LONGLONG values
* contrib/hbwin/olecore.c
+ added functions which changes default method of NIL conversion to
OLE variant:
__oleVariantNil2Null( [<lNewNil2NullFlag>] ) -> <lPrevNil2NullFlag>
By default NIL values passed to foreign OLE code are converted to
VT_EMPTY variants. __oleVariantNil2Null( .t. ) changes this behavior
so NIL values are converted to VT_NULL variants.
; Warning: This function was added for tests. Looks that it's expected
behavior for communication with MS-Excel and allows to use
NIL as default parameter value but potentially it may create
problems with some custom OLE interfaces so this modification
should be widely tested in real life before we change the
default behavior.
* contrib/hbwin/olecore.c
- removed support for VT_DECIMAL and VT_PTR arrays from
__oleVariantNew() - I found in MSDN that such types are
unsupported in SAFEARRAYs
! fixed indexes in array conversion in __oleVariantNew()
! fixed conversion to VT_BSTR arrays in __oleVariantNew()
* contrib/hbwin/olecore.c
+ automatically add WIN_VT_ARRAY bit in 1-st parameter of
__oleVariantNew() when 2-nd parameter is an array
+ added support for typed variant arrays to __oleVariantNew()
Now it's possible to create strong typed one dimensional arrays and
pass them as parameters to foreign OLE code, i.e.
oOle:setArrayOfStrings( ;
__oleVariantNew( WIN_VT_BSTR, { "1-st", "2-nd", "3-rd" } ) )
oOle:setArrayOfIntegers( ;
__oleVariantNew( WIN_VT_INT, { 1, 2, 3, 4 } )
+ added support for array of integers initialization from strings
passed to __oleVariantNew() in 2-nd parameter.
Now it's possible to create strong typed one dimensional OLE array
initialized with string bytes ASCII values, i.e.
oOle:setUcharStr( ;
__oleVariantNew( hb_bitOr( WIN_VT_ARRAY, WIN_VT_UI8 ), ;
"ABCDEF" ) )
oOle:setArrayOfIntegers( ;
__oleVariantNew( hb_bitOr( WIN_VT_ARRAY, WIN_VT_INT ), ;
"ABCDEF" ) )
; warning: code not tested at all, written in my Linux box,
please make real life tests in MS-Windows
* contrib/hbwin/olecore.c
* added additional protection to reduce hb_oleSafeArrayToString()
functionality to arrays of VT_I1 and VT_UI1 items so other types
which may also allocate 1 byte for each item are not converted.
* contrib/rddads/ads1.c
* src/rdd/workarea.c
* simplified the code and eliminated wrong /* fallthrough */ comments
inside case block reported by Viktor
* contrib/hbwin/olecore.c
+ added support for named parameters in OLE method calls,
named parameters should be passed inside hash array in
first parameter, i.e.:
oWorksheets:add( { "Before" => oWS, "Count" => 3 } )
next parameters if exist are passed as unnamed ones, i.e.
oOle:add( { "name" => "test", "value" => 12345 }, 1, 2, 3 )
; warning: code not tested at all, written in my Linux box,
please make real life tests in MS-Windows
! fixed __oleGetNameId()
