Clipper Tools comms routines
dougwoodrow
I have some existing Clipper applications that I need to convert to 32-
bit applications, and I'm currently trying to choose between Harbour
or xHarbour. The only third party libs used are Advantage database
server and some from CATools3, including the serial communications
routines. No need for a GUI.
So far I've tried the free version of xHarbour, it's easy to build
applications using the xBuild utility. Using a dynamic version of the
rddads lib I was able to connect to ADS with no problems. xHarbour
does not include the old Clipper Advantage functions like
AX_ServerTime() but I was able to create my own version using
AdsGetServerTime(), and presumably will be able to the same with the
other AX_ functions.
The comms support seems a lot less promising, except there is a
CT3Comm.lib included with the commercial xHarbour Professional
package, which claims to be "near 100% Clipper compatible". But that
of course would mean committing myself to xHarbour...
Any recommendations from you Harbour experts? Is there a CT3 comms
lib available already for Harbour, or has anyone created comms
wrappers to emulate the CT3 functions using hbtpathy (or any other
lib)?
Also, how do I go about creating the dynamic version of the rddads lib
in Harbour?
Pritpal Bedi
> I have some existing Clipper applications that I need to convert to 32-
> bit applications, and I'm currently trying to choose between Harbour
> or xHarbour. The only third party libs used are Advantage database
> server and some from CATools3, including the serial communications
> routines. No need for a GUI.
hbct librray. Simply link it. No need to change your code.
> The comms support seems a lot less promising, except there is a
> CT3Comm.lib included with the commercial xHarbour Professional
> package, which claims to be "near 100% Clipper compatible". But that
> of course would mean committing myself to xHarbour...
But this is a Windows only solution.
So is Harbour's native library with a plus that
it is portable across all platforms.
Pritpal Bedi
dougwoodrow
>
> Harbour has exactly CT-3 compatible Com_*() functions in
> hbct librray. Simply link it. No need to change your code.
> > of course would mean committing myself to xHarbour...
>
> Yes it is 100% Clipper compatible.
> But this is a Windows only solution.
>
> So is Harbour's native library with a plus that
> it is portable across all platforms.
favour, thanks again.
Przemysław Czerpak
Hi,
> I have some existing Clipper applications that I need to convert to 32-
> bit applications, and I'm currently trying to choose between Harbour
> or xHarbour. The only third party libs used are Advantage database
> server and some from CATools3, including the serial communications
> routines. No need for a GUI.
>
> So far I've tried the free version of xHarbour, it's easy to build
> applications using the xBuild utility. Using a dynamic version of the
In Harbour you will find HBMK2 tool which have much wider functionality
then XBuild but it's text only tool and will stay in such form. It's
intentional.
For GUI some frontends are created, i.e. HBIDE.
In HBMK2 you will find many interesting options, i.e. support for
internationalization (Harbour can generate GETTEXT compatible .po[t]
files and HBMK2 can very nicely manage them, etc.
If you want then you can even make two copies of hbmk2.exe as clipper.exe
and rtlink.exe or blinker.exe and use them as standards Clipper tools i.e.
with RMAKE and existing .rmk files or your own batches.
HBMK2 automatically detects that were renamed and switch to coresponding
input processing. Anyhow I strongly suggest to used it in native mode
with .hbp files - they open completely new world, i.e. in portability.
You can start with simple .hbp file were you put all your .prg files
with Harbour compiler switches, i.e.:
-n
-w
file1.prg
file2.prg
file3.prg
then you can start to use new HBMK2 options, i.e. add:
-inc
like to enable increamental build mode, etc.
> rddads lib I was able to connect to ADS with no problems. xHarbour
> does not include the old Clipper Advantage functions like
> AX_ServerTime() but I was able to create my own version using
> AdsGetServerTime(), and presumably will be able to the same with the
> other AX_ functions.
The ADS code is very similar in both projects so list of functions
available for PRG programmer is nearly the same. They cover nearly
whole ADS/ACE functionality - for sure much wider area then in Clipper
anyhow it's highly possible that [x]Harbour ADS API is not compatible
with Clipper and maybe some ACE functions present in Clipper are not
available in 32/64-bit ACE library so they will not exist also in
32/64 bit wrappers for different languages like [x]Harbour or Delphi.
I've never used ADS with Clipper so I cannot say too much about
compatibility with Clipper DOS ACE version.
In last years most of modifications in RDD and ACE code were done
in Harbour and then they are usually ported to xHarbour though with
some delay and not all of them.
> The comms support seems a lot less promising, except there is a
> CT3Comm.lib included with the commercial xHarbour Professional
> package, which claims to be "near 100% Clipper compatible". But that
> of course would mean committing myself to xHarbour...
Harbour contains in code code support for COM ports which works for
all platforms and is far beyond anything ever created for xHarbour.
Harbour include his own CT3COM code which is more completed then
commercial xHarbour version and works with all platforms using internaly
core Harbour API and xHarbour.com CT3COM library is only for MS-Windows.
Anyhow both implementation are not fully compatible with CT3. It's caused
by the nature of COM support in modern OS-es. In old DOS the lowlvel
access to the hardware (IO ports and interupts) was done by application
code which access it directly. In modern OS-es it's done by the system
and application cannot touch hardware at all. It's hardware protection
so you cannot make it even if you want. Only code which is executed
with kernel space privileges can do touch hardware. So we are limited
to the OS. It means that we do not have to worry about different devices,
it's enough that system supports them and they will work with our
application automatically just like any other ones using the same
system API. But it also means that we cannot change some behavior
hardcoded in system code or add our own actions which strictly depends
on some hardware events. One of such action is COM_KEY() you were
asking on xHarbour.news group. Neither Harbour nor xHarbour.com CT3COM
library supports it because in modern OS-es we cannot attach our own
interrupt handler to COM ports to put key into keyboard buffer when
some event appear. In Harbour I can easy implement it only for DOS
builds but who will use it in current days?
Theoretically it can be done by some active loop executed to call
system functions to check for new events copping incoming data to
own buffer but it's a nightmare for resource consumption so it's
easier and much more efficient if user implements such functionality
himself using his own loops and buffers only when he need it.
If you look at harbour/contrib/ctcom[12].c then you will find list
of implemented COM_*() and related functions. I added TODO note
for all missing functionality but all what is missing is platform
dependent and cannot be implemented without active loop I described
above. xHarbour.com CT3COM library does not address any of the TODO
you will find (with one unimportant exception) and some functions
are not implemented at all.
> Any recommendations from you Harbour experts? Is there a CT3 comms
> lib available already for Harbour, or has anyone created comms
> wrappers to emulate the CT3 functions using hbtpathy (or any other
> lib)?
The most complited one you will find in HBCT library for Harbour.
> Also, how do I go about creating the dynamic version of the rddads lib
> in Harbour?
If you are talking about ace32.c from xharbour/contrib/rdd_add then
you can use it with some minor modifications with Harbour too anyhow
it's fatal idea. Technically this is nonsense because [x]Harbour ADS
RDD code uses some definitions from ACE headers which are different
in different ACE version. When you compile RDD ADS then some things
are statically compiled depending on used ace.h header file, i.e.
buffer for index key in older ACE versions has 256 bytes but in newer
it's 4096 so it may cause buffer overflow when buffer size is smaller
then necessary. Or if you compile it with ACE >= 6.00 then for seek
operation ADS_RAWKEY or ADS_STRINGKEY may be used but in older ACE
versions only ADS_STRINGKEY is supported so ADS_RAWKEY will fail.
The same can happen with AdsGetFieldRaw() which is used by ADS RDD
for ACE >= 6.00 and for older versions AdsGetField().
When ACE >= 7.00 is detected then functions like AdsGetLongLong()
are used but for older ACE versions AdsGetDouble(), for ACE >= 6.10
AdsCreateIndex61() is used but for older versions AdsCreateIndex(),
etc.
The ace32.c is simple dynamic wrapper for all ACE functions which
does not respect the fact that for different ACE header files different
functions are used by ADS RDD so the mapping has to be adopted to
used library. So some things does not work at all or works incorrectly
when used ACE library is in different version then the one used to
compile RDD ADS code. If someone things differently then he is simply
wrong and haven't tested it well. When he presents his opinion on public
forum then it only shows what he knows about the problem and [x]Harbour
RDD ADS implementation details. Theoretically it's possible to create
such dynamic wrapper but it needs modification in core ADS RDD code
or at least some strict synchronization with core code and the wrapper.
Then it's necessary to carefully update them together and check for
possible interactions with each new ACE header files updating the code
and replacing some static parts with new dynamic code when something
is changed. So far no one try to make it well and I have serious doubts
that we will ever find trusted person with sufficient knowledge and
enough spare time for such job. For sure I do not plan to analyze the
whole code against all existing ACE header files. I simply suggest to
use ACE library corresponding to ACE header file used to compile ADS RDD.
best regards,
Przemek
ps. if you are intersting in more precise information about differences
between Harbour and xHarbour then you can look at:
http://harbour-project.svn.sf.net/svnroot/harbour-project/trunk/harbour/doc/xhb-diff.txt
matt johnson
I have interfaced laser measuring scale and Sartorius weighing scale via RS-232.
Let me know if you want more info. Regards, Matt, mattfr...@yahoo.com
--- On Tue, 4/19/11, dougwoodrow <dougw...@gmail.com> wrote:
> --
> You received this message because you are subscribed to the
> Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
dougwoodrow
> I have had better luck with the hb_tpathy library than CT tools for serial communications.
>
> I have interfaced laser measuring scale and Sartorius weighing scale via RS-232.
>
> Let me know if you want more info.
perfectly with the original CATools so hopefully using Harbour's CT3
routines will be the quickest way to get a 32-bit application that
works the same way. Thanks for the offer though, if I encounter any
problems I will let you know :)
dougwoodrow
[snip extensive reply]
> ps. if you are intersting in more precise information about differences
> between Harbour and xHarbour then you can look at:
Wow, Przemek, thank you very much for going into such a detailed and
clear explanation of all the issues. You've definitely convinced me
to switch my attention to Harbour. And it's good to understand the
problems with the dynamic rddads lib. It's no big deal having to
build a new version of the application when my client upgrades their
Advantage server.
kind regards,
Doug.
Viktor Szakáts
altogether. It's quite new feature and not yet enabled in default
builds. You need to rebuild Harbour with option:
set HB_BUILD_CONTRIB_DYN=yes
Then you can build any of the examples in contrib/rddads/tests/
with this setting:
set HB_DYNLOAD_RDDADS=yes
hbmk2 <test.prg>
The examples will then dynamically load RDDADS .dll at
runtime.
Which means you can have multiple RDDADS builds under
different names, f.e. rddads61.dll and rddads90.dll and load them
as needed. You have to take care that matching ADS .dlls
be installed. It's quite new functionality, so expect some bumps
and report what you find.
Viktor
dougwoodrow
> In Harbour it is also supported to load rddads dynamically
> altogether. It's quite new feature and not yet enabled in default
> builds. You need to rebuild Harbour with option:
> set HB_BUILD_CONTRIB_DYN=yes
>
> Then you can build any of the examples in contrib/rddads/tests/
> with this setting:
> set HB_DYNLOAD_RDDADS=yes
> hbmk2 <test.prg>
>
> The examples will then dynamically load RDDADS .dll at
> runtime.
>
> Which means you can have multiple RDDADS builds under
> different names, f.e. rddads61.dll and rddads90.dll and load them
> as needed. You have to take care that matching ADS .dlls
> be installed. It's quite new functionality, so expect some bumps
> and report what you find.
It might be some time before I can test that, but it sounds like a
potentially useful feature. Thank you!
matt johnson
regards, Matt
--- On Wed, 4/20/11, dougwoodrow <dougw...@gmail.com> wrote:
> From: dougwoodrow <dougw...@gmail.com>
> Subject: [harbour-users] Re: Clipper Tools comms routines
> To: "Harbour Users" <harbou...@googlegroups.com>
Viktor Szakáts
> I recall that I could not make the CT comms work. ( several years ago ) You may find that all need is a handful of comms functions ( open, close read, write ) and that a wrapper function can convert your CT functions to hb_tpathy .
in core using brand new solution less than a year ago.
So now both hbtpathy and hbct (and also hbcomm
and hbsms) uses this very same core comm API, so
they should all work well.
Harbour also got new a .prg level comm API (HB_COM*()
functions), which is the best choice for new .prg com
code.
Viktor
dougwoodrow
Harbour comm functionality have been reimplemented
in core using brand new solution less than a year ago.
Qatan
----- Original Message -----From: dougwoodrowSent: Wednesday, 20 de April de 2011 16:49Subject: [harbour-users] Re: Clipper Tools comms routines
--
dougwoodrow
Harbour is a project in constant development so I would recommend you to download the last nightly build and keep connected to the list so you will know what are the new improvements, bug fixes, adds, news, etc...
Qatan
Viktor Szakáts
> On Wednesday, April 20, 2011 9:26:01 PM UTC+1, Qatan wrote:
>
> > Harbour is a project in constant development so I would recommend you
> > to download the last nightly build and keep connected to the list so you
> > will know what are the new improvements, bug fixes, adds, news, etc...
> > To download go to:
> Thanks Qatan,
> I've already started using the latest source straight from the SVN trunk, is
> that a bad idea?
development build so it's rare but possible to have
short-term fluctuations in stableness. Usually
problems are localized to the small area which got
updated.
Sometimes things may change in a way you need to
follow with your local code, but that's natural part of
the "package" of such development style.
So, it couldn't hurt to watch the commits to be informed
about these, but you are quite safe by just using it.
F.e. ATM I use r16616 for live stuff.
Viktor
Marco Boeri
Massimo Belgrano
https://sourceforge.net/projects/harbour-project/files/binaries-windows/nightly/harbour-nightly-win.exe/download
2011/4/21 Marco Boeri <boer...@hotmail.com>:
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
--
Massimo Belgrano
Marco Boeri
Yes I understood that it's a compiled version of Harbour (only for few OSes and platforms I suppose), but I was curious about the differecens between a compiled SVN version and the "nightly build" version: are there some libs missing? Or what else?
Ciao,
Marco
Massimo Belgrano
2011/4/21 Marco Boeri <boer...@hotmail.com>:
Qatan
--
Marco Boeri
thanks for your explanations. The used compiler is MingW, right?
Regards,
Marco
Massimo Belgrano
Hi Qatan, Massimo, all,
thanks for your explanations. The used compiler is MingW, right?
Regards,
Marco
Massimo Belgrano
Viktor Szakáts
> Hi Qatan, Massimo, all,
> thanks for your explanations. The used compiler is MingW, right?
The mingw compiler itself is also included in the
package, so you don't need else.
The 2.0.0 release binary contains support for
more platforms/compilers, check the lib dir
for them.
Viktor
Qatan
Marco Boeri
thanks to all for explanations. I'll give it a look.
Regards,
Marco
> Date: Fri, 22 Apr 2011 03:38:13 -0700
> Subject: [harbour-users] Re: Clipper Tools comms routines
> From: harbo...@syenar.hu
> To: harbou...@googlegroups.com