David, over the years I had forgotten about how to address this specific issue, but, lo and behold, I figured it out again w/in the past 48 hours. The only way, it seems, to suppress that SAVE|DISCARD|CANCEL dialogue is to have nothing but VARIABLES located on your FORM ; this means not even a FIELD_NAME = (.VARName) expression defined in the FORM as, apparently, any "attachment" to the underlying TABLE.RECORD triggers the dialogue.
Now, a VARIABLE-only FORM might not be applicable in all situations and I didn't think I could make 'em work. But, between some little thoughts ticklin' inside my head (no, not voices) and the helpful suggestions fm "those to numerous to mention" in this listserv, I began finding my way last Friday PM and have been "VARIABLE-izing" a set of FORMS in my current APP in order to achieve as near as possible the things that I need to achieve, one of which is dumpin' that DIALOGUE. I'm working on an app which, in part, must support simple but high-speed/high-volume data entry. So, I don't want anything between my users' 10-keys and their input fields, unless I put it there (ERR_TRAPS, etc). Just about all the FORMS that are called in this functional area are VARIABLEs-only. Fortunately, the functional requirements and my design have made it such that the high-speed part only requires one input per record, that is, one EDITABLE VARIABLE field on the FORM. I start with a CURSOR, which calls the (main) FORM by "ENTER USING ..." The FORM is displayed with values assigned to the un-editable VARIABLE-Fields by way of the CURSOR. The user then types what they see on the paper source-doc into the editable VARIABLE-Field. Although I am locating BUTTONS on some FORMS, typically Field Exit occurs by way of "[ENTER]", which is expected normal processing for 10-key data entry. In any case, and there are some situations for which I haven't yet implemented anything, such as "NEXT"/"PREVIOUS" I then have an EEP take control. I have created command files which then do the work of ERR-trapping, SKIPping, SAVEing, etc, which is a general but not absolute requirement for VARIABLE-only FORMS. I have modularized the command files to the point that I can be flexible and fairly quick in re-configuring them for the appropriate flow-control. That is, each source file does basically one thing and one thing only, which fits into one of the fundamental principles of good S/W DEV, that is the state of "loose coupling and high cohesion". F/ex, I have file-modules w/names along the lines of "CURSOR_NAV", "SAVE_DATA", "SKIP_TRIGGER", "RESPONSE_TYPE", "RESPONSE_VALID", etc. There are some particulars to both the DB-Tables and the app which I'm not sharing right now, but these also factor into making this VARIABLE-only approach feasible f/our solution. Now, this ain't brain surgery, but it might be a bit like building construction and requires some work, IMO. My system has gotten large/complex enough that just managing the architecture has become a challenge. I have a big (well, big-enough) magnetic whiteboard in my office w/magnetic labels I have cut and/or printed (available fm AVERY) upon which I write module names or tape screen dumps of forms. It looks somewhat like a hand-did "TreeView" control in DELPHI/VB/ETC (see, Mike, I read that e-mail). Thus, I have an architectural diagram of the various building blocks, as it were. Although I'd never really considered the true value of doing this in an RBase-type environment, it's helping me tremendously. Yep', I still need to check the source, but just to analyze the overall structure and changes to it, I just need to change the magnetic labels and use my whiteboard markers/eraser. Man, I tell you, it's helpin' me to manage the development of a system which I think is gonna' make some things happen around my department w/in the next few days ; and I think those things are gonna' be good and big! Others have implemented things like this as well. When I get (sufficiently) done, I'm gonna' summarize in some (hopefully) intelligible fashion what I did, because I'd like to hear what other folks think about it. I'm proud enough to-date that I (almost) hope v7 isn't out too soon, as it could be so flexible that my implementation accomplishment becomes marginalized, at least in my eyes. Nevertheless, the true value and ongoing payback comes from that whiteboard, as that's the basic roadmap to doing exactly the same implementation in v7 ... Well, I've run on enuf', so, I'd be happy to help any way I'm able. I've been an RBase user since System V, which was what, 1986 or 1987? Nevertheless, my app-dev skills in RBase have only recently been exercised after a multi-year layoff, and, while I'm kinda' impressed w/myself in the past week, there are many others here who are far deeper than I - they are also probably less verbose, too. Y'all just be glad that I've never taken the time to get my Dragon "Naturally Speaking" stuff trained and working ... Later, Steve in Memphis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of David Billing > Sent: Friday, March 29, 2002 3:54 PM > To: [EMAIL PROTECTED] > Subject: Re: Eep Question > > > Hi Tom, > > Thanks for your answer, but... > > I should have explained more fully. I worked out how to delete a row; no > problem. It appears that what the discard row defined function does is > discard changes that were made to the record displayed in the form without > them ever being saved to the table. I can just do a CLOSEFORM in the eep, > but RB then asks whether I want to save the changes. I'd like to > have that > extra step/window not appear because my button already says that I want to > discard the changes. I also have a Save Changes and Delete Row buttons > where I use SAVEROW and a DELETE just like yours. What will do > the Discard > Row, like the defined function? > > I suppose I could use a variable form, and just never copy the > variables to > the row. I've done it that way in other situations. > > Are you coming to Pittsburgh this spring/fall? > > Thanks for your help, > Dave Billing > Tall Tree Business Solutions > ----- Original Message ----- > From: "Tom Grimshaw" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 30, 2002 11:33 AM > Subject: Re: Eep Question > > > > > > G'day Dave, > > > > 1. Within the form declare a variable to the value of a unique row ID. > > 2. In the eep, DELETE FROM TableName WHERE RowID = .vRowID > > > > At 15:04 29/03/02 -0500, you wrote: > > >Perhaps a simple question, but I'm stuck on it. In RBW6.5++, > you have a > > >form with a button. In the button properties you can select defined > > >function with the options to Discard Row or Discard Row & Exit. How > would > > >you do that in an eep? > > > > Warmest regards, > > > > > > Tom Grimshaw > > coy: Just For You Software > > tel: 612 9552 3311 > > fax: 612 9566 2164 > > mobile: 0414 675 903 > > > > post: PO Box 470 Glebe NSW 2037 Australia > > street: 3/66 Wentworth Park Rd Glebe NSW 2037 > > > > email: [EMAIL PROTECTED] > > web: www.just4usoftware.com.au ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
