Hidden screen fields

[kiglid]

Can someone tell me the best way to hide or otherwise make a field invisible on a screen?

TIA

 

[rgbean]

What version of FoxPro (DOS or Windows?) and are you using .PRG code or .SCX screens? Do you want this always invisible, or to conditionally turn it on and off? What kind of field (e.g. GET, SAY, EDIT, LINE, etc.)?

Rick

 

[kiglid]

I'm using FoxPro 2.6 for Windows. The coding is done through the .SCX screens and I want the field to be always invisible. It is a GET field. Thanks.

 

[rgbean]

OK, now you've got my curiousity - what good is a GET field that can't be seen? Is the user suppose to be able to tab or mouse into it?

Rick

 

[JRB-Bldr]

Rick (rgbean) is correct, it is not a usual way to place a GET field.

Regardless.......

I just did a
HELP INVISIBLE
in the FPW command window and it brought up a screen labeled:
@... GET - Invisible buttons command

It describes how to make a button invisible.

You will need to begin the GET's Function statement with
*I

If you create the invisibility within the GET's Picture statement, begin it with a
@*I

Look at the complete Help contents for a full description.

Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[kiglid]

Long story. I have to use two fields for the same value. The field where the users select the value has to have a specific name in order to use the look up function (which i'm not about to rewrite). Then I transfer that value to the other field for saving, which is the field on the table. That probably doesn't make sense, but this application wasn't written that well to start with and I just get to maintain it and fix it for our users. What I've now been able to do is have the fields overlap each other on the screen so only one is visible, the one they use to actually select the value.

 

[JRB-Bldr]

I would recomment that instead of using Invisible fields, you might want to consider using a separate memory variable for your SaveToDBF value. You do not need two GET Fields for the same value, merely two memory variables.

You could initialize 2 unique memory variables (example: m.SaveToDBF and m.UserEntered) for the before entering the screen. m.SaveToDBF does not need to be displayed on-screen (or in an Invisible GET). That initialization could be to a default value or to the value already existing in the associated table.

Then within the screen itself, you can assign m.SaveToDBF a new value within the Valid function of the m.UserEntered's on-screen GET (or within part of a Save function within the screen Cleanup). m.SaveToDBF's assigned value can be the same as the m.UserEntered or it can be a "massaged" value.

In that way you would not need to mess with Invisible GET fields which do not add any functionality, but are being considered merely to hold a "massaged" value.

Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com