* contrib/hbqt/Makefile
* contrib/hbqt/qtgui/Makefile
* contrib/hbqt/qtcore/Makefile
* contrib/hbqt/qtnetwork/Makefile
+ Enabled HB_QT_STATIC for all OSes.
* contrib/hbqt/hbqt.hbc
* contrib/hbqt/hbqts.hbc
- Deleted no more needed special Windows system libs.
* contrib/hbqt/hbqts.hbc
- Deleted webkit libs.
+ Enabled static libs for linux. (they are named the
same as on Windows)
* contrib/gtwvg/tests/demowvg.hbp
! Missing SVN header.
! Missing SVN props.
! Deleted local system specific absolute paths.
TOFIX: HBIDE should make the working (what is it BTW)
and destination folders relative to the location
of .hbp. BTW destination is redundant, since -o
already specifies that.
! Deleted -trace -info. These should be user decisions.
* utils/hbmk2/hbmk2.prg
+ Beefed up and fixed -reqpkg feature:
+ Possible to pass multiple alternate pkg names:
-reqpkg=cairo|cairo2|cairo.h
+ Possible to attach header name, in which case it
will automatically satify the -reqheader= parameter
with same header name, if it exists. Headers without
extension can be specified as 'header.'
! Fixed to use case-insensitive lookup in header list
on non-*nix systems.
+ Added -info messages regarding pkg detection.
! Fixed parsing of -l/-L/-I parameters in pkg detection
code.
* INSTALL
* config/global.mk
+ Added support for configurations where PATH contains the same
compiler multiple times. (and all similar cases when a files
is looked for in a list of possible dirs). From now on only
the first one will be extracted. Dirs can still contain spaces.
Such configurations started to appear like mushrooms just
recently. Maybe it's something seasonal. Anyhow I'd suggest
to fix such configurations, since it may cause misc problems,
outside the real of Harbour. So the INSTALL is still not
lying:
Keep only one compiler in PATH at any time, and especially
don't keep the same C compiler multiple times in PATH, and
especially not two different versions of the same C compiler.
If you're is interested in GNU Make black magic for some (pervert)
reason, you may want to take a closer look at the implementation.
* harbour/contrib/hbwin/olecore.c
! fixed old bug in passing parameters by reference to OLE objects
(they were cleared in reverted order so half of the complex variants
were cleared before coping to HVM items)
+ harbour/contrib/hbwin/tests/oletst4.prg
+ harbour/contrib/hbwin/tests/olesrv4.hbp
+ harbour/contrib/hbwin/tests/olesrv4.prg
+ harbour/contrib/hbwin/tests/oletst4.hbp
+ added example of OLE server returning to client HVM objects as
OLE object and also some other values using parameters passed by
reference with client code.
Remember about registering the server by 'regsvr32 olesrv2.dll'
before testing the client code.
* utils/hbmk2/hbmk2.prg
! Fixed silly variable initialization bug after last commit.
* contrib/hbwin/wapi_shellapi.c
! Fixed WAPI_SHELLEXECUTE() having HB_PARSTRDEF() one
position off.
* examples/rddado/tests/access1.prg
* Minor update. Still doesn't work.
+ contrib/gtwvg/tests/demowvg.hbp
+ Project definition.
+ contrib/gtwvg/tests/wvgactivex.prg
+ contrib/gtwvg/tests/wvgcuigdialog.prg
+ contrib/gtwvg/tests/wvgdyndialogs.prg
+ contrib/gtwvg/tests/wvgmodal.prg
+ contrib/gtwvg/tests/wvgqt.prg
+ contrib/gtwvg/tests/wvgtbrowser.prg
+ contrib/gtwvg/tests/wvgutilities.prg
+ contrib/gtwvg/tests/wvgwvtclasses.prg
+ contrib/gtwvg/tests/wvgxbp.prg
+ Code organized in logical units.
* contrib/gtwvg/tests/demowvg.prg
- Code moved to smaller modular sources as logical units.
This demo was written few years back and then at that point of time
no standradized make system was aavailable which led me to club
everything in one source. Now because we have an excellent hbMK2
in place so this move has been possible.
It is the first in series of reforms pertaining to GTWVG.
More are scheduled to be followed.
* contrib/hbmisc/calldll.prg
! Fixed to use Windows system .dll calling convention
(stdcall) by default, to emulate original function's
behavior. Note that on non-Windows systems, calling
convention will be set to the default (cdecl).
* contrib/hbmisc/tests/testcall.prg
* Replace examples with a Windows system .dll call.
* utils/hbmk2/hbmk2.prg
+ Added untested, experimental support for -reqpkg=/reqpkgs=
(.hbp/.hbc) options. F.e. '-reqpkg=libcurl' option causes
hbmk2 to query library, library path and include path
information from 'pkg-config' tool and if not found using
'*-config' script, and to automatically pass these information
to C compiler/linker. In addition, it will automatically add
a macro named HBMK2_HAS_LIBCURL to C compiler cmdline, so
that the sources get to know that this package was found.
; NOTE: Nothing is finalized, it is still a question how to
setup obligatory and optional components, current
implementation is rather a mixture, but anyway pls
feel free to test it. It's also a question how to merge
this method with the -inctrypath/-reqheader one.
Later we can consider adopting extra C flags, too,
and it can be extended to know about more package
detection methods (even platform dependent ones can
be used if they adhere to more or less the same
principle of 'pkgname->IN incpaths/libpaths/libs->OUT')
Thanks to Tamas Tevesz for sparking the idea.
* src/common/hbver.c
+ Fine tuned SunPro version detection.
Patch submitted by Tamas Tevesz.
* contrib/hbwin/win_shell.c
* contrib/hbwin/tests/testcopy.prg
! WIN_SHFILEOPERATION() fixed after initial upload.
+ Added more test code.
* utils/hbmk2/hbmk2.prg
+ Added ${hb_filename} macro.
+ "hbexe", "hblib", "hbdyn", "hbdynvm", "hbimplib" can now
be used as filter keywords to detect target type.
* contrib/hbwin/hbolesrv.hbc
+ Will now show warning message if not used together with
-hbdynvm option.
+ Will will now be ignored if not used together with
-hbdynvm option.
; Tried to add hbolesrv.c as direct source 'sources=hbolesrv.c',
but it requires this source (+ headers) to be distributed along
the binaries, plus it didn't resolve the watcom issue, so
I dropped it.
* contrib/hbmisc/calldll.prg
+ HB_DYNCALL1() will now cut the number of parameters
according to passed nCount parameter, just to mimic
exact behavior of original function.
+ contrib/hbmisc/tests/testcall.prg
+ Added test code for CALLDLL32() and HB_DYNCALL1().
* contrib/hbwin/tests/testcopy.prg
* Copyright year.
* contrib/hbmisc/Makefile
+ contrib/hbmisc/calldll.prg
+ Added CALLDLL compatibility API interface:
CALLDLL32(), HB_DYNACALL1(), STRPTR(), PTRSTR(), UNLOADALLDLL().
; Lightly tested, it's based on core .dll functions, so it may only
need easy tweaking. Notice that this API support all platforms,
not just 32-bit Windows.
The original library is found in MINIGUI f.e.
* contrib/hbwin/win_shell.c
* Minor formatting.
* contrib/hbwin/wapi_wingdi.c
* contrib/hbwin/hbolesrv.c
! Fixed for msvcarm.
* contrib/hbwin/hbwin.ch
* contrib/hbwin/win_shell.c
+ contrib/hbwin/tests/testcopy.prg
+ Added:
WIN_SHFileOperation( [<hWnd>], [<nFunction>], [<cFrom>|<aFrom>], [<cTo>|<aTo>],
[<nFlags>], [<@lAnyOperationAborted>],
[<aNameMappings>], [<cProgressTitle>] ) -> <nResult>
; Przemek, if you have some time pls review s_StringList()
function which I adapted from similar function in win_dlg.c,
but it might not be perfect. '<s1><\0><s2><\0><\0>' format
is required by this SHFileOperation() Windows function.
* harbour/contrib/hbwin/hbolesrv.c
% improved the performance and reduced memory usage by using hash
array with strict assign order for message names to number translation
in OLE objects accepting any message names
* harbour/contrib/xhb/Makefile
+ harbour/contrib/xhb/xhbhasha.c
+ added xHarbour Hash with Associative Array compatibility functions:
HAAGETKEYAT( <hValue>, <nPos> ) -> <value>
HAAGETVALUEAT( <hValue>, <nPos> ) -> <value>
HAASETVALUEAT( <hValue>, <nPos>, <value> ) -> NIL
HAADELAT( <hValue>, <nPos> ) -> NIL
HAAGETPOS( <hValue>, <xKey> ) -> <nPos>
HAAGETREALPOS( <hValue>, <nPos> ) -> <nRealPos>
HGETVAAPOS( <hValue> ) -> <aOrder>
HSETAACOMPATIBILITY( <hValue>, <lAACompat> ) -> <lDone>
HGETAACOMPATIBILITY( <hValue> ) -> <lAACompat>
These functions were added only for compatibility with existing
xHarbour code. Harbour does not emulate associative arrays by
special index but it uses real natural order for them. It means
that associative array indexes are equal to regular hash indexes
so we do not need any translation between them and Harbour users
can use regular hash array functions for associative array indexes,
i.e. instead of using HAAGETKEYAT() they can use HB_HKEYAT().
* contrib/xhb/xhbfunc.c
+ Added XHB_NETNAME(), XHB_MEMOWRIT()
* contrib/xhb/hbcompat.ch
! Fixed MEMOWRIT() translation. Someone pls test it with
real xhb.
* contrib/xhb/hbcompat.ch
* contrib/xhb/xhb.ch
! Moved xhb_*() function dependent translations to xhb.ch.
(since the promise is that hbcompat.ch translations don't
need xhb lib)
* contrib/xhb/hbcompat.ch
* Grouped together all translations which cannot be
replaced using wrapper technique.
* contrib/xhb/xhbgt.c
* contrib/xhb/xhbfunc.c
! Deleted two wrappers which cannot be wrappers.
(dirty extensions)
* contrib/xhb/Makefile
- contrib/xhb/hbcompat.prg
+ contrib/xhb/xhbfunp.prg
* Renamed.
* contrib/xhb/Makefile
* contrib/xhb/xhbmt.prg
+ contrib/xhb/xhbmtc.c
* contrib/xhb/xhbfunp.prg
% Some .prg wrappers changed to .c ones.
! This also fixed some double implementation
after previous commit.
* contrib/xhb/xhbarr.c
* contrib/xhb/xhbfunp.prg
% Converted RASCAN wrapper to .c and moved to
existing array wrapper source file.
* contrib/xhb/Makefile
* contrib/xhb/xhbfunc.c
+ contrib/xhb/xhbhash.c
% Moved hash wrappers to separate file.
(also synced with xhbfunp.prg content)
- Deleted special macro to disable these wrappers.
* contrib/xhb/Makefile
* contrib/xhb/xhbfunc.c
+ contrib/xhb/xhbinet.c
% Moved inet function wrappers to separate file.
(also synced with xhbfunp.prg content)
- Deleted special macro to disable these wrappers.
* contrib/xhb/Makefile
* contrib/xhb/xhbfunp.prg
+ contrib/xhb/xhbgt.c
+ contrib/xhb/xhbini.c
+ contrib/xhb/xhbproc.c
+ contrib/xhb/xhbregx.c
+ contrib/xhb/xhbmtc.c
+ contrib/xhb/xhbfs.c
+ contrib/xhb/xhbdate.c
+ contrib/xhb/xhbi18n.c
% Rewritten wrappers in .c and moved them to
separate files.
; Few other double definitions fixed after previous commit.
Hopefully now it's optimal and modular, and the best wrappers
were kept.
; Basically hbcompat.ch is now not of too much use, unless
someone specifically want to avoid linking xhb.
* contrib/xhb/Makefile
+ contrib/xhb/hbcompat.prg
+ Added equivalent function wrappers for all hbcompat.ch
translations where such was possible (everywhere besides
"dirty" extensions of original Clipper functions)
; NOTE: This method, as is now, has some advantages:
- doesn't require modification of app source code.
- doesn't require knowledge about hbcompat.ch.
and disadvantages:
- is slightly slower
- will pull unnecessary code parts into the executable
If this change gets positive feedback, the two
disadvantages can be easily mitigated by splitting
hbcompat.prg into multiple .prg sources and replacing
wrappers with .c code where possible.
; Pls review me.
* contrib/xhb/hbcompat.ch
! Minor cleanup.
* contrib/hbcomm/hbcomm.prg
! Fixed return value of OUTCHR(). Thank you Przemek for reviewing.
* contrib/hbqt/generator/hbqtgen.prg
+ Tweaked to operate on local folder and definitions there.
+ contrib/hbqt/hbqscintilla
+ contrib/hbqt/hbqscintilla/doc
+ contrib/hbqt/hbqscintilla/doc/en
+ contrib/hbqt/hbqscintilla/qth
+ contrib/hbqt/hbqscintilla/qth/HBQsciScintilla.qth
+ contrib/hbqt/hbqscintilla/qth/QsciAbstractAPIs.qth
+ contrib/hbqt/hbqscintilla/qth/QsciAPIs.qth
+ contrib/hbqt/hbqscintilla/qth/QsciCommand.qth
+ contrib/hbqt/hbqscintilla/qth/QsciCommandSet.qth
+ contrib/hbqt/hbqscintilla/qth/QsciDocument.qth
+ contrib/hbqt/hbqscintilla/qth/QsciLexer.qth
+ contrib/hbqt/hbqscintilla/qth/QsciLexerCPP.qth
+ contrib/hbqt/hbqscintilla/qth/QsciLexerFlagship.qth
+ contrib/hbqt/hbqscintilla/qth/QsciScintilla.qth
+ contrib/hbqt/hbqscintilla/qth/QsciStyle.qth
+ contrib/hbqt/hbqscintilla/qth/QsciStyledText.qth
+ contrib/hbqt/hbqscintilla/doc/en/class_*.txt
+ Auto generated
+ contrib/hbqt/hbqscintilla/Qsci*.cpp
+ Auto generated.
+ contrib/hbqt/hbqscintilla/THBQsci*.prg
+ Auto generated.
+ contrib/hbqt/hbqscintilla/hbqt_garbage.h
+ Auto generated.
+ contrib/hbqt/hbqscintilla/hbqscintilla.ch
+ Constants for PRG code.
+ contrib/hbqt/hbqscintilla/hbqscintilla.hbp
+ To build hbqscintilla.a/lib
+ contrib/hbqt/hbqscintilla/hbqscintilla.qtp
+ .qth info file.
+ contrib/hbqt/hbqscintilla/hbqt_hbqsciscintilla.cpp
+ contrib/hbqt/hbqscintilla/hbqt_hbqsciscintilla.h
+ contrib/hbqt/hbqt.h
+ Added: constants hbqt_par_Qsci*
; TODO make them local.
+ Initial upload of wrappers for QScintilla.
To generate the sources auto you need to stay in hbqt/hbqscintilla
and issue ../generator/hbqtgen.
HB_WITH_QSCINTILLA and HB_WITH_QT need be properly defined.
I am still finding where to host modified QScintilla, any tips ?
* utils/hbmk2/examples/contribf.hbc
* contrib/Makefile
+ contrib/hbcomm
+ contrib/hbcomm/Makefile
+ contrib/hbcomm/hbcomm.hbc
+ contrib/hbcomm/hbcomm.prg
+ contrib/hbcomm/hbcomm.hbp
+ contrib/hbcomm/tests
+ contrib/hbcomm/tests/hbmk.hbm
+ contrib/hbcomm/tests/test.prg
+ Added HBCOMM compatibility library. It's based on hbct
COM functions. Not tested with real port. Also see one
TOFIX and one INCOMPATIBILITY note inside. The latter
belongs to INCHR() function which in original HBCOMM
library will do HVM corruption by overwriting string
content passed as 3rd parameter. In Harbour 3rd
parameter needs to be passed by reference.
Also added fully adapted test code from HARBOUR MINIGUI
project. Interestingly this code was using the return
value of INCHR() to get the returned buffer, which was
in sync with included HBCOMM code. Anyway, hopefully
this can be finalized based on report from real users.
; DISCLAIMER:
EXPERIMENTAL CODE. USE AT YOUR OWN RISK. NO GUARANTEES.
+ contrib/hbfbird/hbfbird.hbp
+ contrib/hbsms/hbsms.hbp
+ Added early bird experimental .hbp files for contrib
two projects.
* utils/hbmk2/hbmk2.prg
+ Added support for ${hb_dirname} macro which returns the
directory in which the script file is where the macro is
used.
! Fixed so that '-build' option doesn't require a configured
C compiler.
+ Extended hack for bcc autoconfiguration with 5.8 support,
adding an extra system header directory to the include
dir list if it exists. bcc 5.8 appears to be well installed,
so this is probably not needed for most users.
+ Documented dir casing differences between bcc 5.5 and 5.82.
This may be important for autoconfiguration hack to work with
bcc under wine using native hbmk2 build. I'm not even sure
such scenario is possible at all ;)
* harbour/contrib/hbwin/hbwinole.h
* harbour/contrib/hbwin/olecore.c
* modified hb_oleVariantUpdate() parameters
+ added automatic conversion of HVM objects to OLE objects for
for parameters passed by reference to Harbour OLE server methods.
* harbour/contrib/hbwin/hbolesrv.c
+ added automatic conversion of HVM objects to OLE objects for
memvars redirected to OLE instance variables.
! fixed typo
* utils/hbmk2/hbmk2.prg
* utils/hbmk2/hbmk2.pt_BR.po
* utils/hbmk2/hbmk2.hu_HU.po
+ Added support for 'psources=' and 'pflags=' directives in
.hbc files. They serve the same purpose as cmdline '-pi='
and '-pflag=' options; passing parameters to plugins.
% Minor internal optimizations, also fixing some very rare
and light potential problems with letting to add double
parameters when passing them using different pathseps.
* include/hbapifs.h
+ Added some more HB_EXPORT flags. Pls check me.
* contrib/hbwin/hbolesrv.hbc
+ Added reference to hbwin.hbc, so that it can be used
standalone accompanied by -hbdynvm option to create
OLE servers easily: 'hbmk2 -hbdynvm hbolesrv.hbc ...'
* contrib/hbwin/hbolesrv-watcom.def
! Fixed comments to watcom format.
* utils/hbmk2/hbmk2.prg
! Fixed RTE when parsing certain rarer Windows file types
in sources= directive in .hbc files in *nix hbmk2 builds.
(could only kick in when using hbmk2 under *nix to cross
compile for Windows). Thanks Przemek for the report.
- Deleted doubly added support for .def file parsing in sources=
directive.
* harbour/contrib/hbwin/hbwinole.h
! fixed typo in added extern declarations
* harbour/contrib/hbwin/hbwinole.h
* harbour/contrib/hbwin/axcore.c
* harbour/contrib/hbwin/olecore.c
* harbour/contrib/hbwin/hbolesrv.c
+ added support for automatic conversion of HVM objects returned by
Harbour OLE server methods to OLE objects.
Please test. I cannot make any tests now.
; TODO: if it works then update this code to create some more general
version.
* 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.
