Migrate Clipper/Clip4Win

I know this has been discussed over the years, but I would like some
current feedback on opinions on the subject. I have an application
that has these features:

Menu driven
Ntx indexes
Clipper 5.2d
Clip-4-Win
Lots of Wbrowse screens
Multi-user (netuse, addrec etc from locks.prg)

What route would people recommend?

The answer wants to be inherently 32 bit Windows (unlike the 16 bit
appearance of Clip-4-Win). Ideally we want to be able to port to Linux
at a later stage. Must be multi-user.

I have some exposure to C and Pascal and feel tempted by Delphi, but
ulimately need something that will convert 32 bits quickly.

Any comments appreciated

Reece,

Depends on what you want in the end.

The most "common" Clipper feel if you want to go open source is
obviously (x)Harbour, which also would allow you Linux.

Other than that, since you want to go 32 bit:
1. CA-Visual Objects - although I believe although it will be still
around for some time not the best option to go for if you now converting.
2. Vulcan.NET - You can call this the Visual Objects on steroids. True
..NET applications with the familiar syntax of Clipper and VO. Dbf and
SQL interfaces and you have all the .NET class libraries at hand to make
use of.

I had a look at (x)Harbour, but maybe I was at that time already too
deeply involved with VO, but I battled to get going.

Currently I am using Vulcan.NET so you know what I would
recommend...<VBG> A 60 day evaluation version at
http://www.govulcan.net. Integrates into Visual Studio with Intelisense
support. There is also an IDE at the same site (VIDE) that are 100%
Vulcan.NET code as an alternative to Visual Studio.

So if you feel you want to keep the Clipper feel I would plunge straight
into Vulcan.NET. Even Al Acker, old Clipper guru that went Delphi and
C#, are now a converted Vulcan.NET user... Obviously others will differ
and advise differently.

HTH,

Johan Nel
Pretoria, South Africa.

Reece wrote:
> I know this has been discussed over the years, but I would like some
> current feedback on opinions on the subject. I have an application
> that has these features:
>
> Menu driven
> Ntx indexes
> Clipper 5.2d
> Clip-4-Win
> Lots of Wbrowse screens
> Multi-user (netuse, addrec etc from locks.prg)
>
> What route would people recommend?
>
> The answer wants to be inherently 32 bit Windows (unlike the 16 bit
> appearance of Clip-4-Win). Ideally we want to be able to port to Linux
> at a later stage. Must be multi-user.
>
> I have some exposure to C and Pascal and feel tempted by Delphi, but
> ulimately need something that will convert 32 bits quickly.
>
> Any comments appreciated

Dear Reece:

On Apr 3, 8:20*am, Reece <x...@bevanweb.co.uk> wrote:
> I know this has been discussed over the years,
> but I would like some current feedback on
> opinions on the subject. I have an application
> that has these features:
>
> Menu driven
> Ntx indexes

Either go to mutli-tag indexes and CDX, but better still SQL / server.

> Clipper 5.2d

> Clip-4-Win
> Lots of Wbrowse screens

OK, so you already have some GUI-fication. Good.

> Multi-user (netuse, addrec etc from locks.prg)
>
> What route would people recommend?
>
> The answer wants to be inherently 32 bit
> Windows

(x)Harbour does 32-bit or 64-bit WinDoze and Linux.

> (unlike the 16 bit appearance of Clip-4-Win).
> Ideally we want to be able to port to Linux
> at a later stage. Must be multi-user.

(x)Harbour.

> I have some exposure to C and Pascal and
> feel tempted by Delphi, but ulimately need
> something that will convert 32 bits quickly.
>
> Any comments appreciated

(x)Harbour, and choose either Hwgui or Minigui. I'd add that xHarbour
has its own newsgroup at comp.lang.xharbour.

David A. Smith
(ps: no I don't own stock, they just saved my butt on a non-GUI
programming project.)

> For a Clip-4-Win replacement you may want to look at WinDock - it is
> Clip4Win compatible library for [x]Harbour.

Oops, here's the link:

http://www.roessler-software.de/e195...index_ger.html

Ron

On Apr 5, 2:54*am, "Ron Pinkas" <Ron.Pinkas_remove_th...@xHarbour.com>
wrote:
> > For a Clip-4-Win replacement you may want to look at WinDock - it is
> > Clip4Win compatible library for [x]Harbour.
>
> Oops, here's the link:
>
> * *http://www.roessler-software.de/e195...index_ger.html
>
> Ron


Dear David, Johan and Ron

Thank you all for your replies.

Two more questions if I may:

Is Advantage Database Server (from Sybase) a good idea/necessary/
irrelevant? I ask this considering I know some SQL as well as having a
decade-plus of Clipper experience. (Johan, I see Vulcan is DBF/SQL.)

I have an application in Clipper/Clip-4-Win which I am considering
rewriting in whichever language I pick. This would be a large project
for me as a one-man band, so I hope to only change half of it: either
the GUI or the database commands/functions. The ability to link into
other databases at a later date would be good. Different clients have
different types of technology, including Sage and Access. I regard
Access as flaky, but the ability to look into its files would be
handy. So the question is, how would xHarbour or Vulcan cope with,
say, Access files?

Reece Bevan

UK

Hi Reece,

> Is Advantage Database Server (from Sybase) a good idea/necessary/
> irrelevant? I ask this considering I know some SQL as well as having a
> decade-plus of Clipper experience. (Johan, I see Vulcan is DBF/SQL.)

ADS is available for both Vulcan and xHarbour.
Vulcan is the product of GrafX who took over the development of Visual
Objects under license from CA. A "transporter" was developed to migrate
Visual Objects code to Vulcan. In general, xHarbour, VO and Vulcan
provide native DBF support.

> I have an application in Clipper/Clip-4-Win which I am considering
> rewriting in whichever language I pick. This would be a large project
> for me as a one-man band, so I hope to only change half of it: either
> the GUI or the database commands/functions. The ability to link into
> other databases at a later date would be good. Different clients have
> different types of technology, including Sage and Access. I regard
> Access as flaky, but the ability to look into its files would be
> handy. So the question is, how would xHarbour or Vulcan cope with,
> say, Access files?

I agree with you, take it step by step. Whether you consider xHarbour
or Vulcan as your language of preference, they will both provide you
with the necessary tools to only have to rewrite your GUI as a start.
Only difference would be that VO/Vulcan provide strict typing of
variables with obvious speed improvements.

Somebody with more knowledge of xHarbour needs to answer your question
regarding SQL databases, but yes it is available.

Vulcan surely does allow them, it provides ODBC, OleDB and native driver
support, rember it is a 100% .NET language, so any class library
available in the .NET framework 1.0 upto 3.5 is available to use inside
of your Vulcan applications.

I use Vulcan to access DBF (native support), MS-Access, Oracle (via
OleDB) and PostgreSQL (through their native Npgsql.dll) as an example.
Other Vulcan developers that I know have applications interfacing to all
the MS products, MySQL etc.

As an example (Vulcan code):
USING Npgsql // The PostgreSQL .NET driver
FUNCTION Start() AS VOID
LOCAL oConn AS NpgsqlConnection
LOCAL oComm AS NpgsqlCommand
LOCAL oRead AS NpgsqlDataReader
LOCAL nCol AS INT
oConn := NpgsqlConnection{<connection string>}
oComm := NpgsqlCommand{"select * from customer", oConn}
oConn:Open()
oRead := oComm:ExecuteReader()
WHILE oRead:Read()
FOR nCol := 0 UPTO oRead:FieldCount - 1 // .NET Lists are 0 based
? nCol, oRead:GetName(nCol), oRead:GetValue(nCol)
NEXT
ENDDO
oConn:Close()
RETURN

If you do go Vulcan/Visual Objects you might consider rather using the
DbServer classes instead of the Functional versions of Clipper DBF
support etc.

FUNCTION Start() AS VOID
LOCAL oDbServer AS DbServer
LOCAL nCol AS INT
oDbServer := ;
DbServer{"c:\myapp\dbf\customer.dbf", <rest of parameters>}
WHILE !oDbServer:Eof
FOR nCol := 1 UPTO oDbServer:FCount
? nCol - 1, oDbServer:FieldName(nCol), oDbServer:FieldGet(nCol)
NEXT
oDbServer:Skip()
ENDDO
oDbServer:Close()
RETURN

HTH,

Johan Nel
Pretoria, South Africa.

Thanks everybody for your help. I have almost decided to go with (x)
Harbour and will go over to their newsgroup to contnue this.

N:dlzc D:aol T:com (dlzc) wrote:

> Works on Linux? No.

Check out http://www.mono-project.com/Main_Page.

Regards
Alex

On Apr 6, 6:18*am, Alex Strickland <s...@mweb.co.za> wrote:
> N:dlzcD:aol T:com (dlzc) wrote:
>
> > > ... .NET ...

> > Works on Linux? *No.
>
> Check out
http://www.mono-project.com/Main_Page.

I was wondering how M$ was going to keep .NET confined to their
control...

David A. Smith

David,

If you were interested in following all technologies you would have
known that M$ did not want to keep it to themselves, otherwise why is
the JIT-Compiler(Just In Time) and Intermediate Language so well
documented? Or for that matter having a product like Reflector that
could open any .NET exe/dll and display the code in your programming
language of choice (VB, C++, Delphi, C# and Vulcan)? Sorry no
clipper/xHarbour there...

Johan

> I was wondering how M$ was going to keep .NET confined to their
> control...
>
> David A. Smith

Dear Johan Nel:

On Apr 6, 7:09*am, Johan Nel <johan555.nel...@xsinet555.co.za> wrote:
....
> > I was wondering how M$ was going to keep .NET
> > confined to their control...

> If you were interested in following all
> technologies you would have known that M$ did
> not want to keep it to themselves, otherwise
> why is the JIT-Compiler(Just In Time) and
> Intermediate Language so well documented?

Because the documentation had a copyright on it.

>*Or for that matter having a product like
> Reflector that could open any .NET exe/dll
> and display the code in your programming
> language of choice (VB, C++, Delphi, C# and
> Vulcan)? *Sorry no clipper/xHarbour there...

(x)Harbour comes out as C, so there is some hope of viewing the result
from the (pre)compiler, with recognizeable function calls (in most
cases).

I not as enamoured of the "latest and greatest" in languages as you
seem to be. The lion's share of the people I deal with want to do
business with minimal changes, WinDoze prevents that, and "bells and
whistles" only serve to slow them down. But since Reece has already
implemented windowing, then his client base is used to those "bells
and whistles".

Thanks for the dialog...

David A. Smith

David,


> Thanks for the dialog...
Pleasure

Johan

Hello Reece

> Menu driven
> Ntx indexes
> Clipper 5.2d
> Clip-4-Win
> Lots of Wbrowse screens
> Multi-user (netuse, addrec etc from locks.prg)
>
> What route would people recommend?
>
> The answer wants to be inherently 32 bit Windows (unlike the 16 bit
> appearance of Clip-4-Win). Ideally we want to be able to port to Linux
> at a later stage. Must be multi-user.

This is just to inform the group about ongoing development of
GUI and CONSOLE user interface based on QT ( http://www.qtsoftware.com )
which will allow your Clipper code to be run as is on any platform
out-of-the-box with native look-and-feel.

Please refer to Harbour Developers-List at
http://www.nabble.com/Harbour---Dev-f688.html
( if you have not already subscibed to )
and look for messages related with QT ?

The goal of this development is to provide single-source ,
multi-platform compilations with native look and feel. To start with
it is emphasizing pure Harbour wrappers ( auto generated ),
the Clipper console named GTQTC, GUI console named GTQTG,
then on top of it Xbase++ compatible XbpParts class framework,
( this can be extended to write wrappers for Clip-4-Win also ).

If it interests you, you may join the team, as you have C knowledge.

To put some code in real use, though a small working demo ( absolute ),
is already there, you may wait a couple of months.

Regards
Pritpal Bedi, INDIA-USA
a student of software analysis and design

Jasim,

I am glad for you that you were able to port your 16-bit code to 32-bit
using xHarbour. I do monitor the (x)harbour newsgroups from a xBase
perspective to keep informed of what happens in that arena. And I have
many "code snippets" that I actually used as a basis and converted to
Visual Objects and now Vulcan.NET picked up from those newsgroups.

> IMHO, The market has come to expect the Bells and Whistles of Windows
> these days, but open source OSes are now not far behind the GUI
> capabilities of Windows. Regarding .NET, the language is powerful
> though heavy. And developer license are not as cheap as open-source
> alternatives. And I'm personally seeing a shift of attitude from
> Windows to favouring open source alternatives in the market.
> Especially with Vista being as heavy and backward-incompatible as it
> was, I'd place my bets on open-source than on Microsoft.

I do however feel that there are some misconceptions regarding .NET from
postings in this message thread that I feel should be rectified. Yes
one have to pay for your OS if you go MS. However, you can download the
..NET framework for free, C# with the Visual Studio Express edition is
again free. Yes you do miss out in having an integrated VS if you go
the express edition route. However if one consider the Activity Partner
programme from MS, you can get from a developer perspective most of
their applications for almost free (+-US$250) annually.

I am however working for one of the biggest companies in SA at the
moment and they refuse to even look at open source for mission critical
systems. For smaller companies that are cash strapped, yes it is
definately a solution.

To me, I develop on which platform my client require me to develop, even
if with Linux, I still don't feel uncomfortable using Vulcan.NET, as I
know there is Mono that I can use to run my applications on other
operating systems. However, the trend I see in South Africa is that
Open Source is mostly used in the backend. Very few users (well I still
have to find a reputable company) that actually use an open source OS
on their desktops.

So in conclusion, in that scenario I do not have problems in developing
Windows front-end applications that speak to backend servers on
Linux/Open Source Databases.

Just my two cents worth of another perspective on the issue of
developing platform.

Regards,

Johan

> Anything that ends up as open source will save your code efforts
> today, minimizing future difficulties. ADS likely will not do
> that for you. Nor will WinDock. Nor will SQLRDD. ADS is a rock
> solid product (and WinDock too probably), today. As is MySQL,
> and a dozen other offerings.

AFAICT, WinDock *is* an open source project.

Ron