On another computer, I found the output_close version, and I'm not sure if I
had problems getting the other to work, or if it was just a while before I
found the okclick event. I'll include this sample as well:
(openform is a project-level variable that is set to the name of the form being
shown at any time.)
Sub output_close
Select Case openform
Case "paytypes"
If List1p.ListCount < 1 Then
MsgBox "You must have at least one payment type before you
continue!", vbExclamation, "Usage error"
Exit Sub
End If
frmMain_show
paytypes_hide
openform = "frmMain"
ShowOKButton False
Case "classes"
If cmbMain.ListCount <= 0 Then
MsgBox "You must have at least one expense class before you are
done.", vbExclamation, "Expenses message"
Exit Sub
End If
frmMain_show
classes_hide
openform = "frmMain"
ShowOKButton False
Case "locates"
frmMain_show
locates_hide
openform = "frmMain"
ShowOKButton False
end Select
End Sub
--- In [email protected], "chris_kenworthy" <chrisk...@...> wrote:
>
> Okay, the example I found didn't use output_close, instead it had what seemed
> to be a form-level event handler of the 'OkClick' event, which definitely
> seems to be a good way of doing it. (Before I found the example, I was
> wondering how to keep track of which screen you were on when output_close was
> triggered.)
>
> Here's a sample OkClick event. This dialog screen, paytypes, is used to
> manage and setup one of the expense classes that are needed in order to use
> the main entry to actually create an expense record.
>
> Sub paytypes_OKClick()
> If List1p.ListCount < 1 Then
>
> MsgBox "You must have at least one payment type before you
> continue!", vbExclamation, "Usage error"
> Exit Sub
>
> End If
>
> frmMain_show
> paytypes_hide
>
> End Sub
>
>
> --- In [email protected], "chris_kenworthy" <chrisken0@> wrote:
> >
> > I don't have the example to hand, but you can do this with output_close.
> >
> > "Documentation Changes for Version 6.0.4
> > Output_Close: (Pocket PC) This event is sent to a program if ShowOKButton =
> > True. You can do normal processing here, including MsgBox statements. The
> > program will not actually exit unless you have a Bye statement in the
> > subroutine. (Note that is a change from previous versions). If ShowOKButton
> > = True and you do not have an Output_Close subroutine, the program will
> > exit. If ShowOKButton = False, the operation will be as always: the program
> > will keep running, but the next program in the hierarchy will appear on the
> > screen. "
> >
> > Will provide more detail when I can find the source code for my program
> > with ok button closing dialogs.
> >
> > --- In [email protected], "michiman56" <rriemersma@> wrote:
> > >
> > > While the behavior when using "ShowOKButton True" is useful and welcome
> > > for many applications, it seems to deviate quite far from the OK button's
> > > intended purpose.
> > >
> > > Is there any technique that can be used to modify this behavior back to
> > > the expected "OK this dialog" functionality?
> > >
> > > I wouldn't want the [X]-button (minimize) action, but rather some event I
> > > can handle that would tell my code it can close/hide the current "dialog"
> > > form and return to a main form.
> > >
> > > Thanks for any ideas.
> > >
> > > Bob
> > >
> >
>
--
You received this message because you are subscribed to the Google Groups
"nsb-ce" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nsb-ce?hl=en.
