DB Button Click and DB Pass Value(s)

[Bill_H]

I have a simple form that displays customer transactions (charges and credits).  There is a client textbox, a customer textbox, and a displaytype dropdown box.  In addition, there is a [Process] button.  On other forms there is a link to this form.  When that link is clicked the variable PROCESS.STACK is set to "MYFILE_MYFORM~L".

What happens in this particular form is unusual.  From the calling form the following variables are set:

DBPASS.DBVALUE = "Client# ] Cust# ] DisplayType"
DBPASS.DBVALUE.TO = "ClientNo.Wk ] CustNo.Wk ] DispType.Wk"

The form "MYFILE_MYFORM" is called in a layered status and the events that occur are:

BEFORE.SCREEN (the new form)
AFTER.DISPLAY (the new form)
AFTER.READ (the client)
AFTER.READ (the customer)
VALIDATE (the display type)
BUTTON (the process button)

At this point a report should display.  It does not for this particular form.  When I review the events two additional AFTER.READ events occur (after the last BUTTON event caused by the DBBUTTONCLICK variable); for the client, with a value of the Client#, and for the customer, with a value of the Client# (that's right).  Of course, nothing is in the DBPASS.DBVALUE... variables during these events.  I have a couple of other forms that are very similar and they don't have this problem (the non-display of the form and the extra events).  What is interesting is after the BUTTON event (to process the report) the OUTPUT variables are all properly populated and the PROCESS.TYPE is set to "R" along with the PROCESS.REFRESH being set to the on-form report variable "R.REPORT".

If I just click on the [Process] button the report displays but I'd like the report to display as the last thing done when the form is called, without user intervention.  I've had this problem with a couple of reports in the past but can't seem to isolate the actual DB variable that calls the additional AFTER READ events.  Does anyone know what DB variables override the expected behavior?  Thanks,

Bill

[David Knight]

Hi Bill,

In your called form, by "BEFORE.SCREEN" do you mean the slot entitled 'Process Before Display' on the Form designer setup screen? If so, note the f1 help which on my system reads: "This will invoke a process with a 'BEFORE.DISPLAY' event. This is for the sole purpose of changing SCREENROOT via DISPLAY.STACK" [emphasis added].

In my experience, putting anything in this slot does not do quite what one expects unless it is a standard form [not layered, not called via MODAL.RETURN etc] and one is literally doing what the online help says. It is not 'another' slot one can use to do stuff.

Try fiddling in that area. When I did some simple testing months ago with a dummy form and dummy subroutine just debugging; I found this slot may cause multiple calls such as what you are seeing; and iirc does some weird things with COMMON variable, which is in essence what you are seeing.

HTH?

Sorry for taking so long to respond, have been away & off-forum for a while.

Cheers,

David

[Bill H]

I don't use the "BEFORE DISPLAY" section of forms.  The above caveat you described applies to this event.  I use "BEFORE SCREEN" that is defined by the menu's "Subroutine to invoke before screen" field in the menus section.  Once this menu (a main menu) is run all subsequent activity uses this subroutine before running the form.  This allows us to stop the user from accessing the form completely, or to divert the user to another form.

There are a large number of anomalies with DB that cause the application to fail.  These are generally documented things that don't work but only in certain circumstances the developer has no idea what it is.  Consequently huge amounts of time is spent trying to find a work around.  Once one is found the developer tries to standardize this "work around" but it often, in this instance, fails too.  For instance, another issue is clicking a button that disables the clicked button, so it can't be clicked again, and does a DBBUTTONCLICK of another button that brings up a Yes/No dialog box to validate the action (usually a save).  Sometimes this just doesn't work; the DBBUTTONCLICK doesn't run.  Don't ask me why, but it doesn't.  I have no idea why but two almost identical (but not obviously identical) forms with almost identical behind-form code react differently to this DB variable.

Anyway, I was wondering if someone had found the cause of this particular anomaly, but I guess not.  :-)

--
You received this message because you are subscribed to a topic in the Google Groups "DesignBais-Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/designbais-forum/xT18AOgS_Wc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to designbais-forum+unsubscribe@googlegroups.com.
To post to this group, send email to designbais-forum@googlegroups.com.
Visit this group at https://groups.google.com/group/designbais-forum.
For more options, visit https://groups.google.com/d/optout.