Thanks Chris, This looks good. I'll check the documentation changes notes and try working with the examples you've outlined.
Bob --- In nsbasic...@yahoogroups.com, "chris_kenworthy" <chrisk...@...> wrote: > > 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 nsbasic...@yahoogroups.com, "chris_kenworthy" <chrisken0@> 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 nsbasic...@yahoogroups.com, "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 nsbasic...@yahoogroups.com, "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 nsb...@googlegroups.com. To unsubscribe from this group, send email to nsb-ce+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/nsb-ce?hl=en.
