Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Feedback on Xbase++ 1
- Thread starter greg85
- Start date
Download a trial version of xbase++ at and have a try for yourself.
I thought xbase++ specializes in clipper 5.2 code and not in de specifics of clipper 5.3 but I am not sure about that.
Rob.
I thought xbase++ specializes in clipper 5.2 code and not in de specifics of clipper 5.3 but I am not sure about that.
Rob.
I've written other replies on this subject. Usually comes down to a single advice: Redo from scratch.
Your clipper app was designed with 'serialisation' in mind, I think, and never intended to react to events happening on keyboard entry or mouseclicks etc. like current windows environments provide.
In the cases I was involved, and there were quite some, applications big and small, we never regretted going for a total overhaul of the system, starting with the design phase, or 'drawing board' stage. First thing we did was throw out anything that looks like clipper/xbase as the language was not designed to handle the new tasks, and is now almost a 'single vendor' solution. CA quit Clipper years ago and screw up VO, and xBase++ is the only serious commercial xbase around these days. I know about harbour, fivewin and other initiatives, and I've followed them for a few years, but in the long run you're just driving up the hill backward, on a bicycle, while other tools (Delphi, VB, C#, Java) can give you a windows based headstart: halfway that same hill, using a hotrod to get up. Once you know how to drive it, you'll drive it fast!
If you are still going for xBase dev. because of a lot of Clipper knowledge, please understand that 'old' clipper writers may also want or need a new 'toy' from time to time... and they 'll have to learn windows programming from the inside out, instead of from the outside in :-(
All I ever did to keep old Clipper apps 'alive' was add some functions to handle the clipboard (OSLIB) and printing to networked printers, the rest I postponed to a 'real' windows application.
HTH
TonHu
Your clipper app was designed with 'serialisation' in mind, I think, and never intended to react to events happening on keyboard entry or mouseclicks etc. like current windows environments provide.
In the cases I was involved, and there were quite some, applications big and small, we never regretted going for a total overhaul of the system, starting with the design phase, or 'drawing board' stage. First thing we did was throw out anything that looks like clipper/xbase as the language was not designed to handle the new tasks, and is now almost a 'single vendor' solution. CA quit Clipper years ago and screw up VO, and xBase++ is the only serious commercial xbase around these days. I know about harbour, fivewin and other initiatives, and I've followed them for a few years, but in the long run you're just driving up the hill backward, on a bicycle, while other tools (Delphi, VB, C#, Java) can give you a windows based headstart: halfway that same hill, using a hotrod to get up. Once you know how to drive it, you'll drive it fast!
If you are still going for xBase dev. because of a lot of Clipper knowledge, please understand that 'old' clipper writers may also want or need a new 'toy' from time to time... and they 'll have to learn windows programming from the inside out, instead of from the outside in :-(
All I ever did to keep old Clipper apps 'alive' was add some functions to handle the clipboard (OSLIB) and printing to networked printers, the rest I postponed to a 'real' windows application.
HTH
TonHu
I have used HYBRID mode to convert my Clipper apps
as they already exist from DOS to Windows 32 bit so that
my clients could be in a comfort zone about the future
support of their/my applications under future versions
of Windows.
By far the most tedious and time-consuming task was
having to rewrite my Ad-Hoc report-writer that relied on
.FRM report formats. Also I found that I needed to
visit every line of all the old reports to ensure that
xBASE++ output exactly the same as the old method.
I do not find the xBASE++ Report Wizard very useful because
all of my systems have a host of different columnar
reports and the stupid xBASE++ wizard does not offer
a simple means of creating/supporting such report formats.
I am giving Alaska one last try in this area of report
creation... if it can do what the manual says it can
and... if I can use the library supplied by Roger Donnay
(xPRESS++) with its DPRINT() function than I will
persevere...
.... otherwise I will ask for my money back from
ROger Donnay and throw out xBASE++
Cheers,
Jim Wild
T/A Wildcard Systems
New Zealand
<jwild@xtra.co.nz>
as they already exist from DOS to Windows 32 bit so that
my clients could be in a comfort zone about the future
support of their/my applications under future versions
of Windows.
By far the most tedious and time-consuming task was
having to rewrite my Ad-Hoc report-writer that relied on
.FRM report formats. Also I found that I needed to
visit every line of all the old reports to ensure that
xBASE++ output exactly the same as the old method.
I do not find the xBASE++ Report Wizard very useful because
all of my systems have a host of different columnar
reports and the stupid xBASE++ wizard does not offer
a simple means of creating/supporting such report formats.
I am giving Alaska one last try in this area of report
creation... if it can do what the manual says it can
and... if I can use the library supplied by Roger Donnay
(xPRESS++) with its DPRINT() function than I will
persevere...
.... otherwise I will ask for my money back from
ROger Donnay and throw out xBASE++
Cheers,
Jim Wild
T/A Wildcard Systems
New Zealand
<jwild@xtra.co.nz>
-
1
- #5
RHankinsJr
Programmer
I happen to use xBase v1.8 for my programs and have converted several Clipper 5.2e applications to xBase with some work but nothing too drastic.
What you need to realize is that if you use alot of libraries or utilities (3rd party) you will have to rethink them unless you have the source code to recompile them. The reason behind this is you are going from a 16bit application to a 32bit application.
If you do decide to go to xBase there are several ways to do this. One method is VIO mode which renders your application looking exactly like a dos program, it is in a dos program box and everything in Windows but it is 32 bit. The next option is Hybrid mode which generates an application window that cannot be set to full screen. These two options will allow you to use your clipper coding knowledge to maintain the application and write new ones. The last option is to go totally windows. This is where a rewrite will be needed and some extra knowledge will be needing required. VIO and HYBRID both will allow you to make and disribute applications using clipper only code, but Full GUI will require you to scrap everything and go to object modeled code such as VB, C++ With MFC, Delphi, etc.
In my opinion I say do it, xBase is pretty darn functional in all modes. I have created applications using all three modes and not had much problem at all with them (well no more than usual for me). And I have written everything from Full POS systems to label writers to 100k line database programs.
It is a viable option if you want to explore it. There are a couple add on libraries that you may want to research if you are going full GUI and that is Clayton Jones Top Down Library ( and Roger Donnay's eXpress (
If you have any other questions just ask.
Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
What you need to realize is that if you use alot of libraries or utilities (3rd party) you will have to rethink them unless you have the source code to recompile them. The reason behind this is you are going from a 16bit application to a 32bit application.
If you do decide to go to xBase there are several ways to do this. One method is VIO mode which renders your application looking exactly like a dos program, it is in a dos program box and everything in Windows but it is 32 bit. The next option is Hybrid mode which generates an application window that cannot be set to full screen. These two options will allow you to use your clipper coding knowledge to maintain the application and write new ones. The last option is to go totally windows. This is where a rewrite will be needed and some extra knowledge will be needing required. VIO and HYBRID both will allow you to make and disribute applications using clipper only code, but Full GUI will require you to scrap everything and go to object modeled code such as VB, C++ With MFC, Delphi, etc.
In my opinion I say do it, xBase is pretty darn functional in all modes. I have created applications using all three modes and not had much problem at all with them (well no more than usual for me). And I have written everything from Full POS systems to label writers to 100k line database programs.
It is a viable option if you want to explore it. There are a couple add on libraries that you may want to research if you are going full GUI and that is Clayton Jones Top Down Library ( and Roger Donnay's eXpress (
If you have any other questions just ask.
Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
I have converted a large clipper app to xbase. You can do this in stages. First convert all apps as text base and then use Express from Roger Donnay to implement GUI. If your clipper code is fairly clean and you don't use a lot of external libraries the basic conversion is pretty easy. Converting your code to gui is fairly simple as well. I would recommend xbase and express to anyone.
Be very carefull.
I have 100% clipper code which is NOT 100% xbase++ compatible.
TonHu is right, there are no shortcuts. I would dearly like to convert one of my (my clients) apps to xbase, but it will not work - I have spent hours trying to locate the incompatibilities, but at the end of the day it isn't worth it.
I am well aware that it is difficult to persuade a client to fund a rewrite, but if he/she won't then it probably isn't worth trying to get xbase++ to do the job instead.
This probably won't please the xbase people, but right here and now I challenge them to get the app I'm talking about to run properly when in xbase. It is ten years old, there is a VERY small C element (shadows on boxes) and it runs very nicely on about 2-300 machines right now.
If they want to try, there is an NDA and I'll need to get the clients permission - so go ahead make my clients day (ps if you are successful I am due 10% of the final invoiced value!).
Martin Griffin
Finedata Limited
martin.griffin@finedata.com
Regards
Griff
Keep [Smile]ing
I have 100% clipper code which is NOT 100% xbase++ compatible.
TonHu is right, there are no shortcuts. I would dearly like to convert one of my (my clients) apps to xbase, but it will not work - I have spent hours trying to locate the incompatibilities, but at the end of the day it isn't worth it.
I am well aware that it is difficult to persuade a client to fund a rewrite, but if he/she won't then it probably isn't worth trying to get xbase++ to do the job instead.
This probably won't please the xbase people, but right here and now I challenge them to get the app I'm talking about to run properly when in xbase. It is ten years old, there is a VERY small C element (shadows on boxes) and it runs very nicely on about 2-300 machines right now.
If they want to try, there is an NDA and I'll need to get the clients permission - so go ahead make my clients day (ps if you are successful I am due 10% of the final invoiced value!).
Martin Griffin
Finedata Limited
martin.griffin@finedata.com
Regards
Griff
Keep [Smile]ing
You raise an interesting business ethic Griff about 10%
retentions.
A programmer is worthy of his hire. A programmer is
often called back in (sometimes decades after development)
to make repairs or changes to an application.
The trick to being available is to stay in business...
ie to stay solvent. If a programmer goes 'bust' he
is no longer available to honour warranty claims or
service a request for enhancement.
If there is no NDA then the programmer retains
Intellectual Property in the solutions devised
for the application. This is an asset that can
justifiably be amortized to cover the cost of
program repairs under warranty.
If there is an NDA then the programmer has no
asset to amortize to cover downstream costs.
10 retentions in this case are not good business
practice these days.
IN the early years I offered a 10% 'Retention' clause in my development contracts and sometimes had to wait many months
before receiving final settlement.
20 years ago I had to rethink after losing too much potential income (where the top 10% is usually profit!). I was ripped off by clients going bust (or bought out), changes to personnel with a different agenda, legal wrangles over system definition, etc
So, nowadays I no longer offer (or agree to) a 10%
retention as such. Instead I insist on progress payments during development so that 90% of the contract is met on (or
before) date of installation and the final 10% due
(without dispute) on the 20th following.
IN this way I get my money and any disputed items are handled 'under warranty' rather than 'under threat of retention'.
This may be a small point - but it keeps me solvent.
Cheers,
Jim
retentions.
A programmer is worthy of his hire. A programmer is
often called back in (sometimes decades after development)
to make repairs or changes to an application.
The trick to being available is to stay in business...
ie to stay solvent. If a programmer goes 'bust' he
is no longer available to honour warranty claims or
service a request for enhancement.
If there is no NDA then the programmer retains
Intellectual Property in the solutions devised
for the application. This is an asset that can
justifiably be amortized to cover the cost of
program repairs under warranty.
If there is an NDA then the programmer has no
asset to amortize to cover downstream costs.
10 retentions in this case are not good business
practice these days.
IN the early years I offered a 10% 'Retention' clause in my development contracts and sometimes had to wait many months
before receiving final settlement.
20 years ago I had to rethink after losing too much potential income (where the top 10% is usually profit!). I was ripped off by clients going bust (or bought out), changes to personnel with a different agenda, legal wrangles over system definition, etc
So, nowadays I no longer offer (or agree to) a 10%
retention as such. Instead I insist on progress payments during development so that 90% of the contract is met on (or
before) date of installation and the final 10% due
(without dispute) on the 20th following.
IN this way I get my money and any disputed items are handled 'under warranty' rather than 'under threat of retention'.
This may be a small point - but it keeps me solvent.
Cheers,
Jim
Hello Jim,
I haven't thought about retentions in years, I once worked on a major offshore oil project where all the senior management were on contract and had a 7% retention - which worked out very nicely for all of them, they didn't get the money until they were outside the clutches of the UK Inland Revenue service, somewhere sunny with a no tax/low tax regime! (They were all in the job for about five years too)
Personnaly, I don't have retention clauses (the 10% in my previous message was more of a bounty!) but customers do generally pay on a milestone basis - i.e. 50% when they see the 'first look' or proof of concept then stage payments to completion. I've not had a customer hold back when invoiced. I do have quite a few customers who NOW work on a "Don't pay till you badger us" basis though - this can be annoying.
GriffMG Regards
Griff
Keep [Smile]ing
I haven't thought about retentions in years, I once worked on a major offshore oil project where all the senior management were on contract and had a 7% retention - which worked out very nicely for all of them, they didn't get the money until they were outside the clutches of the UK Inland Revenue service, somewhere sunny with a no tax/low tax regime! (They were all in the job for about five years too)
Personnaly, I don't have retention clauses (the 10% in my previous message was more of a bounty!) but customers do generally pay on a milestone basis - i.e. 50% when they see the 'first look' or proof of concept then stage payments to completion. I've not had a customer hold back when invoiced. I do have quite a few customers who NOW work on a "Don't pay till you badger us" basis though - this can be annoying.
GriffMG Regards
Griff
Keep [Smile]ing
RHankinsJr
Programmer
Griff, if you send me a sample of the source code I bet I can convert it using Alaska xBase++ 
- Rick Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
- Rick Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
RHankinsJr
Programmer
Don't get me wrong... I do not want to try to do the whole thing, but I am sure that I can assist you in the areas you are having problems with.... I also have some clipper code to do the non destructive shadows
Rick Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
Rick Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
RHankinsJr
Programmer
Oh and by the way.. RHankins@contactasi.com Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
Senior Programmer
Auction Services, Inc.
Richard,
That is an extraordinarily helpful offer! You're right, I wouldn't want to send across all 100,000 lines of code but
if you'll bear with me I might be able to 'cook-up' a representative sample system with a menu, a tbrowse and a second tbrowse on a child table - It will take a few days to get the time, so please don't go holding your breath.
Many thanks in advance
Regards
Griff
Keep [Smile]ing
That is an extraordinarily helpful offer! You're right, I wouldn't want to send across all 100,000 lines of code but
if you'll bear with me I might be able to 'cook-up' a representative sample system with a menu, a tbrowse and a second tbrowse on a child table - It will take a few days to get the time, so please don't go holding your breath.
Many thanks in advance
Regards
Griff
Keep [Smile]ing
Humm, I may have to eat a little humble pie here...
I made a tres simple bit of code from a really old app
and, bar something I already knew, the blessed thing
worked...
Richard, I'm going to have another look at this and come back to you!
Many thanks
Regards
Griff
Keep [Smile]ing
I made a tres simple bit of code from a really old app
and, bar something I already knew, the blessed thing
worked...
Richard, I'm going to have another look at this and come back to you!
Many thanks
Regards
Griff
Keep [Smile]ing
Oh my gosh, subject to some testing, I've gorn and done it!
Thanks to Richard I've converted my clients 100,000 line application to xBase++ all the apparent incompatibilities seem to be solved!
It's all Richards fault, because in order to send him something with problems I could identify - I had to sort out where they were. Once you've done that, they are a doddle to fix!
Thank you!
Now, on to the client!
Regards
Griff
Keep [Smile]ing
Thanks to Richard I've converted my clients 100,000 line application to xBase++ all the apparent incompatibilities seem to be solved!
It's all Richards fault, because in order to send him something with problems I could identify - I had to sort out where they were. Once you've done that, they are a doddle to fix!
Thank you!
Now, on to the client!
Regards
Griff
Keep [Smile]ing
RHankinsJr
Programmer
I am glad that my offer could help. I am a big supporter of Alaska's xBase. There are some things that require a little 'fiddling' to fix but none of them are too tough to work with.
If anyone is converting to Alaska xBase feel free to ask me any questions you may encounter. If I cannot help there are some real wonderful people on the Alaska forum that have helped me to work wonders!!
Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
If anyone is converting to Alaska xBase feel free to ask me any questions you may encounter. If I cannot help there are some real wonderful people on the Alaska forum that have helped me to work wonders!!
Richard L. Hankins Jr.
Senior Programmer
Auction Services, Inc.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question