Foxpro 2.6 tables

[MelanieParent]

I have an order entry screen that looks a bit like that :
prod(1) description (1) qty(1) price(1)
prod(2) description(2) qty(2) price(2)
...
For 13 lines. So I have quite a few arrays.

The company wants to be able to enter up to 30 products on an order. So I would like to change it to ressemble an excel table, so that the screen is the same size but we could scroll up and down. Also, some fields need to have validation (the product number field must exists in a dbf, and the description is put up automatically).

Can I do something like this ? And how ?

Thank you so much for your help !

 

[JRB-Bldr]

If, as this language-specific forum area implies, this is being developed in FoxPro (old versions 1 to 2.6), then you need to define a Window and do a BROWSE within that window - most likely all contained in a FP Screen.

If, however, you are using one of the newer Visual Foxpro versions, then:
1. You are in the wrong language-specific forum area
Your question should be posted in: forum184
2. You will create a Visual Foxpro Form and put a Grid in it - setting up the proper Cursor/Table as the RecordSource
3. You might want to look over Creating a Form Manually in:

http://www.garfieldhudson.com/FreeVideos.aspx

the product number field must exists in a dbf, and the description is put up automatically
Regardless of which version of FP/VFP you are using, you get to write your own code to Validate the data entry against an existing Data Table and, if found, populate the Description.

Good Luck,
JRB-Bldr

 

[MelanieParent]

Yes, it is in FoxPro 2.6. I'll try the browse window, I thought you couldn't add to it only see the content of the table that's why I didn't try browse (and not really familiar with it also).

Thanks !!

 

[JRB-Bldr]

Unless it is absolutely necessary I would recommend that you get away from FP 2.6 and convert your application to one of the Visual Foxpro versions (preferably VFP9)

It has been SO Long since many of us used FP2.6 that for us to even remember how to do things in that OLD version is a challenge.

The challenge you will face is how to issue your APPEND BLANK to the data table you are viewing in your BROWSE window.

Typically this is done within a FP Screen and uses a Button to initiate the ADD RECORD. Then that button's Valid Snippet will have code in it to issue the APPEND BLANK command.

Many times the new data is written into text box fields and the ENTER button snippet does the APPEND BLANK and REPLACE <whatever> to enter the data which can then be viewed in the BROWSE window.

Good Luck,
JRB-Bldr

 

[MelanieParent]

Thank you so much for your help, I'll try to work on that today and make it work.

And I know that I should switch over to the new versions... I do have have VFP 9.0 on my computer and haven't had time to look a lot into it. I tried converting one screen from 2.6 to VFP 9.0 and I think I'll be better off starting from scratch. With a hundred or so screens, it's a task that I've been pushing aside for too long. I guess it'll have to be done.

Thanks !!

 

[JRB-Bldr]

I tried converting one screen from 2.6 to VFP 9.0 and I think I'll be better off starting from scratch.

I wholeheartedly agree.

The 'conversion' routine is far from perfect and does not, by itself, really result in executable code.

Fortunately the code itself, for the most part, is fully compatible with the newer versions.
It maybe will not be as optimized as can be with the Visual versions, and the code may need to go in other places (e.g. FP Screen Snippet code --> VFP Form Method code, etc.) but it executes the same.

Good Luck,
JRB-Bldr

 

[DSummZZZ]

I tried converting one screen from 2.6 to VFP 9.0 ...

For what it's worth, and I do agree with JRB-Bldr, my personal opinion is the conversion routine makes the code cumbersome to deal with, but is great for taking the converted screen and copying/pasting the layout onto a new form without pageframes, containers, and extraneous code.
In other words, I found it to be more work to make the converted screen behave properly than to just copy the layout and copy some of the code from the converted form into the new one. Not quite conversion but not quite starting from scratch.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

>I think I'll be better off starting from scratch. With a hundred or so screens, it's a task that I've been pushing aside for too long.

See:

http://www.alvechurchdata.co.uk/company/foxconvert5.html

Technically it's preferable to start from scratch, or as the article says "In an ideal world, this (rewrite) would be the best solution."

That's even more true in a case you are upgrading 7 versions, that's not working nicely. But I doubt you can do 100 screens from scratch and leave users with the old application for the time you need to reimplement.

The doing nothing option is an option you can start with, when you set the most important settings to let forms, reports and sql work as older versions did:

SET REPORTBEHAVIOR 80
SET ENGINEBEHAVIOR 70
_SCREEN.THEMES = .F. && OR SYS(2700,0)

Especially turning off themes will make your screens look more familiar. Reportbehavior has had a major change in VFP9, SQL behavior has changed in many versions, but 70 is the most compatible with any sql you may have, if you have any sql at all.

Maybe also look into SET COMPATIBLE, but I think coming from FP2.6 the default OFF is better, this setting rather is for developers, which came from dbase or foxbase.

Bye, Olaf.