Dialog box closes prematurely

[dboggs]

Still trying to learn all about dialog boxes, as supported by IVF (not API). My project has a list box, an edit box, and the usual OK and Cancel buttons. When the user is working in the list or edit box, and mistakenly presses <enter>, the dialog will close. I want it to close ONLY with OK or Cancel button. What is wrong? I hope it's something simple and stupid because this is the usual desired behavior, but I can't find anything in the documentation that discusses it.

[andrew_4619]

That is  default action on <enter> for the dialog control. One of the properties in the resource editor changes that."want return" springs to mind....

The sure fire way is to have a callback defined for the  list control so that becomes the default action, even if it does nothing which I guess is what you want.

[dboggs]

app4619, thank you!

For the edit box control there was indeed a Want Return property. I set it by adding the phrase ES_WANTRETURN phrase in the EDITTEXT portion of the Dialog definition portion of the dialog_name.rc file. It was exactly what I needed. I wouldn't have guessed that this was the relevant property--great job in suggesting it.

For the list box control there apparently is no such property. There is one called Want Key Input but it doesn't do what I want (in fact it doesn't appear to do anything). So, I will pursue the callback routine for this one. Are you suggesting that the callback setup would look something like this:

lreturn = DLGSETSUB (dlg, IDC_LIST, DoNothing)
:
CALL DoNothing (dlg, IDC_LIST, DLG_CHANGE)
:
SUBROUTINE DoNothing (dlg, control_name, callback_type)
USE DFLOGM
TYPE (dialog) dlg
INTEGER :: control_name, callback_type
! Do nothing
END SUBROUTINE DoNothing

I'm pretty new at this, and the documentation is quite sparse. I feel like a beginning pilot student flying blind and solo (except for help from you and others on this forum) . I had thought perhaps this problem was a callback issue but hadn't pursued it because my documentation states "Each control in a dialog box, except a pushbutton, has a default callback that performs no action." We shall see.

[andrew_4619]

the CALL donothing is not needed. Quiclwin will call donothing automatically if there is an event on that control instead of the preset action which appears to be to exit the dialog.  

I sounds like you don't use the graphical resource editor and manually maintain the .rc file from a text editor maybe? I don't ever see things such as ES_WANTRETURN as I never look in the RC file,  I just set the relevant properties TRUE or FALSE in the GUI. 

The lack of a resource editor is VS shell is a real pain. I used to use resedit but there are things it cannot do that I need. VS Community works well if you are eligible to use it.is 

[IanH]

What do you want to happen when the user has an item in the list box control selected, and then they press Enter?

Each dialog has a default push button, which is typically the Ok button, and keying Enter is equivalent to pressing that button (and that is the behaviour that users will expect!).  But you can change that - see the BS_DEFPUSHBUTTON style.

[dboggs]

When the user presses Enter I want nothing to happen. I want the dialog to close ONLY when the user presses the OK button.

Why? because it's too easy for the user to press Enter accidentally, instead of taking the decisive action of clicking on the OK button. This is especially true for a multiline edit box, for example, where the user will be entering several lines of text items and may carelessly press Enter after each one (which by default closes the dialog) instead of Ctrl-Enter (which allows him to safely move to the next line). Well, that problem for the edit box was solved by setting the Want Return property. But I want the list box control to work the same way and there isn't such a property for that. Note that it is a multi-select list box, so I don't want it to close by surprise before all of the selections are made.

Adding BS_DEFPUSHBUTTON to the list box control definition in the rc file does not seem to have any effect.

I also tried removing the "Default button" property from the OK pushbutton control, but that didn't work either.

app4619: if calling DoNothing is not needed, then what should the callback routine do? "The sure fire way is to have a callback defined for the  list control so that becomes the default action, even if it does nothing"

[andrew_4619]

dboggs wrote:

app4619: if calling DoNothing is not needed, then what should the callback routine do? "The sure fire way is to have a callback defined for the  list control so that becomes the default action, even if it does nothing"

When you hit enter "donothing" will be called automatically by the Quickwin system if it donothing is registered as the callback for that control, You should not be explicitly calling donothing was all I was trying to say.

[dboggs]

I thought that donothing must not be registered as the list box callback, since <enter> closes the dialog which, in my interpretation, is not "doing nothing." So, I tried my own explicit donothing callback routine. surprise, it doesn't change anything.

I conclude that there is no way to prevent a dialog from closing when the user presses <enter> in a list box. I can live with that. At least I was able to prevent this happening in an edit box, thanks to help from app4619 with the "want return" property in #2.

p.s. I agree that lack of a resource editor in VS shell is a real pain. I have tried to use ResEdit but have a lot of trouble getting it to run; it reports lots of "errors" that may or may not be important; it just doesn't seem to deal well with users who simply want to create a .rc file. I have more experience creating dialog boxes in Visual Basic; that works very well indeed but the resulting file only works in VB and is not a C-type .rc file that would work in Fortran. I do have an old CVF installation that I intentionally keep around just so I can use the resource editor in that (old enough that it was before Microsoft decided to remove it). It works fairly well, although it doesn't appear to support all of the control properties that I see referred to elsewhere. And since it is not very well integrated with the VS shell in IVF, I find it easier to edit the resource files directly.

What is one to do?

[IanH]

If your dialog box has no buttons, then it will have no default button...

Add a push button control to the dialog that does nothing, ahead of any other push buttons in the dialog.  Give it the BS_DEFPUSHBUTTON style and make sure that the Ok button does not have that style.  See if that fixes the problem.  If so, then you might be able to try hiding the button in some way (moving it out of the visible part of the dialog box window, or making it hidden, or hiding it behind another control... etc.

Alternatively, have a look at the WM_GETDLGCODE message (and perhaps DM_GETDEFID/DM_SETDEFID) - if I recall correctly then if a control responds to that message saying "I want the enter key", then the dialog box manager won't then map the enter across to a click on the the default button.  You probably need to subclass the list box control to implement this.

BUT if I was working in an application, and while a modal dialog box was active a control other than a multi-line edit control had the focus, and I pressed enter and the default action of the dialog box didn't happen (which I would normally expect to be the Ok button), I would file a bug report against that application.

[andrew_4619]

I am slightly confused by "when the user presses <enter> in a list box." Is this a list box  control or a combo box control? In my experience ( or maybe inexperience!) a list box is not directly user editable, In which case pressing enter over the dialog will be taken by whichever control is default which maybe the in the top corner or example. You can trap that also in Quickwin but I can't remember how I would need to dig out an old project.

[andrew_4619]

When your dialog terminates in the unwanted way what is the return value is it IDCANCEL or IDOK? You can define a callback for IDCANCEL e.g. do a message box with "are you sure?"  and if Yes then call  dlgexit.