FoxPro button status

[mmerlinn]

Is there a way in FP (and maybe VFP) to test the status of a push button, that is to return whether a button is ENABLED or DISABLED?

 

[Scott24x7]

mmerlin,
This is a case where (and you did say FP2.6 - VFP, I just haven't had a chance to respond to this yet).
As many have pointed out the key difference between FP2.x and VFP is object orientation.
What is of course, cool, about FP though is that it has some of those "pre-cursors" to OOP, and that it has an EVENT MODEL.
So when you have something like READ EVENTS (and I'm going back almost 30 years here... I haven't thought about this in a long time, but still have some bits I maintain), that READ EVENTS is a loop that continues until you get to CLEAR READ if I recall correctly.

So, the way you can control this in FP2.6 is to have (usually) a global variable (don't beat me up everyone), that once you initiate "editing" you set some value like M.Editing = .T.
You keep this state until you're not editing any longer, when you do something like click a SAVE or CANCEL button, where you set M.Editing = .F.

REFERSH() is still a call we make A LOT in FP2.x. (And even at FP2.x)

On the Button's VALID clause, you can sate
*
IF M.Editing
MYBUTTON = DISABLED
ELSE
MYBUTTON = ENABLED
ENDIF

I believe the button has an m.memoryvariable to identify it, but I could be wrong, it's been a LOOOONG time since I had to do one of these, and the machine I'm on at the moment only has VFP applications on it, I'm not in my office where the archive for the old FOX apps are.

 

[Chris Miller]

It's not really plausible to me, though, why you could create a button rendered disabled, to not have anything that could enable it but removing it and replacing it with a new enabled button. The only justification for a disabled button is to show there is a way to enable it. The only reason a button stays disabled for a user not having permissions to ever use the button is envy on users with higher priviledges :^). Well, seriously, it would only tell such a restricted user there is a feature to be unlocked, be it with added/highered permissions or an upgraded license.

So I can understand how mmerlin has this question, because disabled buttons in a UI have very limited purpose when they can't be enabled, don't they?

It's plausible if there is another way to set a disabled buttton enabled somehow.

There's this line in the help:

To disable a single push button, place two backslashes (\\) before the button's prompt.

So maybe when that's used you could change the prompt to the same without \\ prefix and enable a button that way. The question now is how to change a button prompt or make it dynamically depend on a variable you can change.

The only other area of VFP where prompts ring a bell to me are menu item prompts and isn't there a way to change a menu item prompt without redefinig the item?

 

[Scott24x7]

Chris,
That's fine for VFP, but that option didn't exist for FP2.6.
You couldn't hide objects on the form. Buttons have a minimal set of "Events" and being enabled or disabled is one of them.
There's no OOP in FP2.6. Buttons are a special "object" in the environment, which had (If I recall correctly), 4 events associated with them. VALID, WHEN, READ, and CLEAR? (Sorry it's been ages). We had to do things like DO SCATTERVARS, DO SHOWGETS in order to "refresh" the form.
But the button did respond to a mouse click, but that was really controlled by VALID there wasn't a "click" event.
In any case, Object.Property.property doesn't exist in FP2.6.

 

[Chris Miller]

I already got aware of that, I think in the abilities of the help topic for lkegacy@...GET and prompts being prefixed \\ to disable a button. If you could make a prompt be a variable that changes, when the variable changes, you could use that to en/dis-able the button, but I doubt that's available. Perhaps a function that retuns the prompt with or without \\ prefix? I doubt that works, too, as you have no event that would call that function at specific times. So I guess the prompt is as given with the @...GET command and can't dynamically change, unless there' s some SYS() or SET command. But how would you refer to which button? It would need a name or any identifier and I don't see anything like that, the only thing you have is the button number from the nummber of prompts, but then you'd still need to somehow address the button number of which @...GET command button group. I don't see how it could work, so it seems Joes solution is the only way to get there.

Or switch to VFP. Of course that's not available on a Mac.

 

[Scott24x7]

Hi Chris, like I mentioned, the ability to enable/disable a button exists in FP2.6, but the ability to Hide/Show the button (Visible = .T./Visible = .F.) does not.
You set up a control variable in the screen (it still uses .SCX) (called screens instead of "forms") which holds a "global" variable. I always called mine M.EDITING. I'd then check the status of that variable (it would initially be set to .F.) If M.EDITING is False, then the "Edit" button would be enabled, but the "Save" button would be Disabled, because there is nothing to "save". Once you click "Edit" the first thing it would do would be to change the "state" (status) of the form to M.EDITING = .T. One of the last bits of code that would be executed in the "Snippet" would be a call to DO SHOWGETS (which was a routine much like the code you'd use in the "Refresh" event. FP2.6 essentially has Methods, but not Events (or at least the Event model is fixed by the READ EVENTS).
So you have some control, and FP2.6 would "grey out" your disabled buttons. IN FPW2.6 you can still give it a picture clause to determine what image is shown based on the state. You couldn't do this in FPD2.6 though.
Surprisingly the "leap" is there, but because FP2.6 had implemented a limited event model, (It was "Event Driven") The VALID and WHEN clauses where key to program flow, unlike (exactly like) they are in VFP, but in VFP we rarely use them because there are better events, for other than "rejecting" entry to the object.
Man, this is REALLY making me think back.

 

[cumminsm]

Cool online shopping offers a modern, engaging, and personalized experience that goes beyond the basics of traditional e-commerce. It combines sleek website design, intuitive navigation, and innovative features like personalized recommendations, virtual try-ons, and fast checkout processes. Shoppers can discover unique, trendy products while enjoying interactive elements that make the experience more immersive

 

[Chris Miller]

but the ability to Hide/Show the button (Visible = .T./Visible = .F.) does not.

I didn't talk about hiding or showing buttons. I don't know where you have your eyes, Scott, I quoted the lagacy help expliitly mentioning how you can enable/disable (that's not showing/hiding) Buttons done with @...GET by setting prompts (that's captions, I think) with \\ prefix or not:

To disable a single push button, place two backslashes (\\) before the button's prompt.

I think you can only set the prompt when issuing the command, it can't be dynamic. Maybe you can, but mmerlin should know that better than me.

I appreciate your mentioning of DO SHOWGETS, maybe that can be used to also refresh the prompts, I don't see how, though and what triggers it.