Reply-To: erik.wachtmeester@bighole.iaf.nl
Denis Braussen wrote in a message to Erik Wachtmeester:
EW> write a user interface in e.g. Delphi, C++ Builder or Visual C++ that
EW> communicates with a Clipper engine on the background through named
EW> pipes or shared memory?
 DB>     nice idea...
 DB>     but it seems to be difficult to do it :( 
 DB>     i've never heard about such pipes.
Both named and anonymous pipes are quite well known mechanisms in networking
environments, but I've just read an 1100 page book on NT ('Windows NT 4 
erver
Unleashed'), and pipes weren't mentioned even once. Could it be that Windows
doesn't support these, maybe because MS has got it's own Windows messaging,
OLE2, DAO, etc.?
 DB>     Besides CLIPPER makes 16 bits exe and programs like DELPHI, C++
 DB>     Builder are 32 bits App. So you have to call within a 16 bits exe
 DB>     32 bits *.dll and vice et versa (i've red something about that:
 DB>     it's something named 'THUNK' (there are some build in Win95 for
 DB>     compatibility with old 16 bits apps). it was very hard stuff,
 DB>     impossible (IMHO) to make it with clipper :( )  
Thunking is indeed not the simplest thing to do, but if the 16-bit database +
business engine and the 32-bit user interface each are running in their own
process, the thunking part is done by the operating system. And with W95 and 
NT
MS has shown that they do know how to deal with thunking...
 DB>     -------->BUT i've heard that John Skelton will implement such
 DB>              call (16->32) in the next release aof Clip4Win.(?)
 DB>       ?:-/   That will allow you to call 32 bits *.dll like R&R
 DB>              (report maker) for instance) <------------
In that case you let your Clipper engine handle everything, and yes, you (or
Skelton) will have to deal with thunking yourself. I don't know R&R, but I've
fiddled with Crystal Reports, ReportSmith and ReportPrinter Pro (for Apollo),
but at the moment I prefer QuickReport. Not directly usable in Clipper (maybe
when Skelton dealt with this thunking?) but in Delphi or C++Builder it's a
breeze: no external programs or dll's to distribute, the possibility to work
with data that don't come out of your database directly but from e.g. a 
richedit
component, and all and all it really is quick. A lot faster than Crystal 
anyway.
Maybe ReportPrinter Pro is a little faster, but it's got far less options.
 DB>     It's perhaps possible to only make somme 'call' to external
 DB>     clipper module (exe) ? IMHO, it's possible, but complex  (too
 DB>     many small clipper *.exe, you need also to maintain a lot of
 DB>     temporary files for transmitting parameters for instance)
 DB>     that sounds to me like the (bad) (very) old basic ands
 DB>     its (ugly) RUN "C:\..." within a pgm :-)
You're thinking in DOS terms now. On a decent operating system more than one
program can run side by side, and can exchange information directly, without 
the
need for temporary files. Any real multitasking OS supports things like
semaphores (not 'semaphore files'), shared memory and pipes and/or messaging. 
No
spawning would be needed, because both tasks are running concurrently, 
watching
eachother...
 DB>    'pipe' are only well implemented on UNIX plateform (you can try
 DB>    LINUX :-)) ). halas, UNIX is not so easy (IMHO) to use as MS-DOS
 DB>    and even windows programming.
OS/2 handles them quite nicely too, and so does NetWare. But in a Windows
environment it's maybe smarter to look at the Windows API (messaging, OLE) 
nd
use these. But the general idea stays the same.
Clipper is a great xBASE development system for DOS, but both xBASE and
(character based) DOS are overhauled by (inter-)networking, client/server 
DBMS's
and GUI's like Windows. You can try to keep your Clipper code alive (e.g. 
ith
Clip4Win or with the foreground/background schedule I proposed), but it'll
always be a kludge...
 DB>    in conclusion, i think that if your custommers don't _really_
 DB>    insist to have a 'windows look & feel', you can continue to
 DB>    produce (good) old clipper *.exe in ms-dos mode.
Existing customers will not insist on a GUI, but new customers won't give a
blink at your character based application, even if it sings and dances for 
them.
This may not be true for all branches, but the great majority of the people
looking for a hotel property management system are looking for a 
indows-based
system. At the moment we can offer them a thoroughly tested Clipper version 
with
all bells and whistles one could ask for and a fresh Win32 version
(Delphi/InterBase) that at the moment has a lot less functionality than the
Clipper version, but looks a lot smarter. And the Win32 version sells 3 times 
as
fast as the Clipper version...
Regards,
Erik 
---
---------------