Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight to 
GUI with XbpCrt or make a detour to VIO?

I assumed that VIO was the least disruptive to our production enviroment, 
but I don't get the impression that anyone else is using VIO apps.

Rodd

I skip the CRT and VIO entirely. It is easest to just move straight to 
GUI. There are really too many differences between Event Driven GUI and 
  Procedual CRT. You can generaly save most of the true buisness logic 
and the reports with a little message.  You just have to grit your teath 
and  jump the screen stuff to full GUI. Nobody is likly to want a VIO 
app for long it being neither CRT or true windows. There are two third 
party Libs that can be used to accelerate development and keep some of 
the old screen logic TopDown and Express++.  However this preficates you 
have a qwell written Clipper 5.X program to update. I'm currently 
working on a 700K line program written entirly in a very primitive 
dBaseIII coding style with Cobal style edit screens. There just is not 
an easy way.

Jim

Rodd Graham wrote:

> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight to 
> GUI with XbpCrt or make a detour to VIO?
> 
> I assumed that VIO was the least disruptive to our production enviroment, 
> but I don't get the impression that anyone else is using VIO apps.
> 
> Rodd 
> 
>

Personally, I went straight to GUI

I thought about VIO for the fact that I could keep the window being visibly
the same and there would be minimal change to the way the users were
working.

In the end I decided against it because there was ClassY code that I decided
was more work to duplicate than it was worth - and that in fact the users
would eventually have to get used to a windows world rather than the DOS
world, so go there sooner than later...

Eric Breddam
SOM Data Services
"Rodd Graham" <rodd@tpmco.com> wrote in message
news:5D5Le6KuFHA.5608@S15147418...
> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight
to
> GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment,
> but I don't get the impression that anyone else is using VIO apps.
>
> Rodd
>
>

I too started with CRT, initially and dropped during my trial phase and 
moved to GUI straight-away.

Had to re-write my FrontEnd Entry screen (forms), but then I wrote my own 
wrappers around Topdown (then).
Though lately I have been using TD Functions directly.

Moving my reports (over 380+ reports, developed over a long period), in the 
product was a breeze, as I just need to port the Report Class (written using 
ClassY) to Xb++ using TD.

Anand

"Rodd Graham" <rodd@tpmco.com> wrote in message 
news:5D5Le6KuFHA.5608@S15147418...
> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight 
> to GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment, 
> but I don't get the impression that anyone else is using VIO apps.
>
> Rodd
>

Rodd,

> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight
to
> GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment,
> but I don't get the impression that anyone else is using VIO apps.

Yup, I did a long time ago, first go to VIO, and then use XbpCrt in
graphical mode.
The problem with that migrationpath is that the step from XbpCrt in
graphical mode
to GUI is big, and graphical windows on a XbpCrt terminal make your program
horrible to look at, and horrible to work with.

I have seen examples of programs in this second stage with a very
professional
look. It might even be the best user interface solution.

HTH,
Frans Vermeulen

James, Eric, and Anand:

All good comments that make me question the VIO decision in our system. 
This decision was originally made by user resistance to change and ease of 
migration from Clipper.

One follow up question:

Do your users use a variety of applications or perform activities that 
require decision making?

I ask this to evaluate whether our users who only use one application which 
is mostly data entry, production and customer service are better suited with 
the VIO or GUI implementations.

Rodd

"Rodd Graham" <rodd@tpmco.com> wrote in message 
news:5D5Le6KuFHA.5608@S15147418...
> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight 
> to GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment, 
> but I don't get the impression that anyone else is using VIO apps.
>
> Rodd
>

> Do your users use a variety of applications or perform activities that
> require decision making?
>
> I ask this to evaluate whether our users who only use one application
which
> is mostly data entry, production and customer service are better suited
with
> the VIO or GUI implementations.
>

I don't really understand the question but... my users do data entry on a
constant day-to-day basis and about once a quarter do a fair bit of
reporting and exporting and 'use' the data.

Eric,

> I don't really understand the question but...

The question is geared to decide if our application and users are typical 
compared to the NG experience.  Since we are essentially a manufacturer, our 
process is mostly defined with specific steps performed by novice computer 
users.

What are the benefits to expect by presenting a more robust GUI application 
in this situation?  I have a hard time buying into GUI for the sake of GUI 
if I cannot express benefits that exceed the costs of the change (net 
overall value increase).  Does GUI have an inherent advantage when the 
process is specific and defined?

I am not taking a position as much as looking for a compelling argument that 
tips the scale between GUI and VIO.

Regarding Win64/Vista, I assume that Win32 character mode (VIO) is still 
supported?

Rodd

"Eric Breddam" <eric@somdata.com> wrote in message 
news:jrcQigVuFHA.1256@S15147418...
>> Do your users use a variety of applications or perform activities that
>> require decision making?
>>
>> I ask this to evaluate whether our users who only use one application
> which
>> is mostly data entry, production and customer service are better suited
> with
>> the VIO or GUI implementations.
>>
>
> I don't really understand the question but... my users do data entry on a
> constant day-to-day basis and about once a quarter do a fair bit of
> reporting and exporting and 'use' the data.
>
>
>

Ah, I see now... and I understand completely now... and in your situation i
have no argument that tips it either way for you ... what are your reasons
for moving away from Clipper in the first place?   We might have stayed
there if we could have run the network as essentially a bunch of DOS
terminals... but once we decided we 'had to go to windows' we figured go the
full way...

Eric Breddam
SOM Data Services


"Rodd Graham" <rodd@tpmco.com> wrote in message
news:WOytdEWuFHA.5608@S15147418...
> Eric,
>
> > I don't really understand the question but...
>
> The question is geared to decide if our application and users are typical
> compared to the NG experience.  Since we are essentially a manufacturer,
our
> process is mostly defined with specific steps performed by novice computer
> users.
>
> What are the benefits to expect by presenting a more robust GUI
application
> in this situation?  I have a hard time buying into GUI for the sake of GUI
> if I cannot express benefits that exceed the costs of the change (net
> overall value increase).  Does GUI have an inherent advantage when the
> process is specific and defined?
>
> I am not taking a position as much as looking for a compelling argument
that
> tips the scale between GUI and VIO.
>
> Regarding Win64/Vista, I assume that Win32 character mode (VIO) is still
> supported?
>
> Rodd
>
> "Eric Breddam" <eric@somdata.com> wrote in message
> news:jrcQigVuFHA.1256@S15147418...
> >> Do your users use a variety of applications or perform activities that
> >> require decision making?
> >>
> >> I ask this to evaluate whether our users who only use one application
> > which
> >> is mostly data entry, production and customer service are better suited
> > with
> >> the VIO or GUI implementations.
> >>
> >
> > I don't really understand the question but... my users do data entry on
a
> > constant day-to-day basis and about once a quarter do a fair bit of
> > reporting and exporting and 'use' the data.
> >
> >
> >
>
>

We went ahead with windows using the NTVDM to support Clipper.  Move to 
Xbase is driven by reduced stability of DPMI memory and outgrowing 
clipper/blinker memory limits.

Rodd

"Eric Breddam" <eric@somdata.com> wrote in message 
news:ICsksNWuFHA.1256@S15147418...
> Ah, I see now... and I understand completely now... and in your situation 
> i
> have no argument that tips it either way for you ... what are your reasons
> for moving away from Clipper in the first place?   We might have stayed
> there if we could have run the network as essentially a bunch of DOS
> terminals... but once we decided we 'had to go to windows' we figured go 
> the
> full way...
>
> -- 
> Eric Breddam
> SOM Data Services
>
>
> "Rodd Graham" <rodd@tpmco.com> wrote in message
> news:WOytdEWuFHA.5608@S15147418...
>> Eric,
>>
>> > I don't really understand the question but...
>>
>> The question is geared to decide if our application and users are typical
>> compared to the NG experience.  Since we are essentially a manufacturer,
> our
>> process is mostly defined with specific steps performed by novice 
>> computer
>> users.
>>
>> What are the benefits to expect by presenting a more robust GUI
> application
>> in this situation?  I have a hard time buying into GUI for the sake of 
>> GUI
>> if I cannot express benefits that exceed the costs of the change (net
>> overall value increase).  Does GUI have an inherent advantage when the
>> process is specific and defined?
>>
>> I am not taking a position as much as looking for a compelling argument
> that
>> tips the scale between GUI and VIO.
>>
>> Regarding Win64/Vista, I assume that Win32 character mode (VIO) is still
>> supported?
>>
>> Rodd
>>
>> "Eric Breddam" <eric@somdata.com> wrote in message
>> news:jrcQigVuFHA.1256@S15147418...
>> >> Do your users use a variety of applications or perform activities that
>> >> require decision making?
>> >>
>> >> I ask this to evaluate whether our users who only use one application
>> > which
>> >> is mostly data entry, production and customer service are better 
>> >> suited
>> > with
>> >> the VIO or GUI implementations.
>> >>
>> >
>> > I don't really understand the question but... my users do data entry on
> a
>> > constant day-to-day basis and about once a quarter do a fair bit of
>> > reporting and exporting and 'use' the data.
>> >
>> >
>> >
>>
>>
>
>

having read the post from Jimmy (AUGE_OHR) below, I realized i forgot to
describe our migration path more completely - it's very similar if not the
same as his.

We did reporting functions first, for much the same reason - management
wanted that point and click-on-big-buttons stuff while users wanted zero
change... so we developed gui reporting while maintaing Clipper data entry
and eventually moved the data entry to gui... there was a very long period
where both had to run together....

Eric Breddam
SOM Data Services

We moved all of our reporting to Crystal against SqlServer long ago.  Our 
Clipper->Xbase++ app is purely data entry, customer service lookup, and 
manufacture processing.

How long did you run the non-GUI and what benefits did you receive from 
moving to GUI?

Rodd

"Eric Breddam" <eric@somdata.com> wrote in message 
news:Zx$7fPWuFHA.5608@S15147418...
> having read the post from Jimmy (AUGE_OHR) below, I realized i forgot to
> describe our migration path more completely - it's very similar if not the
> same as his.
>
> We did reporting functions first, for much the same reason - management
> wanted that point and click-on-big-buttons stuff while users wanted zero
> change... so we developed gui reporting while maintaing Clipper data entry
> and eventually moved the data entry to gui... there was a very long period
> where both had to run together....
>
> -- 
> Eric Breddam
> SOM Data Services
>
>

well, truley it should have been six months (as planned) of running both
simultaneously but it was two years after all the 'moving targets' and new
development were met ...

With regards to data-entry, I can't say there were any real benefits - the
client users would have been happier staying with the Clipper app but the
client management was generally looking for something more 'modern' - in at
least one case they planned to sell the business and didn't think they could
sell the (working, functional, running-steady-for-10-years) clipper app with
it but would get more value if they included a visibly 'windows' app.

I can say it seemed to be running slowly on XP systems but we didn't test it
long enough to worry about it - it was done migrating by the time any of our
clients had to buy XP machines.

As a programmer, threading, access to windows DLL's, access to other windows
components (registry, ocx come to mind), a lot of stuff the apps didn't do
when we started the migration - those are nice but i wouldn't say they
improved the data entry system at all.

Eric Breddam
SOM Data Services

On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:

> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight to 
> GUI with XbpCrt or make a detour to VIO?
> 
> I assumed that VIO was the least disruptive to our production enviroment, 
> but I don't get the impression that anyone else is using VIO apps.
> 
> Rodd

I would suggest you to go directly to GUI. 
Why doing the work twice ?

And if you don't want to reinvent the wheel, try Clayton Jone's TopDown
Library. It will save you hundreds of hours of work.

Raymond Fischbach
Belgium
http://www.mouches.org

Raymond,

But if I am migrating existing Clipper, wouldn't it be 'why do the work 
once'.  Doesn't the VIO mode provide a functionally equivalent operation to 
the Clipper app?

However, with multiple suggestions to TopDown and Express++, I will need to 
investigate prior to going GUI.

Rodd

"Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in message 
news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>
>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight 
>> to
>> GUI with XbpCrt or make a detour to VIO?
>>
>> I assumed that VIO was the least disruptive to our production enviroment,
>> but I don't get the impression that anyone else is using VIO apps.
>>
>> Rodd
>
> I would suggest you to go directly to GUI.
> Why doing the work twice ?
>
> And if you don't want to reinvent the wheel, try Clayton Jone's TopDown
> Library. It will save you hundreds of hours of work.
>
>
> -- 
> Raymond Fischbach
> Belgium
> http://www.mouches.org

Hi Rodd,

What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
looks like DOS?  If the latter, then the next question is why not stick 
with Clipper?  You will find that Clipper Apps are going to be faster, 
but you may have some problems with WindowsXP and newer Monitors.

IMO, the GUI Object Oriented Environment ultimately provides a much more 
flexible App, but it also presents some new programming challenges.

If you eventually want a GUI App then just bite the bullet and go 
directly to GUI.

-Joe

Rodd Graham wrote:
> Raymond,
> 
> But if I am migrating existing Clipper, wouldn't it be 'why do the work 
> once'.  Doesn't the VIO mode provide a functionally equivalent operation to 
> the Clipper app?
> 
> However, with multiple suggestions to TopDown and Express++, I will need to 
> investigate prior to going GUI.
> 
> Rodd
> 
> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in message 
> news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
> 
>>On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>
>>
>>>Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight 
>>>to
>>>GUI with XbpCrt or make a detour to VIO?
>>>
>>>I assumed that VIO was the least disruptive to our production enviroment,
>>>but I don't get the impression that anyone else is using VIO apps.
>>>
>>>Rodd
>>
>>I would suggest you to go directly to GUI.
>>Why doing the work twice ?
>>
>>And if you don't want to reinvent the wheel, try Clayton Jone's TopDown
>>Library. It will save you hundreds of hours of work.
>>
>>
>>-- 
>>Raymond Fischbach
>>Belgium
>>http://www.mouches.org 
> 
> 
>

Joe, a reason might be that the new 64 bit OS's are not supporting 16 
bit programs any more!!!!

Jim

Joe Carrick wrote:

> Hi Rodd,
> 
> What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
> looks like DOS?  If the latter, then the next question is why not stick 
> with Clipper?  You will find that Clipper Apps are going to be faster, 
> but you may have some problems with WindowsXP and newer Monitors.
> 
> IMO, the GUI Object Oriented Environment ultimately provides a much more 
> flexible App, but it also presents some new programming challenges.
> 
> If you eventually want a GUI App then just bite the bullet and go 
> directly to GUI.
> 
> -Joe
> 
> Rodd Graham wrote:
> 
>> Raymond,
>>
>> But if I am migrating existing Clipper, wouldn't it be 'why do the 
>> work once'.  Doesn't the VIO mode provide a functionally equivalent 
>> operation to the Clipper app?
>>
>> However, with multiple suggestions to TopDown and Express++, I will 
>> need to investigate prior to going GUI.
>>
>> Rodd
>>
>> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in 
>> message news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>
>>> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>
>>>
>>>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go 
>>>> straight to
>>>> GUI with XbpCrt or make a detour to VIO?
>>>>
>>>> I assumed that VIO was the least disruptive to our production 
>>>> enviroment,
>>>> but I don't get the impression that anyone else is using VIO apps.
>>>>
>>>> Rodd
>>>
>>>
>>> I would suggest you to go directly to GUI.
>>> Why doing the work twice ?
>>>
>>> And if you don't want to reinvent the wheel, try Clayton Jone's TopDown
>>> Library. It will save you hundreds of hours of work.
>>>
>>>
>>> -- 
>>> Raymond Fischbach
>>> Belgium
>>> http://www.mouches.org 
>>
>>
>>
>>

Hi James,

We have a Clipper App that is still running just fine on WinXP_Pro with 
SP2.  The only problem is with newer Monitors where it's necessary to 
start it in a window and then change the properties to full screen so 
the mouse works properly.

-Joe

James Loughner wrote:
> Joe, a reason might be that the new 64 bit OS's are not supporting 16 
> bit programs any more!!!!
> 
> Jim
> 
> Joe Carrick wrote:
> 
>> Hi Rodd,
>>
>> What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
>> looks like DOS?  If the latter, then the next question is why not 
>> stick with Clipper?  You will find that Clipper Apps are going to be 
>> faster, but you may have some problems with WindowsXP and newer Monitors.
>>
>> IMO, the GUI Object Oriented Environment ultimately provides a much 
>> more flexible App, but it also presents some new programming challenges.
>>
>> If you eventually want a GUI App then just bite the bullet and go 
>> directly to GUI.
>>
>> -Joe
>>
>> Rodd Graham wrote:
>>
>>> Raymond,
>>>
>>> But if I am migrating existing Clipper, wouldn't it be 'why do the 
>>> work once'.  Doesn't the VIO mode provide a functionally equivalent 
>>> operation to the Clipper app?
>>>
>>> However, with multiple suggestions to TopDown and Express++, I will 
>>> need to investigate prior to going GUI.
>>>
>>> Rodd
>>>
>>> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in 
>>> message news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>
>>>> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>
>>>>
>>>>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go 
>>>>> straight to
>>>>> GUI with XbpCrt or make a detour to VIO?
>>>>>
>>>>> I assumed that VIO was the least disruptive to our production 
>>>>> enviroment,
>>>>> but I don't get the impression that anyone else is using VIO apps.
>>>>>
>>>>> Rodd
>>>>
>>>>
>>>>
>>>> I would suggest you to go directly to GUI.
>>>> Why doing the work twice ?
>>>>
>>>> And if you don't want to reinvent the wheel, try Clayton Jone's TopDown
>>>> Library. It will save you hundreds of hours of work.
>>>>
>>>>
>>>> -- 
>>>> Raymond Fischbach
>>>> Belgium
>>>> http://www.mouches.org 
>>>
>>>
>>>
>>>
>>>

Are you running a 64 bit processor. My understanding is the XP 64 does 
not support 16 bit DOS applications. And Windows Vista definitely won't 
even for 32 bit processors!!!

Jim

Joe Carrick wrote:
> Hi James,
> 
> We have a Clipper App that is still running just fine on WinXP_Pro with 
> SP2.  The only problem is with newer Monitors where it's necessary to 
> start it in a window and then change the properties to full screen so 
> the mouse works properly.
> 
> -Joe
> 
> James Loughner wrote:
> 
>> Joe, a reason might be that the new 64 bit OS's are not supporting 16 
>> bit programs any more!!!!
>>
>> Jim
>>
>> Joe Carrick wrote:
>>
>>> Hi Rodd,
>>>
>>> What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
>>> looks like DOS?  If the latter, then the next question is why not 
>>> stick with Clipper?  You will find that Clipper Apps are going to be 
>>> faster, but you may have some problems with WindowsXP and newer 
>>> Monitors.
>>>
>>> IMO, the GUI Object Oriented Environment ultimately provides a much 
>>> more flexible App, but it also presents some new programming challenges.
>>>
>>> If you eventually want a GUI App then just bite the bullet and go 
>>> directly to GUI.
>>>
>>> -Joe
>>>
>>> Rodd Graham wrote:
>>>
>>>> Raymond,
>>>>
>>>> But if I am migrating existing Clipper, wouldn't it be 'why do the 
>>>> work once'.  Doesn't the VIO mode provide a functionally equivalent 
>>>> operation to the Clipper app?
>>>>
>>>> However, with multiple suggestions to TopDown and Express++, I will 
>>>> need to investigate prior to going GUI.
>>>>
>>>> Rodd
>>>>
>>>> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in 
>>>> message news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>>
>>>>> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>>
>>>>>
>>>>>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go 
>>>>>> straight to
>>>>>> GUI with XbpCrt or make a detour to VIO?
>>>>>>
>>>>>> I assumed that VIO was the least disruptive to our production 
>>>>>> enviroment,
>>>>>> but I don't get the impression that anyone else is using VIO apps.
>>>>>>
>>>>>> Rodd
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I would suggest you to go directly to GUI.
>>>>> Why doing the work twice ?
>>>>>
>>>>> And if you don't want to reinvent the wheel, try Clayton Jone's 
>>>>> TopDown
>>>>> Library. It will save you hundreds of hours of work.
>>>>>
>>>>>
>>>>> -- 
>>>>> Raymond Fischbach
>>>>> Belgium
>>>>> http://www.mouches.org 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

Hi James,

Our most advanced systems are running with Pentium4 processors with 
WinXP-Pro, SP2.  We have a variety of systems, some of them are older 
Win98-SE with lesser processors.

None of the systems has any problem running a DOS 16-bit application.
However, we will be moving this App to Xbase++ within the next year.
Ou primary reasons for migrating this App is to take advantage of GUI, 
Graphic Printing, etc.

The biggest problem is that most of the code was written without a 
declared Procedure or Function Name.  Each Procedure was a separate prg 
and called simply by the file name.  This worked in Clipper but made it 
very difficult to migrate to Xbase++.  Consequently it has been kept as 
a DOS App up to this time.

-Joe

James Loughner wrote:

> Are you running a 64 bit processor. My understanding is the XP 64 does 
> not support 16 bit DOS applications. And Windows Vista definitely won't 
> even for 32 bit processors!!!
> 
> Jim
> 
> Joe Carrick wrote:
> 
>> Hi James,
>>
>> We have a Clipper App that is still running just fine on WinXP_Pro 
>> with SP2.  The only problem is with newer Monitors where it's 
>> necessary to start it in a window and then change the properties to 
>> full screen so the mouse works properly.
>>
>> -Joe
>>
>> James Loughner wrote:
>>
>>> Joe, a reason might be that the new 64 bit OS's are not supporting 16 
>>> bit programs any more!!!!
>>>
>>> Jim
>>>
>>> Joe Carrick wrote:
>>>
>>>> Hi Rodd,
>>>>
>>>> What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
>>>> looks like DOS?  If the latter, then the next question is why not 
>>>> stick with Clipper?  You will find that Clipper Apps are going to be 
>>>> faster, but you may have some problems with WindowsXP and newer 
>>>> Monitors.
>>>>
>>>> IMO, the GUI Object Oriented Environment ultimately provides a much 
>>>> more flexible App, but it also presents some new programming 
>>>> challenges.
>>>>
>>>> If you eventually want a GUI App then just bite the bullet and go 
>>>> directly to GUI.
>>>>
>>>> -Joe
>>>>
>>>> Rodd Graham wrote:
>>>>
>>>>> Raymond,
>>>>>
>>>>> But if I am migrating existing Clipper, wouldn't it be 'why do the 
>>>>> work once'.  Doesn't the VIO mode provide a functionally equivalent 
>>>>> operation to the Clipper app?
>>>>>
>>>>> However, with multiple suggestions to TopDown and Express++, I will 
>>>>> need to investigate prior to going GUI.
>>>>>
>>>>> Rodd
>>>>>
>>>>> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in 
>>>>> message news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>>>
>>>>>> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>>>
>>>>>>
>>>>>>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go 
>>>>>>> straight to
>>>>>>> GUI with XbpCrt or make a detour to VIO?
>>>>>>>
>>>>>>> I assumed that VIO was the least disruptive to our production 
>>>>>>> enviroment,
>>>>>>> but I don't get the impression that anyone else is using VIO apps.
>>>>>>>
>>>>>>> Rodd
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would suggest you to go directly to GUI.
>>>>>> Why doing the work twice ?
>>>>>>
>>>>>> And if you don't want to reinvent the wheel, try Clayton Jone's 
>>>>>> TopDown
>>>>>> Library. It will save you hundreds of hours of work.
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Raymond Fischbach
>>>>>> Belgium
>>>>>> http://www.mouches.org 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

hi,

> The biggest problem is that most of the code was written without a
> declared Procedure or Function Name.  Each Procedure was a separate
> prg  and called simply by the file name.  This worked in Clipper but made
> it  very difficult to migrate to Xbase++.

at this point i wrote a small programm just to include "PROCEDURE name"
or "FUNCTION name" as first line (after #include ) into all my *.PRG.

> Consequently it has been kept as  a DOS App up to this time.

this work with cl*pper too .
my favorite is #IFDEF __XPP__

greetings by OHR
Jimmy

Oops, forgot about #include directives, but I do not think you can use them 
in a .prg with an implicit starting procedure so it may not be a problem. 
The #include would be inside of the routine?

Rodd

"AUGE_OHR" <AUGE_OHR*AT*CSI.COM> wrote in message 
news:tP9sNzXuFHA.7860@S15147418...
> hi,
>
>> The biggest problem is that most of the code was written without a
>> declared Procedure or Function Name.  Each Procedure was a separate
>> prg  and called simply by the file name.  This worked in Clipper but made
>> it  very difficult to migrate to Xbase++.
>
> at this point i wrote a small programm just to include "PROCEDURE name"
> or "FUNCTION name" as first line (after #include ) into all my *.PRG.
>
>> Consequently it has been kept as  a DOS App up to this time.
>
> this work with cl*pper too .
> my favorite is #IFDEF __XPP__
>
> greetings by OHR
> Jimmy
>
>
>

Joe,

Using 2K/XP with command extensions enabled, make a .cmd file as follows or 
use attached.  Note: Do not add a () after the function name in the cmd 
script or the ) character will prematurely close the echo block.

rem <start of cmd script>
md newprg
for %%x in (*.prg) do (
  ( echo #include "StdJoe.ch"
    echo.
    echo function %%~nx
    echo. ) >newprg\%%x
  copy newprg\%%x+%%x newprg\%%x
)
rem <end of cmd script>

If you want () after function name use:
  echo #include "StdJoe.ch" >newprg\%%x
  echo. >>newprg\%%x
  echo function %%~nx() >>newprg\%%x
  echo. >>newprg\%%x

If your .prg do not end with Return, the add after copy line but inside for 
loop:

  echo. >>newprg\%%x
  echo Return >>newprg\%%x

Make a backup of all files in source code directory, then run script in 
source code directory.  New prg files should be in newprg subfolder.

Then make the following StdJoe.ch since all .prgs made functions.

<start of stdjoe.ch>
#xcommand Return => Return nil
<end of stdjoe.ch>

Compile prg in newprg subfolder in Xbase++, link, and cross your fingers.  I 
use makefiles, but I think you can build a xpj file for the file list.

Good luck

Rodd

"Joe Carrick" <joe.carrick@dslextreme.com> wrote in message 
news:MJ2f7pWuFHA.6160@S15147418...
> Hi James,
>
> Our most advanced systems are running with Pentium4 processors with
> WinXP-Pro, SP2.  We have a variety of systems, some of them are older
> Win98-SE with lesser processors.
>
> None of the systems has any problem running a DOS 16-bit application.
> However, we will be moving this App to Xbase++ within the next year.
> Ou primary reasons for migrating this App is to take advantage of GUI,
> Graphic Printing, etc.
>
> The biggest problem is that most of the code was written without a
> declared Procedure or Function Name.  Each Procedure was a separate prg
> and called simply by the file name.  This worked in Clipper but made it
> very difficult to migrate to Xbase++.  Consequently it has been kept as
> a DOS App up to this time.
>
> -Joe
>
> James Loughner wrote:
>
>> Are you running a 64 bit processor. My understanding is the XP 64 does
>> not support 16 bit DOS applications. And Windows Vista definitely won't
>> even for 32 bit processors!!!
>>
>> Jim
>>
>> Joe Carrick wrote:
>>
>>> Hi James,
>>>
>>> We have a Clipper App that is still running just fine on WinXP_Pro
>>> with SP2.  The only problem is with newer Monitors where it's
>>> necessary to start it in a window and then change the properties to
>>> full screen so the mouse works properly.
>>>
>>> -Joe
>>>
>>> James Loughner wrote:
>>>
>>>> Joe, a reason might be that the new 64 bit OS's are not supporting 16
>>>> bit programs any more!!!!
>>>>
>>>> Jim
>>>>
>>>> Joe Carrick wrote:
>>>>
>>>>> Hi Rodd,
>>>>>
>>>>> What is your goal?  Do you want a GUI (WindowsTM) App or an App that
>>>>> looks like DOS?  If the latter, then the next question is why not
>>>>> stick with Clipper?  You will find that Clipper Apps are going to be
>>>>> faster, but you may have some problems with WindowsXP and newer
>>>>> Monitors.
>>>>>
>>>>> IMO, the GUI Object Oriented Environment ultimately provides a much
>>>>> more flexible App, but it also presents some new programming
>>>>> challenges.
>>>>>
>>>>> If you eventually want a GUI App then just bite the bullet and go
>>>>> directly to GUI.
>>>>>
>>>>> -Joe
>>>>>
>>>>> Rodd Graham wrote:
>>>>>
>>>>>> Raymond,
>>>>>>
>>>>>> But if I am migrating existing Clipper, wouldn't it be 'why do the
>>>>>> work once'.  Doesn't the VIO mode provide a functionally equivalent
>>>>>> operation to the Clipper app?
>>>>>>
>>>>>> However, with multiple suggestions to TopDown and Express++, I will
>>>>>> need to investigate prior to going GUI.
>>>>>>
>>>>>> Rodd
>>>>>>
>>>>>> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in
>>>>>> message news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>>>>
>>>>>>> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go
>>>>>>>> straight to
>>>>>>>> GUI with XbpCrt or make a detour to VIO?
>>>>>>>>
>>>>>>>> I assumed that VIO was the least disruptive to our production
>>>>>>>> enviroment,
>>>>>>>> but I don't get the impression that anyone else is using VIO apps.
>>>>>>>>
>>>>>>>> Rodd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would suggest you to go directly to GUI.
>>>>>>> Why doing the work twice ?
>>>>>>>
>>>>>>> And if you don't want to reinvent the wheel, try Clayton Jone's
>>>>>>> TopDown
>>>>>>> Library. It will save you hundreds of hours of work.
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Raymond Fischbach
>>>>>>> Belgium
>>>>>>> http://www.mouches.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 

Joe,

We have experienced three critical problems on WinXP sp2 with Clipper of 
which we have only solved one.  Clipper app is 5.2e, Classy 2.4b, Blinker 7 
linked, ADS 7.1 and .EXE is approx 2M.  App is deep with 50 routine call 
stack and 8-12MB live variables not unusual.

As app has expanded to more capability, 332 SVOS exhaustion errors have 
become a multiple time a day problem for all users.  We have not solved this 
problem.

Clipper app is hard to properly allocate CPU when idle and processing. 
WinXP introduced aggressive idle detection that backs off Clipper when it is 
actually processing.  Conversely, disabling idle detection destroys system 
performance by consuming CPU 100%.  This problem is solved via TameDos.

Windows XP introduced a DPMI memory anomaly in our configuration that causes 
periods of DPMI memory depletion during which the Clipper app becomes 
vulnerable to memory exhaustion.  We have confirmed the DPMI problem with a 
DPMI diagnostic utility.  Unfortunately, DPMI docs and solutions are very 
sparse.  We have not solved this problem.

It is at this point that the decision was made to migrate to Xbase++ to open 
up more runtime memory space.

Rodd

"Joe Carrick" <joe.carrick@dslextreme.com> wrote in message 
news:E22RmhVuFHA.1256@S15147418...
> Hi James,
>
> We have a Clipper App that is still running just fine on WinXP_Pro with 
> SP2.  The only problem is with newer Monitors where it's necessary to 
> start it in a window and then change the properties to full screen so the 
> mouse works properly.
>
> -Joe
>
> James Loughner wrote:
>> Joe, a reason might be that the new 64 bit OS's are not supporting 16 bit 
>> programs any more!!!!
>>
>> Jim
>>
>> Joe Carrick wrote:
>>
>>> Hi Rodd,
>>>
>>> What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
>>> looks like DOS?  If the latter, then the next question is why not stick 
>>> with Clipper?  You will find that Clipper Apps are going to be faster, 
>>> but you may have some problems with WindowsXP and newer Monitors.
>>>
>>> IMO, the GUI Object Oriented Environment ultimately provides a much more 
>>> flexible App, but it also presents some new programming challenges.
>>>
>>> If you eventually want a GUI App then just bite the bullet and go 
>>> directly to GUI.
>>>
>>> -Joe
>>>
>>> Rodd Graham wrote:
>>>
>>>> Raymond,
>>>>
>>>> But if I am migrating existing Clipper, wouldn't it be 'why do the work 
>>>> once'.  Doesn't the VIO mode provide a functionally equivalent 
>>>> operation to the Clipper app?
>>>>
>>>> However, with multiple suggestions to TopDown and Express++, I will 
>>>> need to investigate prior to going GUI.
>>>>
>>>> Rodd
>>>>
>>>> "Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in message 
>>>> news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>>
>>>>> On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>>
>>>>>
>>>>>> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go 
>>>>>> straight to
>>>>>> GUI with XbpCrt or make a detour to VIO?
>>>>>>
>>>>>> I assumed that VIO was the least disruptive to our production 
>>>>>> enviroment,
>>>>>> but I don't get the impression that anyone else is using VIO apps.
>>>>>>
>>>>>> Rodd
>>>>>
>>>>>
>>>>>
>>>>> I would suggest you to go directly to GUI.
>>>>> Why doing the work twice ?
>>>>>
>>>>> And if you don't want to reinvent the wheel, try Clayton Jone's 
>>>>> TopDown
>>>>> Library. It will save you hundreds of hours of work.
>>>>>
>>>>>
>>>>> -- 
>>>>> Raymond Fischbach
>>>>> Belgium
>>>>> http://www.mouches.org
>>>>
>>>>
>>>>
>>>>
>>>>

Hi Rodd,

Our Clipper App is 5.2e, Blinker 7 linked and App is (6) 600-900 KB 
EXE's which are overlayed from a single 500 KB EXE.  We don't use ClassY 
and we don't use ADS.  We have not experienced any of the problems you 
mention.

What is 332 SVOS exhaustion error?
What is DPMI memory anomaly?

Frankly, these sound like problems resulting from something other than 
Clipper per se.

-Joe

Rodd Graham wrote:
> Joe,
> 
> We have experienced three critical problems on WinXP sp2 with Clipper of 
> which we have only solved one.  Clipper app is 5.2e, Classy 2.4b, Blinker 7 
> linked, ADS 7.1 and .EXE is approx 2M.  App is deep with 50 routine call 
> stack and 8-12MB live variables not unusual.
> 
> As app has expanded to more capability, 332 SVOS exhaustion errors have 
> become a multiple time a day problem for all users.  We have not solved this 
> problem.
> 
> Clipper app is hard to properly allocate CPU when idle and processing. 
> WinXP introduced aggressive idle detection that backs off Clipper when it is 
> actually processing.  Conversely, disabling idle detection destroys system 
> performance by consuming CPU 100%.  This problem is solved via TameDos.
> 
> Windows XP introduced a DPMI memory anomaly in our configuration that causes 
> periods of DPMI memory depletion during which the Clipper app becomes 
> vulnerable to memory exhaustion.  We have confirmed the DPMI problem with a 
> DPMI diagnostic utility.  Unfortunately, DPMI docs and solutions are very 
> sparse.  We have not solved this problem.
> 
> It is at this point that the decision was made to migrate to Xbase++ to open 
> up more runtime memory space.
> 
> Rodd
> 
> "Joe Carrick" <joe.carrick@dslextreme.com> wrote in message 
> news:E22RmhVuFHA.1256@S15147418...
> 
>>Hi James,
>>
>>We have a Clipper App that is still running just fine on WinXP_Pro with 
>>SP2.  The only problem is with newer Monitors where it's necessary to 
>>start it in a window and then change the properties to full screen so the 
>>mouse works properly.
>>
>>-Joe
>>
>>James Loughner wrote:
>>
>>>Joe, a reason might be that the new 64 bit OS's are not supporting 16 bit 
>>>programs any more!!!!
>>>
>>>Jim
>>>
>>>Joe Carrick wrote:
>>>
>>>
>>>>Hi Rodd,
>>>>
>>>>What is your goal?  Do you want a GUI (WindowsTM) App or an App that 
>>>>looks like DOS?  If the latter, then the next question is why not stick 
>>>>with Clipper?  You will find that Clipper Apps are going to be faster, 
>>>>but you may have some problems with WindowsXP and newer Monitors.
>>>>
>>>>IMO, the GUI Object Oriented Environment ultimately provides a much more 
>>>>flexible App, but it also presents some new programming challenges.
>>>>
>>>>If you eventually want a GUI App then just bite the bullet and go 
>>>>directly to GUI.
>>>>
>>>>-Joe
>>>>
>>>>Rodd Graham wrote:
>>>>
>>>>
>>>>>Raymond,
>>>>>
>>>>>But if I am migrating existing Clipper, wouldn't it be 'why do the work 
>>>>>once'.  Doesn't the VIO mode provide a functionally equivalent 
>>>>>operation to the Clipper app?
>>>>>
>>>>>However, with multiple suggestions to TopDown and Express++, I will 
>>>>>need to investigate prior to going GUI.
>>>>>
>>>>>Rodd
>>>>>
>>>>>"Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in message 
>>>>>news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>>>
>>>>>
>>>>>>On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Did anyone (or everyone) who migrated Clipper apps to Xbase++ go 
>>>>>>>straight to
>>>>>>>GUI with XbpCrt or make a detour to VIO?
>>>>>>>
>>>>>>>I assumed that VIO was the least disruptive to our production 
>>>>>>>enviroment,
>>>>>>>but I don't get the impression that anyone else is using VIO apps.
>>>>>>>
>>>>>>>Rodd
>>>>>>
>>>>>>
>>>>>>
>>>>>>I would suggest you to go directly to GUI.
>>>>>>Why doing the work twice ?
>>>>>>
>>>>>>And if you don't want to reinvent the wheel, try Clayton Jone's 
>>>>>>TopDown
>>>>>>Library. It will save you hundreds of hours of work.
>>>>>>
>>>>>>
>>>>>>-- 
>>>>>>Raymond Fischbach
>>>>>>Belgium
>>>>>>http://www.mouches.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> 
>

Rodd Graham wrote:
> Joe,
> 
> We have experienced three critical problems on WinXP sp2 with Clipper of 
> which we have only solved one.  Clipper app is 5.2e, Classy 2.4b, Blinker 7 
> linked, ADS 7.1 and .EXE is approx 2M.  App is deep with 50 routine call 
> stack and 8-12MB live variables not unusual.
> 
We are in the process of migrating our application to Xbase++ GUI with 
Express++.  We are using 5.2e, blinker 6, ADS 6.11 and 4MB clipper exe. 
  We are using the clipper and Xbase++ application concurrently.

We do not have memory problems.  Idles is not a problem as we use 
FT_Idle with no problems.  Novell 5.1 network.

We do not use classy so the recompilation with Xbase++ was easy.  Made a 
few stub functions for libraries not available in 32bit.  We used a 
browse alternative called Clipx so we built a tbrowse alternative that 
was for compiling only as it did not provide all the functionality. 
Then started module by module converting to windows based on priority. 
Conversion has taken over 2 years because enhancements keep getting in 
the way of converting remaining modules.

text mode items would work in Xbase++ but are currently used in the 
clipper app when needed.  Users use both clipper and Xbase++ app.

Clifford,

I have tried FT_Idle() (and Blinker 7 Idle, OsLib Yield()) and have never 
been satisfied with results.  All seem to use a counter loop that is 
somewhat dependent on CPU speed.  I use dual 2.8Ghz Xeon which always seemed 
to go 50% CPU is clipper app running but idle.  Idle for us was a two way 
problem since XP had idle detection that results in CPU starvation during 
batch processing with ADS since it did not seem that netbios activity (ADS 
on TCP/IP) would disengaged XP brake.  Keyboard and mouse events would 
disengage brake.

Did you have any binary data in ADS?  If so, how did you address the 
oem/ansi character set issues when switching to Xbase++?

Rodd

"Clifford Wiernik" <cwsoft@charter.dot.net> wrote in message 
news:%2328C$CauFHA.6160@S15147418...
> Rodd Graham wrote:
>> Joe,
>>
>> We have experienced three critical problems on WinXP sp2 with Clipper of 
>> which we have only solved one.  Clipper app is 5.2e, Classy 2.4b, Blinker 
>> 7 linked, ADS 7.1 and .EXE is approx 2M.  App is deep with 50 routine 
>> call stack and 8-12MB live variables not unusual.
>>
> We are in the process of migrating our application to Xbase++ GUI with 
> Express++.  We are using 5.2e, blinker 6, ADS 6.11 and 4MB clipper exe. We 
> are using the clipper and Xbase++ application concurrently.
>
> We do not have memory problems.  Idles is not a problem as we use FT_Idle 
> with no problems.  Novell 5.1 network.
>
> We do not use classy so the recompilation with Xbase++ was easy.  Made a 
> few stub functions for libraries not available in 32bit.  We used a browse 
> alternative called Clipx so we built a tbrowse alternative that was for 
> compiling only as it did not provide all the functionality. Then started 
> module by module converting to windows based on priority. Conversion has 
> taken over 2 years because enhancements keep getting in the way of 
> converting remaining modules.
>
> text mode items would work in Xbase++ but are currently used in the 
> clipper app when needed.  Users use both clipper and Xbase++ app.

Rodd Graham wrote:
> Clifford,
> 
> I have tried FT_Idle() (and Blinker 7 Idle, OsLib Yield()) and have never 
> been satisfied with results.  All seem to use a counter loop that is 
> somewhat dependent on CPU speed.  I use dual 2.8Ghz Xeon which always seemed 
> to go 50% CPU is clipper app running but idle.  Idle for us was a two way 
> problem since XP had idle detection that results in CPU starvation during 
> batch processing with ADS since it did not seem that netbios activity (ADS 
> on TCP/IP) would disengaged XP brake.  Keyboard and mouse events would 
> disengage brake.
> 
> Did you have any binary data in ADS?  If so, how did you address the 
> oem/ansi character set issues when switching to Xbase++?
> 
> Rodd
> 
> "Clifford Wiernik" <cwsoft@charter.dot.net> wrote in message 
> news:%2328C$CauFHA.6160@S15147418...
> 
>>Rodd Graham wrote:
>>
>>>Joe,
>>>
>>>We have experienced three critical problems on WinXP sp2 with Clipper of 
>>>which we have only solved one.  Clipper app is 5.2e, Classy 2.4b, Blinker 
>>>7 linked, ADS 7.1 and .EXE is approx 2M.  App is deep with 50 routine 
>>>call stack and 8-12MB live variables not unusual.
>>>
>>
>>We are in the process of migrating our application to Xbase++ GUI with 
>>Express++.  We are using 5.2e, blinker 6, ADS 6.11 and 4MB clipper exe. We 
>>are using the clipper and Xbase++ application concurrently.
>>
>>We do not have memory problems.  Idles is not a problem as we use FT_Idle 
>>with no problems.  Novell 5.1 network.
>>
>>We do not use classy so the recompilation with Xbase++ was easy.  Made a 
>>few stub functions for libraries not available in 32bit.  We used a browse 
>>alternative called Clipx so we built a tbrowse alternative that was for 
>>compiling only as it did not provide all the functionality. Then started 
>>module by module converting to windows based on priority. Conversion has 
>>taken over 2 years because enhancements keep getting in the way of 
>>converting remaining modules.
>>
>>text mode items would work in Xbase++ but are currently used in the 
>>clipper app when needed.  Users use both clipper and Xbase++ app. 
> 
> 
> 
We use IPX and did not experience problems.  FT_Idle worked beter than 
OsLib Yield().  Did not attempt to use IP as it was said to be slower.

No binary data that I am aware of.  Just standard character data.  No 
memo files.

hi,

> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go
> straight to  GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment,
> but I don't get the impression that anyone else is using VIO apps.

i think this is not Developer choise while you have to look what User
are doing which that application.

If a User wanted to do 200 data entry/min, they cant do it in GUI ... to
slow
( they refuse to work with it and use a Mouse instead of keyboard )

If a Boss wanted to have some charts, he did not like data entry ... he like
big buttons to click and get result.

so i have "split" my application in "data entry" ( keyboard, using numpad )
and "data result" like reports and chart in pure GUI.

this make it easy to keep my "data entry" application Cl*pper compatible
so i can use it as "backup" . If M$ Windows total crash, i can boot from
Floppy Disk using RamDisk an connect to the Novell Server and do "data
entry"

greetings by OHR
Jimmy

AUGE_OHR wrote:

> hi,
> 
> 
>>Did anyone (or everyone) who migrated Clipper apps to Xbase++ go
>>straight to  GUI with XbpCrt or make a detour to VIO?
>>
>>I assumed that VIO was the least disruptive to our production enviroment,
>>but I don't get the impression that anyone else is using VIO apps.
> 
> 
> i think this is not Developer choise while you have to look what User
> are doing which that application.
> 
> If a User wanted to do 200 data entry/min, they can´t do it in GUI ... to
> slow
> ( they refuse to work with it and use a Mouse instead of keyboard )
> 
> If a Boss wanted to have some charts, he did not like data entry ... he like
> big buttons to click and get result.
> 
> so i have "split" my application in "data entry" ( keyboard, using numpad )
> and "data result" like reports and chart in pure GUI.
> 
> this make it easy to keep my "data entry" application Cl*pper compatible
> so i can use it as "backup" . If M$ Windows total crash, i can boot from
> Floppy Disk using RamDisk an connect to the Novell Server and do "data
> entry"
> 
> greetings by OHR
> Jimmy
> 
> 
We designed our clipper conversion to Xbase++ with Express++ to use the 
same keyboard functionality and compatibility, plus addition of the 
mouse.  It is quite successful.  Speed of data entry is almost the same 
as the clipper application except when windows/tab pages change as the 
user must pause momentarily.  The user does have to pause momentarily 
when if a multi-tab page form while the forms goes back to page one to 
avoid lost keystrokes, but it is more than acceptable.  And a mouse is 
basically never needed, but can be used when desired or for going 
directly to an input field.

I have converted several Clipper 5.2 apps to Xbase++ and many of them 
were done using xbpCrt, mainy because:
   1. The users wanted as little change as possible.
   2. It is hard to beat Clipper data entry screens for speed.
   3. I can do that type of conversion pretty quickly these days (a 
couple of days) so it costs the client much less.

The main reason for converting at all has been the need for Windows 
printing. Using TopDown for this has enabled me to convert the old 
Clipper @ say reports very quickly as well.

New projects I do GUI from scratch.

That said, I haven't converted my own accounting system yet - I think it 
has something to do with shoemakers barefoot children. I DID have to 
make one change last year so that it wouldn't eat up all the CPU cycles 
on XP machines but I only had to add one line to the main program:
    FT_OnIdle({||FT_IAmIdle(30,.T.)})	 04/10/22
and change my link script:
*****************
OUTPUT PCLUS.EXE
BLINKER INCREMENTAL OFF
BLINKER EXECUTABLE CLIPPER F60
BLINKER EXECUTABLE COMPRESS
FI WW_Main
FI \cl52\obj\iamidle
FI WW_Msc, WW_GL, WW_Stk, WW_Clien, WW_PO, WW_SlDoc, WW_AP, WW_AR, ww_Stmnt
FI WW_GlMst, WW_Dist, WW_Aging, WW_Sale, ww_TrHis, WW_ARPay, WW_MChq, 
ww_VStk, WW_Comm
FI \cl52\source\ww\pcl\PCL_Sls, \cl52\source\ww\pcl\pc_bom, 
\cl52\source\ww\pcl\pc_lot
FI \cl52\source\ww\new\ww_pkg, \cl52\source\ww\pcl\pc_locat, 
\cl52\source\ww\pcl\batchrep
FI \cl52\source\ww\pcl\ordentry,\cl52\source\ww\pcl\alloc
FI \cl52\source\ww\new\ww_cpric,\cl52\source\wwobj\ww_tbfw
FI \cl52\source\ww\pcl\oe2inv
FI \cl52\obj\OnTick, \cl52\obj\PopUpCal
LIB \cl52\lib\cl52proc, \cl52\lib\NanFor3, \cl52\lib\Netto
LIB \cl53\lib\cpmi
******************************
If I can be of help, feel free to ask.
Garry


Rodd Graham wrote:
> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight to 
> GUI with XbpCrt or make a detour to VIO?
> 
> I assumed that VIO was the least disruptive to our production enviroment, 
> but I don't get the impression that anyone else is using VIO apps.
> 
> Rodd 
> 
>

Hi Gary (and Rodd),

>    2. It is hard to beat Clipper data entry screens for
speed.

That's basically true and very hard to beat in specific
cases.

IMO:

1.  VIO is almost totally obsolete (unless you need a fast
direct migration direct port of 16-bit to 32-bit for
whatever reason).  But that should be viewed as very
short-lived.
2.  Hybrid mode is actually a marvelous compromise and the
best of both worlds in some cases.  Under Xbase++, it still
has a lot of life left to live .
3.  Full GUI looks nice and may be expected for modern apps
but it means a leap in code development, requires more
controls for procedural integrity in some (expected and
required) straigth-line end results, and a complete change
in programming and user mentality to deal with event-driven
processing.

Robert

We look at every possible XBase mode, and also at every possible language!

We decide to go directly to XBase GUI because:
- We wanted to integrate external tools directly in our apps, like Crystal 
Report, Words, Excel, Acrobat, AutoCAD, Cadcam, ...  ActiveX was not ready 
at that time (and still today!) so I had to use some C behind the scene.
- We wanted to let our user open many windows side by side, while a report 
is turning in the background
- We wanted new customers! Try to sell a DOS looking app today!
- With XBase 1.1, XbpCrt was slow, XbpDialog was the same speed but with a 
nice look

Our application are used mainly in factory.  Users don't even look at the 
screen, they only type numbers one after an other.  The exception are the 
manager who are really happy to be able to monitor everything with some 
graphics.

Hi Mr Rodd

    We migrate a large application from Clipper to Alaska using a mix 
implementation;
    . Screen form fields Editing -> CRT mode (@ say get)
    . Browse - Gui Mode
    . Messages - Gui Mode

    You can migrate fastly using Topdown library for gui
functions and reports...

    Anyway, if you have time, you can attempt to migrate
do Gui mode all aplication. I plan to migrate to total Gui
mode, on next year... but now I already am selling my system...

    Osvaldo L Aoki
    osvaldo@aoki-sis.com.br

"Rodd Graham" <rodd@tpmco.com> escreveu na mensagem 
news:5D5Le6KuFHA.5608@S15147418...
> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight 
> to GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment, 
> but I don't get the impression that anyone else is using VIO apps.
>
> Rodd
>

I have over 80 (similar but not the same) systems all of different ages and
styles written in Clipper.  I have been migrating them and Unifying them to
ONE Xbase++ system over the last year and so far have only completed 6 of
them.  I use GUI in the Hybrid mode so I can still use @..say / @..get.  The
main advantage of this is that I can still use, xbpListBox(),
xbpPushButton() and print graphical reports but the data entry screens are
still very user friendly with very little change.

[PROJECT]
    COMPILE       = xpp
    COMPILE_FLAGS = -q
    DEBUG         = yes
    GUI           = yes
    LINKER        = alink
    LINK_FLAGS    =
    RC_COMPILE    = arc
    RC_FLAGS      = -v
    ROOT




"Rodd Graham" <rodd@tpmco.com> wrote in message
news:5D5Le6KuFHA.5608@S15147418...
> Did anyone (or everyone) who migrated Clipper apps to Xbase++ go straight
to
> GUI with XbpCrt or make a detour to VIO?
>
> I assumed that VIO was the least disruptive to our production enviroment,
> but I don't get the impression that anyone else is using VIO apps.
>
> Rodd
>
>