CANCEL command unresponsive 1

[bfwriter]

Hi Guys,
I'm an experienced non-professional FoxPro user for over 25 years. And here's a real head scratcher. I just now started a quickie construction of a simple form to display a list of values... of the kind I've done zillions of time in the past. And I've run into this weird problem... The CANCEL command is non-functional... dead in the water. The QUIT command responds normally, but the CANCEL will not. On a quick run through a couple of other Foxpro apps in my system, the CANCELs all work normally.

After several unsuccessful searches and trials, to test this further, I put together a basic blank form with no controls except a single command button with CANCEL in the click procedure. It's still dead. Then I traded a QUIT command in the click and the the Quit works normally.

I rebooted my computer (WIN7), and CANCEL is still dead.

Any ideas here?

Thanks much,
Bill
Rochester, Michigan

 

[Mike Lewis]

Bill, what exactly are you expecting CANCEL to do? In your test scenario, I would expect the CANCEL to exit the Click event of the button, but not necessarily terminate the entire application or even close the form. So, after clicking the button the form would still be on the screen, and it would respond to other events (if any).

Come to think of it, I don't think I have ever used CANCEL in a program. I would use QUIT to terminate the application, or RETURN to come out of a method or function (I'm sure you knew that).

One other point that might be relevant is whether you are in an event loop when you execute the CANCEL (that is, if a READ EVENTS is active). I'm not sure what the effect of that would be on the CANCEL, but it should be easy to check.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Indeed, the help on cancel says in the IDE it's exiting currently running code and returns to the command window, in an EXE it cancels all code and exits like quit.

But in a short test, yes, cancel doesn't exit a form, that's done with THISFORM.RELEASE()

There's a totally different meaning of the cancel property of a button, it's meaning is to be activated by the ESC key and to cancel (undo) changes before exiting. The technical function is to let ESC trigger the click event of a button with button.cancel=.t.

I have to say like Mike, I use QUIT to exit an application, but indeed all you need is to let main.prg end, which could happen just because it ends, without a cancel, quit. Not even a return is necessary.
The reason to use quit is more about reacting to windows message of a shutdown with ON SHUTDOWN. This unfortunately has quite a smeared meaning in VFP, though, the SHUTDOWN event also happens when you click the close (X) button of the _screen form and that's not a system shutdown, just an exit of the application. Also, QUIT does trigger the VFP internal SHUTDOWN event (it doesn't shutdown Windows, of course).

Okay, but coming back to your question, since you want to close a form, perhaps, that's done with Thisform.Release(). And then I think it's your first time using winforms and on top of learning about the release method, you should look into form events, when you do release a form, there are still a few events happening, in which you can also ode something, there's QuerUnload(), there's Unload() and Destroy(). Read about them in the help.

One good design is to use non modal forms and start either menu or menu and main form in the main.prg, then do READ EVENTS to establish a state waiting for events and if you have a main form which should end the EXE when it's closed, one simple thing to do is CLEAR EVENTS in its Unload() event. Then the code after READ events runs and could handle things like open transactions (see TxnLevel) and then, as said initially, you need no cancel, no quit, not even return. If the code in main.prg ends, that ends the EXE.

Chriss

 

[bfwriter]

Thanks for your comments, Mike and Chris. I'm sorry not to have clearer on my CANCEL problem. I expect a CANCEL command to cease processing of a Form and return to the IDE and Command Window for visual editing. I usually add a CANCEL command button to forms when they are new, during the months (or longer) during which I expect to encounter glitches that require some program adjustment.

The problem here and now is that the CANCEL command added to a newly developing form is totally unresponsive, while the Form and its other controls remain responsive in all other respects. (Quit works normally, closing the Form and the IDE, returning to Windows screen.) This has never before happened in my 25 years of using Foxpro. And this use of the CANCEL has always been for me a standard inclusion in a newly developing program.

Since posting my question I have realized that (duhhh) the square "X" button ("Close") at the top right of the Foxpro screen achieves the same response as the CANCEL has always done for me. So I am using it now in place of the dead CANCEL.

Many thanks for your patience.

Bill
Rochester, Michigan

 

[Chris Miller]

Good you got workaround,

but for short checking with a bare form just with a button having CANCEL in its click, this does nothing. That's by design, it works for PRGs, but not for forms.
You have to use Thisform.Release() in forms.



Chriss

 

[TamarGranor]

@bfwriter, perhaps it's been a while since you've done this. Cancel in the Click of a button has never done what you're describing. However, if you create a button, and set its Cancel property to .T., and put ThisForm.Release() in the Click, you can close your form simply by hitting ESC.

Tamar

 

[Chris Miller]

Thanks, Tamar.

That confirms what I think. Maybe you used this in screens, but not in forms. So your memory serves you wrong or you only used this in screens.

The close button (that's what the red X in the title bar is called in Forms, also for the _SCREEN form) is working for single forms inside the screen, too, yes.
I would point out that when you maximize an in-screen form, you get this look:

(Yes, in Win10 the _screen has Win10 look and the in-screen form a vista look)

These close buttons are pretty easy to mis-click. So a close button in the form isn't wrong. As said it just needs Thisform.Release() in it.

You can have the cancel-button clicked by ESC, but also a default-button clicked by ENTER.
See the Cancel and Default properties and their description in the help for details (for example about how ENTER works within an editbox contrtol).

Chriss

 

[Mike Lewis]

I agree with everything that Tamar and Chris have said. In addition, let me point out that if you are developing a (non-modal) form and running it within the IDE, the quickest way to close it and return to the form designer is to click the Modify Form button in the main toolbar (this is the buton with an image of a set square and pencil).

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[bfwriter]

Many thanks to all for the help here.. especially to Chriss whose simplified advice clarified for me a misconception that I've carried since forever, namely that, as used in FoxPro, a Form is NOT synonymous with a Program. It's that that lead me astray. I think that error stems from my earliest steps in learning programming back in the early 1980s with QuickBasic, where, as I recall dimly, everything was a "program".

Thanks to you folks, and your patience with an old amateur, I'm now both happier AND wiser!

Bill
Rochester, Mich.

 

[Chris Miller]

Thanks for your feedback, very much appreciated.

Yes, forms are the replacement for screens of early FoxPro versions, and as far as I know screens also have scx file extension, but are mainly PRGs. Perhaps more like menus that are only turned into PRGs with GenMenu, I think there is GenScreen for that. That's not the case since Visual Foxpro, I mean there is no Genscreen anymore and SCXes are data about the controls and code of a form, mainly a Winform. So your idea could come from there. A Cancel might work in a screen, but not in aq form.

Just one more word on the Close and Cancel properties of commandbuttons: This relates to the concept of Windows Design Guidelines regarding an OK (Close and Save) and a Cancel (Close but revert any changes or not save them). See

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/bb246415(v=vs.85).

The functionalities of save or revert are not automatic, that's very individual, but the ESC and ENTER keys are mapped as they are in other Windows system dialogs, too. For example try ESCC and ENTER with the dialog of a network adapter. I think as far as Microsoft itself diverted from many of this you're not forced to make use of it. If you tell users ESC and ENTER are hotkeys in Windows I guess you mostly will see puzzled faces, if anything is standard then copy&paste.

Chriss