* include/hbapi.h
! Added HB_EXPORT to hb_memvarGet() and hb_memvarSetValue()
used by new OLE server code in hbwin when created -shared
OLE server .dlls.
+ contrib/hbwin/hbolesrv.hbc
+ Added .hbc file to help creating OLE servers.
* contrib/hbwin/tests/olesrv1.hbp
* contrib/hbwin/tests/olesrv2.hbp
* contrib/hbwin/tests/olesrv3.hbp
% Changed to use hbolesrv.hbc.
- Deleted '-static' option to also allow to build -shared
OLE servers. (I tested them OK)
* contrib/hbwin/tests/olesrv2.prg
+ Tweak to allow case-insensitive access of OLE functions.
* utils/hbmk2/hbmk2.prg
+ Added support for .def files in source= .hbc line.
* contrib/hbwin/tests/oletst1.hbp
* contrib/hbwin/tests/olesrv1.hbp
* contrib/hbwin/tests/oletst2.hbp
* contrib/hbwin/tests/olesrv2.hbp
* contrib/hbwin/tests/oletst3.hbp
* contrib/hbwin/tests/olesrv3.hbp
* Changed to reference .hbp files instead of libs.
% Deleted redundant settings already supplied
by .hbm files. (if the goal is to make them
current dir independent, we can add a simple
@hbmk.hbm reference to them)
* contrib/hbwin/hbolesrv-mgw.def
* contrib/hbwin/hbolesrv.def
* contrib/hbwin/hbolesrv-ow.def
+ Added SVN ID as comments.
(I hope watcom supports it, if not pls tell)
; TODO: We should somehow merge these into one .def,
even if it requires some extra hbmk2 "magic".
* contrib/hbwin/tests/oletst1.hbp
* contrib/hbwin/tests/olesrv1.hbp
* contrib/hbwin/tests/oletst2.hbp
* contrib/hbwin/tests/olesrv2.hbp
* contrib/hbwin/tests/oletst3.hbp
* contrib/hbwin/tests/olesrv3.hbp
* contrib/hbwin/hbolesrv-mgw.def
* contrib/hbwin/hbolesrv.def
* contrib/hbwin/hbolesrv-ow.def
+ Added SVN props.
* harbour/contrib/hbwin/Makefile
+ harbour/contrib/hbwin/hbolesrv.c
+ added inproc OLE server implementation. It allows to create OLE/ACTIVEX
COM server in Harbour. Such OLE server allows can be used by programs
written in any languages supporting OLE automation (also in other
Harbour applications)
User ole server code should be linked as DLL which later can be
register in MS-Windows by regsvr32.exe program, i.e.:
regsvr32 myolesrv.dll
The OLE server code should contain DLLMAIN() PRG function which
is executed just after loading OLE inproc DLL server as server from
other application and also by regsrv32.exe during registration and
unregistration procedure. It has to initialize at least OLE server
ID and name usinf WIN_OleServerInit().
+ added new PRG function which intitialize OLE server:
WIN_OleServerInit( <cClassID>, <cServerName>, ;
[ <hAction> | <oAction> | <bAction> | <sAction> ], ;
[ <lHashClone> | <lAcceptAll> ] ) -> <lServerActive>
<cClassID> is registered OLE server class GUID
<cServerName> is OLE server class name
<hAction> is optional parameter with hash array containing messages
and instance variables used by OLE server. The keys in hash array
are strings with message names and values are actions. Codeblock
and symbol items means that given message is a method call and
any other value means that it's variable.
By default the same hash array is shared between all objects
created by registered server. It's important when hash array
contains values which are neither codeblock nor symbol items
so they are not used as method but rather as instance variables
because such instance variables are shared between OLE objects.
Setting 4-th parameter <lHashClone> to .T. causes that each
objects receives it's own copy of <hAction> item so instance
variables inside hash array are also local to OLE object.
Alternatively programmer can use <bAction> or <sAction> to create
seprate copy of hash array for each object, i.e.:
bAction := {|| hb_hClone( hValue ) }
When hash array contains symbol item (@funcName()) then when it's
executed by OLE object message it's possible to access the hash
array bound with given OLE object using QSelf() function. It maybe
useful if hash array contains instance variables and programmer
wants to access them.
Please remember that using hash array which was initialized to keep
original assign order by HB_HKEEPORDER( <hAction>, .T. ) before
adding its items you can define strict message numbers (DISPIDs), i.e.:
hAction := {=>}
HB_HKEEPORDER( hAction, .T. )
hAction[ "OPEN" ] := @myole_open() // DISPID=1
hAction[ "CLOSE" ] := @myole_close() // DISPID=2
hAction[ "SAVE" ] := @myole_save() // DISPID=3
hAction[ "LOAD" ] := @myole_load() // DISPID=4
hAction[ "PRINT" ] := @myole_print() // DISPID=5
(see example in olesrv2.prg)
<oAction> is optional parameter with Harbour object which is used
as base for all newly created OLE objects. All messages (method and
instance variables) supported explicitly by <oAction> object (except
ONERROR message redirecting) are inherited by OLE objects. Each
newly created OLE object uses the same <oAction> object so its
instance variables are shared between all of them. If programmer
wants to create separate Harbour object for each OLE object then
he should use <bAction> or <sAction>, i.e.:
bAction := {|| myClass():new() }
<bAction> is optional parameter with codeblock executed when new
OLE object is created. It should return hash array or Harbour object
which will be used as base for newly created OLE object.
<sAction> is optional parameter with function symbol. This function
is executed when new OLE object is created and should return hash
array or Harbour object which is used as base for newly created
OLE object.
If the 3-rd parameter is <oAction>, <bAction> or <sAction> then
it's possible to also set 4-th parameter <lAcceptAll> to .T. and
in such case <xAction> parameter is used in different way. Newly
created OLE object accepts any massage names invoking for each
of them EVAL() message which is sent to <xAction> with OLE message
name inserted as the 1-st item to OLE object parameters.
It allows to create OLE server which will accept unknown messages
redirecting them to some other code, i.e.:
if netio_connect( cServer,,, cPasswd )
WIN_OleServerInit( cClassID, cServerName, @netio_funcExec(), .T. )
endif
initialize OLE server which redirects all messages to default netio
connection establish by netio_connect().
If 3-rd parameter is not given then all HVM functions becomes
OLE methods and HVM memvars (public and private variables) are
OLE object instance variables so they are shared with all OLE
objects created by this interface. It works just like xHarbour.com
OLE server described at
http://xharbour.com/index.asp?page=add_on_oleserver&show_sub=7&show_i=1
; TODO: add support for MT RPC servers. Current implementation cannot
be safely used in MT programs creating OLE objects and executing
their methods simultaneously in different threads without
additional user code which will serialize these operations.
; TODO: replace message handler API in WIN_AxGetControl()/
__AxRegisterHandler() which uses only fixed method IDs
and do not support method names with above one so user
can easy create activex controls which support message
names. This modificaiton will force updating user and 3-rd
party code but IMO should be done. Current interface is
simply too much limited to keep it.
; Possible TODO: add support for user defined fixed message numbers
(DISPIDs) which are not continuous small numbers so
users cannot easy use hash arrays with strict order.
Is such functionality necessary? Can someone with
ActiveX experience say sth about it?
Above implementation has undocumented feature:
it supports hash arrays with keys using numbers only
which can be used like in __AxRegisterHandler() but
I haven't decided yet I should keep, extend or remove
such functionality.
Please make real life test.
I do not have any practice with MS-Windows and OLE and most of above
code I wrote using only documentation so I'm very interesting in real
test results and user opinions about it. If some important functionality
is missing then please inform me about it.
BTW There are some 3-rd party activex implementation for [x]Harbour, i.e.
xharbour.com or FiveWin ones. Maybe someone familiar with them can create
PRG compatibility layer for Harbour. I cannot do that myself because I
do not know that products and their PRG API used in OLE/COM/ActiveX
implementations but if someone can describe it then I can help in such
implementation.
+ harbour/contrib/hbwin/hbolesrv.def
+ harbour/contrib/hbwin/hbolesrv-mgw.def
+ harbour/contrib/hbwin/hbolesrv-ow.def
+ added .DEF link files which are necessary to correctly export
inproc OLE server DLL functions. It's possible that other compilers
or even different versions of the same compilers may use different
a little bit different .DEF files. I tested above with BCC5.5,
MinGW 3.4.5 and OpenWatcom 1.8.
+ harbour/contrib/hbwin/test/olesrv1.prg
+ harbour/contrib/hbwin/test/olesrv1.hbp
+ harbour/contrib/hbwin/test/oletst1.prg
+ harbour/contrib/hbwin/test/oletst1.hbp
+ added example of NETIO-RPC OLE server code with Harbour (PRG) client.
This server redirects all messages sent to its OLE objects to remote
HBNETIO server as function calls. It understands the following
messages:
CONNECT() - creates connection to the server, parameters like in
NETIO_CONNECT() and NETIO_GETCONNECTION() functions
DISCONNECT() - closes current connection
PROCEXISTS() - works like NETIO_PROCEXISTS()
PROCEXEC() - works like NETIO_PROCEXEC()
PROCEXECW() - works like NETIO_PROCEXECW()
FUNCEXEC() - works like NETIO_FUNCEXEC()
All other messages are redirected directly to RPS server as function
calls.
CONNECT() message should be executed by client to create
connection to the server. Each NETIO-RPC OLE object uses its own
connection which should be initialized. If CONNECT() is executed
more then once the current connection is closed.
DISCONNECT() is executed automatically when OLE object is destroyed
so it's not necessary to call it explicitly.
Please use hbmk2 and olesrv1.hbp to compile OLE server. OLE inproc
servers have to export some DLL entry functions which are defined
in .def files which have to be passed to linker.
Before client code can be tested the server has to be registered.
The server can be registered in given MS-Windows system using
regsvr32.exe command. To register the server use:
regsvr32 olesrv1.dll
and to unregister:
regsvr32 /u olesrv1.dll
+ harbour/contrib/hbwin/test/olesrv2.prg
+ harbour/contrib/hbwin/test/olesrv2.hbp
+ harbour/contrib/hbwin/test/oletst2.prg
+ harbour/contrib/hbwin/test/oletst2.hbp
+ added very simple example of OLE server using hash array with
strict item order (associative hash array) to define OLE objects
with fixed message numbers (DISPIDs)
Remember about registering the server by 'regsvr32 olesrv2.dll'
+ harbour/contrib/hbwin/test/olesrv3.prg
+ harbour/contrib/hbwin/test/olesrv3.hbp
+ harbour/contrib/hbwin/test/oletst3.prg
+ harbour/contrib/hbwin/test/oletst3.hbp
+ harbour/contrib/hbwin/test/oletst3.bas
+ added example of OLE server code with Harbour (PRG)
and Visual Basic (BAS) clients.
This server redirects all messages sent to its OLE objects to HVM
functions and messages to HVM memver (public and private) variables
This server should work as xHarbour.com OLE servers described at:
http://xharbour.com/index.asp?page=add_on_oleserver&show_sub=7&show_i=1
The server and clients code are nearly the same so users can easy
compare them.
Remember about registering the server by 'regsvr32 olesrv2.dll'
* contrib/hbide/ideprojmanager.prg
! Fixed output directory issue without the need for an hbmk2 plugin.
HBIDE was changing current dir when calling hbmk2, so the detected
output filename needs to be rebased from that directory.
* contrib/hbide/ideprojmanager.prg
- contrib/hbide/idedetect.prg
+ contrib/hbide/resources/hbmk2_plugin_hbide.prg
* Moved plugin to resources directory.
- Commented plugin content.
* utils/hbmk2/hbmk2.prg
* Cleaned up path seps in plugin filenames.
+ contrib/hbide/idedetect.prg
+ Added: -plugin= plugin to detect output target.
* contrib/hbide/ideprojmanager.prg
+ Implemented: -plugin=( hb_dirBase() + "idedetect.prg" ).
This implementation raises the barrier what was ailing hbIDE
since long to detect the executable properly.
Thanks Viktor, this is wonderful addition to hbMK2.
* utils/hbmk2/hbmk2.prg
* '-plug=' option renamed to '-plugin='
+ Added support for 'plugins=' line in .hbc files.
% Plugins are now fully loaded just once at the beginning
of hbmk2. (as opposed to every invocation)
+ Plugins are now automatically treated as .hrb or .prg
based on _file content_. This means that any extension
can be used for plugins for both .prg and .hrb code.
When .prg or .hrb extension is used there isn't any
extra trial made on the file content, it will be load
as source or HRB respectively.
Maybe we should find a new distinctive extension for
hbmk2 plugins.
* Default extension for -plugin= option changed to .prg
(was: .hrb)
+ Showing type of input plugin in -trace mode.
('source' or 'compiled')
* config/detect.mk
! Applied fix to DragonFly patch, submitted by Tamas Tevesz.
* src/vm/runner.c
* Minor formatting.
* INSTALL
+ Added one more envvar which is apparently used by users
even though it does nothing since many years.
(see '10. TROUBLESHOOTING' section)
* config/postinst.prg
* Minor cleanups.
* src/common/hbprintf.c
* include/hbsetup.h
* config/global.mk
* config/bsd/libs.mk
* config/detect.mk
+ Applied patch by Tamas Tevesz, making it possible to build
Harbour for DragonFly BSD systems.
Thanks a bunch.
* utils/hbmk2/hbmk2.prg
+ Applied above change to hbmk2 code, so now it should also
support DragonFly BSD. (pls test it)
* utils/hbmk2/hbmk2.prg
+ Added .hbi to the list of accepted projects at cmdline.
This means that hbmk2 can be run like 'hbmk2 mylib.hbp mylib.hbi'
to create the lib and also generate the implib.
* '-keyheader=' renamed to '-reqheader='
! Fixed typo causing RTE while creating implibs for targets
supporting OMF lib type.
* utils/hbmk2/hbmk2.prg
+ Added experimental feature to aid external dependency
detection. Key header files can now be specified using
'-keyheader=' option. In case such key headers are not
found when evaluating '-inctrypath' conditional header
directories. The goal is to make hbmk2 capable of
replacing GNU Make for all of our contribs. F.e.:
'clean':
{HB_HOST_BIN_DIR}/hbmk2 hbfbird/hbfbird.hbp hbsms/hbsms.hbp -o../lib/${hb_plat}/${hb_comp}/ -clean
simple make:
{HB_HOST_BIN_DIR}/hbmk2 hbfbird/hbfbird.hbp hbsms/hbsms.hbp -o../lib/${hb_plat}/${hb_comp}/
'install':
{HB_HOST_BIN_DIR}/hbmk2 hbfbird/hbfbird.hbp hbsms/hbsms.hbp -o../lib/${hb_plat}/${hb_comp}/ -instpath=${HB_LIB_INSTALL}/ -info
% Minor cleanup to some plugin API functions.
* utils/hbmk2/examples/plug_moc.prg
% Minor cleanup.
* contrib/sddoci/tests/test1.prg
+ Showing field length and decimals.
* harbour/include/hbapi.h
* harbour/src/vm/hashes.c
* harbour/src/vm/hashfunc.c
+ added support for keeping strict assign order in hash arrays. It's
enabled optionally by setting HB_HASH_KEEPORDER hash array flag.
It gives the same functionality as associative arrays in xHarbour
(enabled by HSETAACOMPATIBILITY()) but this implementation is
internally completely different. It does not introduce linear
scan in add operation so enabling it should not reduce the
performance in this operation. It can even improve it on some
hardware reducing number of memory bytes which have to be moved.
Only delete operation will force linear index scan. The most
important in this implementation is that it does not need any
additional functions like HAA*() in xHarbour. Just simply all
existing functions operating on position indexes like HB_HPOS(),
HB_HKEYAT(), HB_HVALUEAT(), HB_HPAIRAT(), HB_HDELAT(), HB_HSCAN()
use as index natural order in which items were added to hash array.
Also HB_HKEYS(), HB_HVALUES() and FOR EACH iterations respect it.
+ added new PRG functions
HB_HKEEPORDER( <hValue> [, <lNewSetting> ] ) -> <lPrevSetting>
HB_HSETORDER( <hValue> [, <lNewSetting> ] ) -> <hValue>
which cam be used to enable/disable strict order in hash array.
Enabling strict order for non empty hash arrays accept the order
created after sorting existing item not the original assign order.
Disabling strict order for non empty hash arrays may change the
items order.
; TODO: add translation for xHarbour's HAA*() functions to hbcompat.ch
and/or xhb library.
* harbour/contrib/hbnetio/netiocli.c
* harbour/contrib/hbnetio/netiosrv.c
% reenabled TCP_NODELAY on client and server side
I had to be really tired when I was making tests and I mixed
hb_socketSetNoDelay() with hb_socketSetBlockingIO().
Thanks to Aleksander Czajczynski who noticed the delay in his
tests.
* harbour/contrib/hbwin/olecore.c
* minor cleanup
* contrib/hbtip/thtml.prg
* removed old FOR EACH limitation
* using HB_OSNewLine() as eol
% on ::popNode added capability to check if end tags for the following
tags are found: "tr","th","td"
to end this tags, the user simply needs to call the current node
with the minus ( - ) operator for the tag requiered to close:
node - "th"
* ChangeLog
! Fixed wrong entry on my previous commit
* harbour/src/vm/hashes.c
* do not clone preallocated unused area
* harbour/contrib/hbnetio/netiocli.c
* disabled RT errors inside NETIO_CONNECT() and NETIO_GETCONNECTION()
when wrong password or NETIO server is used but return .F.
* utils/hbmk2/hbmk2.prg
+ Upped warning level for plugins to -w3.
* utils/hbmk2/examples/plug_moc.prg
+ Added -inc, -clean and -rebuild (IOW incremental)
support for moc plugin. It was tested OK in small
example.
* utils/hbmk2/examples/plug_tpl.prg
* Minor.
* utils/hbmk2/hbmk2.prg
* Moved some local variables to internal hbmk2 structure.
+ Made some more functions and variables accesible to plugns
in order to help creating smooth external calls.
+ utils/hbmk2/examples/plug_moc.prg
+ Added 'moc' plugin, which is supposed to be fully functionaly,
though I didn't test it live.
- utils/hbmk2/examples/plug_moc.prg
+ utils/hbmk2/examples/plug_tpl.prg
* Renamed first example.
* utils/hbmk2/hbmk2.prg
* utils/hbmk2/examples/plug_moc.prg
% Further cleaned context passing, so that now even the
'state' variable is passed as part of context rather than
as separate variable, so now the only parameter the plugin
gets is the callback. This is much more flexible and future
proof this way.
* utils/hbmk2/hbmk2.prg
* utils/hbmk2/examples/plug_moc.prg
% Refined how context is passed to plugins, and how
context is passed back to public APIs.
+ Added way to accept parameters from the cmdline and .hbp
files. This is possible via '-pflag=' and '-pi=' options.
Latter serves to pass input file, so the input file magic
logic is always applied to it. Notice that all plugins are
getting all input parameters, so it's their job to process
only what's relevant to them. plugin specific option prefixes
f.e. can be a solution for that.
+ Added API to add new input .prg, .c, .cpp and .rc files
to the build process.
+ Added better protection from tampering internal hbmk2
structures by plugins.
+ Showing error condition and location in case of an RTE occurs
in a plugin.
* harbour/include/hbapi.h
* harbour/include/hbvmint.h
* harbour/include/hbvmopt.h
* harbour/include/hbstack.h
* harbour/include/hbvmpub.h
* harbour/include/hbtypes.h
* harbour/src/vm/estack.c
* harbour/src/vm/hvmall.c
* slightly modified the names of HB_{API|STACK}_MACROS.
These are internal macros in current Harbour code but they are
still defined in some old user build scripts used to compiled
user or core code what could cause unpredictable results for
final binaries. AFAIR default xMate configuration enables them.
* utils/hbmk2/hbmk2.prg
+ utils/hbmk2/examples/plug_moc.prg
+ Added experimental plugin system. Plugins are written in .prg
or .hrb and can be passed using '-plug=<.prg|.hrb>' option
or simply by passing '.hrb' filename from cmdline or .hbp/.hbm
files. Plugin names without dir component will be searched
in local dir, hbmk2 dir then PATH.
For the details of the calling protocol and available hbmk2
API calls and variables, pls check the example and hbmk2
source code.
Plugin is called from several build stages, in case of multiple
plugins all of them are called at each stage. The plugin
receives the stage name, hbmk2 context and a hash table for
custom variables. The variables are shared between stages and
plugins. Notice that hbmk2 isn't hbrun, so there is a limited
set of the Harbour language which you can use, this also ensures
that the plugins will behave like hbmk2 itself for the most part.
Nothing is finalized.
; The example is the working replica of moc detection logic found
inside hbqt.
* utils/hbmk2/hbmk2.pt_BR.po
* utils/hbmk2/hbmk2.hu_HU.po
* utils/hbmk2/hbmk2.prg
+ In non-incremental mode when no workdir is manually set, hbmk2
will now create a temp subdir inside temp dir and create any
intermediate output files there. (previously it was using the
temp dir without creating a temp subdir inside).
; Please test and report leftover temp files and dirs, also test
it on *nix platforms.
* Changed 'couldn't', 'don't' style English abbrevs to
'could not', 'do not', etc.
* config/rules.mk
! Fixed to include static-only C compiler options for targets
which have no separate static/dynamic C compiler pass.
This should fix wrongly built pcre lib causing missing
exported functions in mingw Harbour .dlls.
* utils/hbmk2/hbmk2.prg
+ Changed filtering implementation for cmdline parameters.
Now filters can be placed anywhere and they work for all
parameters.
Please test, regressions may be possible.
* config/postinst.prg
! Added gpm handling logic to hbmk.cfg creation. This was
previously done in recently deleted postinst.sh function.
* harbour/contrib/hbnetio/netiocli.c
* harbour/contrib/hbnetio/readme.txt
+ added new client side function:
NETIO_GETCONNECTION( [<cServer>], [<nPort>], [<nTimeOut>], ;
[<cPasswd>], [<nCompressionLevel>], [<nStrategy>] )
-> <pConnection> | NIL
I returns pointer item with HBNTIO connection. It can be used to
speedup RPC calls and stream functions when <pConnection> is
passed as parameter to these functions.
+ modified NETIO_PROCEXISTS(), NETIO_PROCEXEC(), NETIO_PROCEXECW(),
NETIO_FUNCEXEC(), NETIO_OPENDATASTREAM(), NETIO_OPENITEMSTREAM()
client side functions to accept as optional 1-st parameter
connection pointer returned by NETIO_GETCONNECTION()
+ modified NETIO_CLOSESTREAM() and NETIO_GETDATA() client side
functions to accept as optional 2-nd parameter connection pointer
returned by NETIO_GETCONNECTION()
* bin/hb-func.sh
* bin/postinst.sh
- Deleted 'hbmk' script. Now superceded by hbmk2, which is
backward compatible with hbmk.
- Deleted 'hb-mkslib' compatibility synonym. Use 'hb-mkdyn'
instead.
* utils/hbmk2/hbmk2.prg
! -hbimplib extended for bcc and msvc* to automatically recognize
and use .def file with the same name as the .dll, if present.
! -hbimplib extended for bcc to first look for any existing
OMF .lib file with the same name as the .dll.
! Refined fallback logic used in implib generation.
(moved .dll existence check to lower level)
* Refinements in pathsep usage in implib generation.
* contrib/sddfb/sddfb.hbi
* contrib/hbfbird/hbfbird.hbi
+ Using COFF libs for pocc targets.
