Clipper for Windows
Erik Christiansson
Wildhart
> Where can I download Clipper for Windows?
Eric,
Yours is a very common question - I face a similar quandary
that involves ClipWin: I can't decide whether to download
Clipper for Windows or purchase a date with Christie
Brinkley... - Both are immensely desirable prizes, and each
is equally unlikely.
Wildhart
______________________
My heart is wild; My soul is free... How did Bill Gates make a
slave out of ME???
Wildhart
>
> > Where can I download Clipper for Windows?
Erik,
Please excuse me for calling you Eric - I was carried away by my
personal blind fury about the fate of Clipper programmers... and
by passionate memories of Christie's ads. : )
If, by chance, you were asking where you could download a trial
version of the add on Clipper library Clip-4-Win, you have only to
go to http://www.clip4win.com/
Mind that you notice, Clip-4-Win is NOT the fabled, longed for
'Clipper for Windows' any more than CA Visual Objects was...
Clipper is/was a low-level high-level language that would allow
you to do simple things simply (like low-level languages do) and
also let you do complex things simply (the way DOS let you perform
complex operations like XCOPY) . Clipper responded to user input
from a single, simple, keyboard buffer handler - you could get
those keystrokes yourself via INKEY() or let READ use the
GETSYS(INKEY()) to organize them for you. BG's WinDoze sends
internal email to a C++ bureaucracy that requires you to create a
new bureau any time you want to do something 'different'... the
neat Clipper/DOS 'black box' functions have turned into profligate
self-replicating gibberish. The basic idea of the Win API is as
flawed as the idea that using 'system standard' DLLs stored in the
Windows\System directory... too much exposed system critical
code... too many contortions required to safely access and
reliably operate.
Example:
This is Clipper
SET COLOR TO W+/B,GR+/N,,N/BG
CLEAR SCREEN
__________________
This is Clip4Win (courtesy of Karl Nitschke via the Clip-4-Win
digest)
This is my revised code following your advice and what is
mentioned in the
MS SDK:
Inside your create method of MDIFrame class do this:
nProc1 := SubClassWindow(::oClient:hWnd, { |hWnd, nMsg,
nwParam,
nlParam| EraseClientBk(nProc1, hWnd, nMsg, nwParam, nlParam) },
WM_ERASEBKGND )
...
/* Control painting of client area background as per procedure
recommended in Windows SDK
*/
STATIC FUNCTION EraseClientBk (nProc, hWnd, nMsg, nwParam, nlParam
)
LOCAL hOldBrush
LOCAL hBrush
LOCAL aRect
IF nMsg == WM_ERASEBKGND
hBrush := GetStockObject(LTGRAY_BRUSH)
UnrealizeObject(hBrush)
hOldBrush := SelectObject(nwParam, hBrush)
aRect := GetClientRect(hWnd)
PatBlt(nwParam, aRect[W_LEFT], aRect[W_TOP], ;
aRect[W_RIGHT], aRect[W_BOTTOM], PATCOPY)
SelectObject(nwParam, hOldBrush)
RETURN ( 1 )
ENDIF
RETURN ( CallWindowProc(nProc, hWnd, nMsg, nwParam, nlParam) )
_________________________
I sadly rest My case.
Juergen Knauf
Erik Christiansson <e...@i.am> schrieb in im Newsbeitrag:
8agl7m$20d$1...@cubacola.tninet.se...
Jean Menten
> AT www.cavo.com
>
> > Where can I download Clipper for Windows?
>
Let me guess the next question:
Where can I find the crack :-))
GreetzzZZzz ,
Jean Menten
Will Chapman
"Erik Christiansson" <e...@i.am> wrote in message
news:8agl7m$20d$1...@cubacola.tninet.se...
Peter Alderliesten
>Where can I download Clipper for Windows?
If you're looking for Clipper compatibility and a learning curve that
isn't that steep, take a look at Xbase++ at www.alaska-software.com
Peter Alderliesten
Will Chapman
"Jean Menten" <jme...@glo.be> wrote in message
news:8ajd7b$knl$1...@trex.antw.online.be...
>
> > AT www.cavo.com
> >
> > > Where can I download Clipper for Windows?
> >
>
Boris Borzic
>Where can I download Clipper for Windows?
The best implementation of a "Clipper for Windows" so far is Xbase++
Please see my homepage for valuable Xbase++ links:
http://ourworld.compuserve.com/homepages/BBorzic
Best regards,
Boris Borzic
--
http://ourworld.compuserve.com/homepages/BBorzic
homepage of SQLExpress - the SQL/ODBC library for Xbase++
Jovko Vaporov
Erik Christiansson schrieb in Nachricht <8agl7m$20d$1...@cubacola.tninet.se>...
>Where can I download Clipper for Windows?
I use FiveWin 1.95 and I'm very sattisfied with it.
Try www.fivetech.com .
Al Acker
neutral here...but IMO Xbase++ is the closest thing to Clipper for
Windows I know of... hands down. ( if you require 32bit Windows )
_but_ if you want something better than Clipper for Windows ( full
32bit and written in xbase so you can still use your Clipper
knowledge) ... check out Visual dBASE. Most Clipper types I know that
have used both never return to Xbase++.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Peter Alderliesten <p.alder...@emergo-systems.nl> wrote in message
news:13rrcsckdd2s396ir...@4ax.com...
:
: >Where can I download Clipper for Windows?
:
: If you're looking for Clipper compatibility and a learning curve
john at clip-4-win dot com
wrote:
>Example:
>
>This is Clipper
>
>SET COLOR TO W+/B,GR+/N,,N/BG
>CLEAR SCREEN
>__________________
>
>This is Clip4Win
[snip: code]
So you give a simple piece of Clipper code that clears the screen
(incidentally removing any menu / form /etc), but for C4W you show an
MDI app (hardly equivalent to the DOS Clipper example) and wanting to
use a non-standard background for the MDI client. Please: be helpful
and reasonably fair.
Windows is very definitely not DOS, and GUIs behave very differently
to the way procedural DOS apps normally behave, so of course there are
some major changes needed. However, if you change a DOS Clipper to a
Windows Clipper app using Clip-4-Win and keep 70% of your code
(typically all your business logic and your favourite Clipper
add-ons), you've done two pretty major things:
1. rewritten only 30%, i.e. one third of the time and effort
2. avoided the huge learning curve of a new language (which is
especially hard when faced with the lurning curve for Windows at the
same time).
There's a detailed file about converting from DOS Clipper to Windows
on our web site (CONVERT.TXT - get CONVERT.ZIP) which anyone wanting
to convert should read, even if all it does is convince them not to
use C4W. <g>
John.
[Clip-4-Win == Clipper for Windows == my product; www.clip-4-win.com]
email: john at clip-4-win dot com [think about it!]
Randal Ferguson
And how does Visual dBase stack up against Delphi? I tried VdB (6.x
version?) and didn't like it too much, what has changed?
And where can I find an example of an xBase app that's ready for
widespread commercial distribution?
Thanks,
Randal Ferguson
MAppell917
>Subject: Re: Clipper for Windows
>From: Randal Ferguson 7122...@compuserve.com
>Date: 3/15/00 9:51 PM Pacific Standard Time
>Message-id: <38D076...@compuserve.com>
>
>Al,
>
>And how does Visual dBase stack up against Delphi? I tried VdB (6.x
>version?) and didn't like it too much, what has changed?
>
>And where can I find an example of an xBase app that's ready for
>widespread commercial distribution?
>
>Thanks,
>Randal Ferguson
>
Mike
Al Acker
different product <G>
You can get VdB samples up on their web site http://dbase2000.com
or news.dbase2000.com I've never seen a commercial Xbase++ app.
VDB / Delphi
The IDE's are very close to the same ( both were created by Borland )
... one uses Pascal as it's native language ( Delphi ) the other uses
xbase ( VdB ). There's a lot of differences above that... IE VdB is
more a data language than Pascal Delphi.... They're both great...
But if you prefer an xbase language, look at VdB.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Randal Ferguson <7122...@compuserve.com> wrote in message
news:38D076...@compuserve.com...
: Al,
:
: And how does Visual dBase stack up against Delphi? I tried VdB (6.x
: version?) and didn't like it too much, what has changed?
:
: And where can I find an example of an xBase app that's ready for
: widespread commercial distribution?
:
: Thanks,
: Randal Ferguson
:
:
Al Acker
VFP puts code in all kinds of different places and you have to go hunt
for it. Also it's dog slow when you load up a lot of controls on one
dialog.
Also ( IMO ) VFP doesn't handle it's two way tools as nice as VdB
does. There's a few other things I don't like about VFP but it deals
with some minor details of data pathing that's kind of crude when you
go to deploy your apps on client boxes.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
MAppell917 <mappe...@aol.com> wrote in message
news:20000315235133...@ng-cu1.aol.com...
: How do they stack up against Visual FoxPro?
:
: >Subject: Re: Clipper for Windows
: >From: Randal Ferguson 7122...@compuserve.com
: >Date: 3/15/00 9:51 PM Pacific Standard Time
: >Message-id: <38D076...@compuserve.com>
: >
: >Al,
: >
: >And how does Visual dBase stack up against Delphi? I tried VdB
(6.x
: >version?) and didn't like it too much, what has changed?
: >
: >And where can I find an example of an xBase app that's ready for
: >widespread commercial distribution?
: >
: >Thanks,
: >Randal Ferguson
: >
:
:
: Mike
Karl Nitschke
Clipper was NEVER a low-level high level language... Maybe C++
is/was...
Anyone who only programmed the WIN API directly (in this day and age)
would be extremely weird... That's why Clip4Win comes with a whole set
of OOP classes so you can avoid the API most of the time.
The example you quoted from me changes a standard behaviour of the
Windows MDI class in order to get it to do something that the
designers of Windows probably never intended/wanted it to do.
In ANY Windows development tool that would either be (1) impossible or
(2) just as hard to implement as the example you quoted using Clip4Win
code.
Karl
On Sun, 12 Mar 2000 13:37:27 -0600, Wildhart <wil...@My-deja.com>
wrote:
>Clipper is/was a low-level high-level language that would allow
>you to do simple things simply (like low-level languages do) and
>also let you do complex things simply (the way DOS let you perform
>complex operations like XCOPY) . Clipper responded to user input
>from a single, simple, keyboard buffer handler - you could get
>those keystrokes yourself via INKEY() or let READ use the
>GETSYS(INKEY()) to organize them for you. BG's WinDoze sends
>internal email to a C++ bureaucracy that requires you to create a
>new bureau any time you want to do something 'different'... the
>neat Clipper/DOS 'black box' functions have turned into profligate
>self-replicating gibberish. The basic idea of the Win API is as
>flawed as the idea that using 'system standard' DLLs stored in the
>Windows\System directory... too much exposed system critical
>code... too many contortions required to safely access and
>reliably operate.
>
>Example:
>
>This is Clipper
>
>SET COLOR TO W+/B,GR+/N,,N/BG
>CLEAR SCREEN
>__________________
>
>This is Clip4Win (courtesy of Karl Nitschke via the Clip-4-Win
>digest)
>
...
Wildhart
bother. If it makes a difference, I was not singling out Clip-4-Win's
method of handling the Windows dilemma... I did point the guy towards the
Clip-4-Win website, after all. : )
As to the fairness of the comparison of those code fragments - if the
object is to change the color of the screen (window) - both sets of code
show what is required to change the color of the screen background. In
DOS, I clear the screen to the new color and replace any elements that
were there before... In Windows, I must destroy the window, call a
special MDI window class that has been modified to accept a nonstandard
background color to recreate the window, and repaint with any elements
that were there before. Certainly Windows is more complex than DOS, but
having to create this kind of capability because it has been omitted from
the standard library functionality is unacceptable.
My problem is that no language has solved the puzzle of making the
unfortunately misconceived Win API as easy to program and as reliable as
Clipper made DOS. I have spent the last five months testing products that
promise to port my Clipper code to Windows... if I'm willing to rewrite
each app from scratch and rethink my program flow completely. If and when
I choose one it will be because the product's developer(s) have placed my
program's need to operate simply, flexibly, and reliably ahead of blind
conformity to the Windows API bureaucracy. If that means the developer
has hidden the contortions required by Windows to do things that were
simple in DOS, I wouldn't mind that at all.
We can accept the designed-by-committee "framework" of Windows and join
the ranks of those who work very hard and/or very long to accomplish
things that Clipper did so easily or we can hold out for a GUI language
that does a better job of controlling the Windows beast.
Gates has hundreds of part time contract workers programming Microsoft
apps - a few of them probably see the Windows API as just another video
game to play and defeat, but I wonder how many of them spend most of the
day scratching their heads in befuddlement.
Wildhart
john at clip-4-win dot com wrote:
> On Sun, 12 Mar 2000 13:37:27 -0600, Wildhart <wil...@My-deja.com>
> wrote:
>
> >Example:
> >
> >This is Clipper
> >
> >SET COLOR TO W+/B,GR+/N,,N/BG
> >CLEAR SCREEN
> >__________________
> >
> >This is Clip4Win
> [snip: code]
>
> So you give a simple piece of Clipper code that clears the screen
> (incidentally removing any menu / form /etc), but for C4W you show an
> MDI app (hardly equivalent to the DOS Clipper example) and wanting to
> use a non-standard background for the MDI client. Please: be helpful
> and reasonably fair.
>
Hugh Lokey
wrote:
>Wildhart,
>
>Clipper was NEVER a low-level high level language... Maybe C++
>is/was...
Does that not depend on ones definition? Clipper does provide low-level
file stuff and with a bit of work one can manipulate bits - then switch to
writing classes with multiple inheritance ( with TopClass of course )<BG>.
>
>Anyone who only programmed the WIN API directly (in this day and age)
>would be extremely weird... That's why Clip4Win comes with a whole set
>of OOP classes so you can avoid the API most of the time.
Then color me with that weird brush - I routinely work at the API level with
both Clip-4-Win and VO 2.xx - the folks that write those nice classes for
you do so as well. Now is the case of Clip-4-Win, John provides the source
code to those classes so you can see and change what is going on - with
VO you have to buy the SDK to get the source but I think you are safer
off by avoiding their classes altogether. VO 2.xx makes working at the
Win API level very very easy..
>The example you quoted from me changes a standard behaviour of the
>Windows MDI class in order to get it to do something that the
>designers of Windows probably never intended/wanted it to do.
I would not go so far as to call Windows MDI implementation a class and
would not recommend creating apps with weird/non-standard UI elements
either. In the last 6+ years you would not belive the number of Clip-4-Win
users who have asked me how to do some horrible Clipper like thing in
Windows<BG>.
It continues to amaze me that to this day, over 6 years after Clip-4-Win hit the
market, Clipper "programmers" out there are still just getting to the point
where they realize that it might be time to try their hand at Windows
programming and/or porting their old Clipper apps to Windows. Time has
shown that there is no more stable/bug free way to do it than Clip-4-Win.
Just my 4 cents worth ( inflation you know )<G>.
Wildhart
Because Clipper made it possible to link Assembler and C addins, it is
effectively low level when supplemented by third party libraries. Since
Clip-4-Win is Clipper, Clip-4-Win enjoys the best of both worlds - the
linkable low level third party function and the inscrutable WinAPI. The
modularity and reusability of functional code has been grossly
underestimated and maligned, in my opinion.
The irony of needing to use a subclass - with the requirement for an
additional handle - every time the programmer wants to deviate from basic
functionality in a window impressed me when I saw your example... as well
as the need to coach individual programmers on the undocumented details.
I agree with you completely about the reasons for that MDI code and about
the difficulty of doing screen io using the tools Microsoft has provided.
I read somewhere recently an analogy that went something like: programming
with Clipper was like building a house with all your tools scattered
around you ready for immediate use and programming through WinAPI was like
having all those tools in a box with a small hole in the top just big
enough to remove one tool at a time. It is to Clip-4-Win's credit that the
workaround is possible, but better, more flexible, automatic and
persistent window control needs to become a standard part of Windows
Clipper/xbase libraries for everyone's sake.
Wildhart
Karl Nitschke wrote:
> Wildhart,
>
> Clipper was NEVER a low-level high level language... Maybe C++
> is/was...
>
> Anyone who only programmed the WIN API directly (in this day and age)
> would be extremely weird... That's why Clip4Win comes with a whole set
> of OOP classes so you can avoid the API most of the time.
>
> The example you quoted from me changes a standard behaviour of the
> Windows MDI class in order to get it to do something that the
> designers of Windows probably never intended/wanted it to do.
>
> In ANY Windows development tool that would either be (1) impossible or
> (2) just as hard to implement as the example you quoted using Clip4Win
> code.
>
> Karl
>
> On Sun, 12 Mar 2000 13:37:27 -0600, Wildhart <wil...@My-deja.com>
> wrote:
>
> >Clipper is/was a low-level high-level language that would allow
> >you to do simple things simply (like low-level languages do) and
> >also let you do complex things simply (the way DOS let you perform
> >complex operations like XCOPY) . Clipper responded to user input
> >from a single, simple, keyboard buffer handler - you could get
> >those keystrokes yourself via INKEY() or let READ use the
> >GETSYS(INKEY()) to organize them for you. BG's WinDoze sends
> >internal email to a C++ bureaucracy that requires you to create a
> >new bureau any time you want to do something 'different'... the
> >neat Clipper/DOS 'black box' functions have turned into profligate
> >self-replicating gibberish. The basic idea of the Win API is as
> >flawed as the idea that using 'system standard' DLLs stored in the
> >Windows\System directory... too much exposed system critical
> >code... too many contortions required to safely access and
> >reliably operate.
> >
> >Example:
> >
> >This is Clipper
> >
> >SET COLOR TO W+/B,GR+/N,,N/BG
> >CLEAR SCREEN
> >__________________
> >
Randal Ferguson
>
> VdB never had a version 6. Maybe you're thinking of VB.... kinda
> different product <G>
No, I'm not thinking of VB, perhaps it was 5.5, whichever version it was
it wasn't ready for prime time in my opinion which is why I asked.
>I've never seen a commercial Xbase++ app.
I've never even seen any kind of production app done in xBase++...
Thanks,
Randal Ferguson
Wildhart
We don't always want to do 'horrible Clipper like things' to Windows... just
sometimes. ; )
We do want to have the power to do anything we could do to the screen (window) in
Clipper if we need to - without having to spend all day trying to figure out how to
make it work... and without having to expend system resources unnecessarily.
Some of us programmed mainly for a closed system (a company that was committed to
DOS) so didn't need to even consider moving those apps to Windows - how ever ugly we
thought the screens were. Time passes though... and some of us get laid off and
find there aren't a great number of openings in our prior field of employment (paint
manufacturing quality management), so we think about selling database systems
created with industry insight - to companies that use Windows.
I agree that Clip-4-Win is a capable makeover for a classic database manager. I
just can't believe you guys (talking about all the Windows xbase variants - not just
Clip-4-Win) are willing to work that hard to beat all those little 'controls' into
shape... day in and day out!
Wildhart
Hugh Lokey wrote:
> On Thu, 16 Mar 2000 12:36:53 GMT, SendJun...@hotmail.com (Karl Nitschke)
> wrote:
>
> >Wildhart,
> >
> >Clipper was NEVER a low-level high level language... Maybe C++
> >is/was...
>
> Does that not depend on ones definition? Clipper does provide low-level
> file stuff and with a bit of work one can manipulate bits - then switch to
> writing classes with multiple inheritance ( with TopClass of course )<BG>.
> >
> >Anyone who only programmed the WIN API directly (in this day and age)
> >would be extremely weird... That's why Clip4Win comes with a whole set
> >of OOP classes so you can avoid the API most of the time.
>
> Then color me with that weird brush - I routinely work at the API level with
> both Clip-4-Win and VO 2.xx - the folks that write those nice classes for
> you do so as well. Now is the case of Clip-4-Win, John provides the source
> code to those classes so you can see and change what is going on - with
> VO you have to buy the SDK to get the source but I think you are safer
> off by avoiding their classes altogether. VO 2.xx makes working at the
> Win API level very very easy..
>
> >The example you quoted from me changes a standard behaviour of the
> >Windows MDI class in order to get it to do something that the
> >designers of Windows probably never intended/wanted it to do.
>
Hugh Lokey
>Hugh,
>
>We don't always want to do 'horrible Clipper like things' to Windows... just
>sometimes. ; )
And Mary Kay likes to paint cars a horrible pink sometimes<g>.
>
>We do want to have the power to do anything we could do to the screen (window) in
>Clipper if we need to - without having to spend all day trying to figure out how to
>make it work... and without having to expend system resources unnecessarily.
I routinely use Clippper/Clip-4-Win, VO, VB, C/C+ and Java and NONE of them
let you do ANYTHING to the screen. When you want to stray from the recommended
or standard path then you have to spill some sweat.
>
>Some of us programmed mainly for a closed system (a company that was committed to
>DOS) so didn't need to even consider moving those apps to Windows - how ever ugly we
>thought the screens were. Time passes though... and some of us get laid off and
>find there aren't a great number of openings in our prior field of employment (paint
>manufacturing quality management), so we think about selling database systems
>created with industry insight - to companies that use Windows.
Sounds like a fine goal - now all you have to do is to pick a development tool
or tools and go to work - none of them will be perfect but some are better than
others.
>
>I agree that Clip-4-Win is a capable makeover for a classic database manager. I
>just can't believe you guys (talking about all the Windows xbase variants - not just
>Clip-4-Win) are willing to work that hard to beat all those little 'controls' into
>shape... day in and day out!
I have not had to "beat a control into shape" in a long, long time - I tend to
stick to the "standard" when it comes to UI.
Some folks will never be satisfied with either application development
environments nor the applications created with them until we reach
that "Holy Grail" where there is jus one button that says "Do it" <BG>.
Boris Borzic
>I've never even seen any kind of production app done in xBase++...
Check out my homepage at: http://ourworld.compuserve.com/homepages/BBorzic
for a link to a sample web app using Xbase++. This app is approx 6MB of
source and was originally converted from Clipper 5.2. It is currently used
by many warehouses including the following Internet stores:
http://www.chapters.ca
http://www.bigwords.com
http://www.indigo.ca
Cheers,
Al Acker
You still around and using C4W.... amazing! < G >. How you doing
guy? I just posted a message over on my conference that you'd love to
read.... it deals with "third world programming" .... you'd get a kick
out of it.
Take care my friend.... good to see you're still around!
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Karl Nitschke <SendJun...@hotmail.com> wrote in message
news:38d0d3b9...@News.compuserve.com...
: Wildhart,
:
: Clipper was NEVER a low-level high level language... Maybe C++
: is/was...
:
: Anyone who only programmed the WIN API directly (in this day and
age)
: would be extremely weird... That's why Clip4Win comes with a whole
set
: of OOP classes so you can avoid the API most of the time.
:
: The example you quoted from me changes a standard behaviour of the
: Windows MDI class in order to get it to do something that the
: designers of Windows probably never intended/wanted it to do.
:
: In ANY Windows development tool that would either be (1) impossible
:
Al Acker
Go to my site.... join the conference.... then go to the Visual dBASE
section and read the thread called "converting" .... it deals with
Clipper types looking to get into windows and wanting to know the best
way to go. I just posted a message that, among other things, deals
with "third world" programming... I think you'd get a kick out of it.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Wildhart <wil...@My-deja.com> wrote in message
news:38D0F377...@My-deja.com...
: Hugh,
:
: We don't always want to do 'horrible Clipper like things' to
Windows... just
: sometimes. ; )
:
: We do want to have the power to do anything we could do to the
screen (window) in
: Clipper if we need to - without having to spend all day trying to
figure out how to
: make it work... and without having to expend system resources
unnecessarily.
:
: Some of us programmed mainly for a closed system (a company that was
committed to
: DOS) so didn't need to even consider moving those apps to Windows -
how ever ugly we
: thought the screens were. Time passes though... and some of us get
laid off and
: find there aren't a great number of openings in our prior field of
employment (paint
: manufacturing quality management), so we think about selling
database systems
: created with industry insight - to companies that use Windows.
:
: I agree that Clip-4-Win is a capable makeover for a classic database
manager. I
: just can't believe you guys (talking about all the Windows xbase
variants - not just
: Clip-4-Win) are willing to work that hard to beat all those little
'controls' into
: shape... day in and day out!
:
: Wildhart
:
:
: Hugh Lokey wrote:
:
: > On Thu, 16 Mar 2000 12:36:53 GMT, SendJun...@hotmail.com (Karl
Nitschke)
: > wrote:
: >
: > >Wildhart,
: > >
: > >Clipper was NEVER a low-level high level language... Maybe C++
: > >is/was...
: >
: > Does that not depend on ones definition? Clipper does provide
low-level
: > file stuff and with a bit of work one can manipulate bits - then
switch to
: > writing classes with multiple inheritance ( with TopClass of
course )<BG>.
: > >
: > >Anyone who only programmed the WIN API directly (in this day and
age)
: > >would be extremely weird... That's why Clip4Win comes with a
whole set
: > >of OOP classes so you can avoid the API most of the time.
: >
: > Then color me with that weird brush - I routinely work at the API
level with
: > both Clip-4-Win and VO 2.xx - the folks that write those nice
classes for
: > you do so as well. Now is the case of Clip-4-Win, John provides
the source
: > code to those classes so you can see and change what is going on -
with
: > VO you have to buy the SDK to get the source but I think you are
safer
: > off by avoiding their classes altogether. VO 2.xx makes working
at the
: > Win API level very very easy..
: >
: > >The example you quoted from me changes a standard behaviour of
the
: > >Windows MDI class in order to get it to do something that the
: > >designers of Windows probably never intended/wanted it to do.
: >
: > I would not go so far as to call Windows MDI implementation a
:
Al Acker
either one of them.... they were not up to speed ( IMO ). But vdb 7.5
is an entire different animal.... check it out if you have time...
it's as close to an xbase version of Delphi as I've seen yet.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Randal Ferguson <7122...@compuserve.com> wrote in message
news:38D10B...@compuserve.com...
: Al Acker wrote:
: >
: > VdB never had a version 6. Maybe you're thinking of VB.... kinda
: > different product <G>
:
: No, I'm not thinking of VB, perhaps it was 5.5, whichever version it
was
: it wasn't ready for prime time in my opinion which is why I asked.
:
: >I've never seen a commercial Xbase++ app.
:
: I've never even seen any kind of production app done in xBase++...
:
: Thanks,
: Randal Ferguson
Al Acker
I think he was talking more of the "traditional" application were you
have the exe sitting on the workstation and the data is either local
or on a network and the program is sold "on the street". But I could
be wrong. BTW, we're still waiting for Alaska to deliver an ADSDBE so
we can do timing tests for a review.... so far no go <G> I think you
made a good move with your product.... I doubt Alaska will ever
duplicate your efforts.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Boris Borzic <bbo...@compuserve.com> wrote in message
news:8EF9614E6...@207.107.108.8...
:
: >I've never even seen any kind of production app done in xBase++...
:
: Check out my homepage at:
Wildhart
that Clipper requires for screen control - I want a 'Let Me Do It' button! The fact that
such an animal isn't available in any of the major Windows programming metaphors (from
your reference list) is what this thread has been lamenting. ; )
I'll let the 'Mary Kay' aspersion slide, since you're not familiar with my extensive
artistic sensibilities.
Wildhart
Wildhart
I'll take a look. I've really missed the comparitive reviews I used to
get from the Databased Advisor and Clipper Advisor magazines. As you can
tell from my software collection (in the 'Future' thread) shopping has
always been my personal vice.
I follow the comp.databases.visual-dbase newsgroup, but I get the
impression that they're struggling to get back into the game a little too
late... I hope that's not true. I also follow
comp.language.visual-objects, where they're visably (and justifiably)
proud of having beaten the steep oop learning curve and sad about the lack
of support their efforts get from VO's owner. Maybe the Visual Objects
guys need to do a buy out from under CA the way dBASE programmers did with
Borland.
The really enthusiastic, confidant, classical Clipper-like attitude is in
the Delphi groups. Those lucky stiffs have everything going their way -
as if there wasn't anything THEIR development language can't do... they
talk about Delphi the same way Rick Spence used to talk about Clipper...
"Yes, it can!"
Wildhart
Al Acker wrote:
> Wildhart,
>
> Go to my site.... join the conference.... then go to the Visual dBASE
> section and read the thread called "converting" .... it deals with
> Clipper types looking to get into windows and wanting to know the best
> way to go. I just posted a message that, among other things, deals
> with "third world" programming... I think you'd get a kick out of it.
>
Al Acker
(now) works and it's flexible enough for Clipper types. There's a lot
of people left around here that still love the language and will be
hell bent not to learn Pascal. <G>. I think this is where dBASE will
win out. CA will NEVER sell anything... they'd rather trash it...
that's a proven fact. So the VO types are in a big hole ( and they
know it ).
We'll be doing a lot of reviews and user feedback in the ezine this
year.... time to tell it like it is and not hold back anything < G >.
Developers need answers right now... not promises.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Wildhart <wil...@My-deja.com> wrote in message
news:38D19B0F...@My-deja.com...
: Thanks, Al.
:
Dave Pearson
> The really enthusiastic, confidant, classical Clipper-like attitude is in
> the Delphi groups. Those lucky stiffs have everything going their way - as
> if there wasn't anything THEIR development language can't do... they talk
> about Delphi the same way Rick Spence used to talk about Clipper... "Yes,
> it can!"
Actually, the last I saw, that's pretty much how Rick talked about Delphi (I
and others I work with got a crash course in Delphi off him a couple of
years back, highly recommended).
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.hagbard.demon.co.uk/ | eg - Norton Guide reader for Linux.
http://www.acemake.com/hagbard/ | weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.
Dave Pearson
> We'll be doing a lot of reviews and user feedback in the ezine this
> year.... time to tell it like it is and not hold back anything < G >.
> Developers need answers right now... not promises.
I've not looked at what the ezine has to offer for quite some time so I just
popped over. According to <URL:http://www.thexbasefiles.com/tocd.htm>, which
is the link off the front page for "What is in our next issue" (I think
you're missing a question mark there BTW), the next issue is your "Premier
Issue".
I get exactly the same page when I look at the contents of the current
issue.
So, according to your site there has only ever been and only ever will be
one issue of The Xbase Files.
I kind of find that hard to believe. <g>
Jamie Macleod
"Al Acker" <aac...@thexbasefiles.com> wrote in message
news:8aslh8$65s$1...@ssauraaa-i-1.production.compuserve.com...
> I think dBASE got sold to Alan just in time.... it's a good base... it
> (now) works and it's flexible enough for Clipper types. There's a lot
> of people left around here that still love the language and will be
> hell bent not to learn Pascal. <G>. I think this is where dBASE will
> win out. CA will NEVER sell anything... they'd rather trash it...
> that's a proven fact. So the VO types are in a big hole ( and they
> know it ).
>
It must be a big hole. I can still see the light.
Jamie
Al Acker
Yes, I'd agree with you on that! <GGG> We're working on the site and
it looks like we have some links confused. Actually, we're popping
out issue number 6 over this weekend and will complete our first year.
The average page size per issue has been around 160 so that's a few
pages worth of information.
We're going to put in a little applet on the site in the next couple
days were you can view the TOC of each issue.... since we sell back
issues also.
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Dave Pearson <davep...@davep.org> wrote in message
news:slrn8d3s1m.1...@hagbard.demon.co.uk...
: On Fri, 17 Mar 2000 00:05:38 -0700, Al Acker
Al Acker
Al
--
Al Acker, Editor
The Xbase Files Magazine
http://www.thexbasefiles.com
Jamie Macleod <bubam...@yahoo.com> wrote in message
news:38d24...@news.cadvision.com...
:
: "Al Acker" <aac...@thexbasefiles.com> wrote in message
:
:
Gordon Hamm
> Borland.
>
> the Delphi groups. Those lucky stiffs have everything going their way -
> as if there wasn't anything THEIR development language can't do... they
> talk about Delphi the same way Rick Spence used to talk about Clipper...
> "Yes, it can!"
>
That's what I feel about Delphi. It reminds me of Clipper in that there is a
tool for everthing under the sun. In fact, the DBF stuff is a snap in
Delphi using one of the several BDE replacements. Check out
Http://Delphipages.com and http://www.torry.ru to see how many tools there
are for Delphi. There is piles of support for Delphi too. Last count there
was over 50 specialized Delphi Newsgroups, from TCP/IP to Graphics to
Desktop databases. You name it, some one has an answer or sample code.
Gordon
Gary Stark
> >We don't always want to do 'horrible Clipper like things' to Windows... just
> >sometimes. ; )
>
> And Mary Kay likes to paint cars a horrible pink sometimes<g>.
Actually, IME Mary Kay likes to paint horrible cars a horrible pink sometimes ... <gbg>
--
g.
Gary Stark
gst...@RedbacksWeb.com
http://RedbacksWeb.com