Ben, here is one of the original of my postings ... -Steve ============================================================================ = Okay, I've created several forms w/tiered regions and tested this w/similar results. I say similar because I just ain't gonna' take the time to isolate this behavior beyond what I've done so far, unless RBTI wants to hire me as a S/W Q/A Manager, and that's not a hint, because I already have a job and I'm tryin' to spend my time doing that job, using RBase as a tool to aid in the performance of that job.
Anyway, the unexpected behavior observed is as follows. While "EDIT USING FormName ...", in a tiered region, when an EEP issues a NEXTROW command that continues conditionally, the edit-cursor (NOT an SQL CURSOR, but that little vertical bar) and the INTENSITY-highlighted tier may go out-of-sync with one another. This is occurs when a NEXTROW command moves off the last visible row of the tiered region. The INSTENSITY-bar sticks at the (LastRow + 1), whereas the edit-cursor may behave unpredictably - the "unpredictability" facet here may simply be that I haven't identified more details about the problem and its potential causes, interdependencies, etc. Anyway, as EEP's are still being called, and their execution being conditionally controlled based on either COL||VAR values, which themselves were dependent, in part, on an expected sequence of execution, meaning, since this an EDIT USING ..., this record comes before that one, everything on my form goes to hell-in-a-handbasket. (Umm, lest I be criticized on etiquette, I have heard my elders and forbears use such a term and I therefore consider it to be within the bounds of acceptable useage.) Okay, so I got basic. I created a table, DUMMY, with 1 COL, "DUMMY_INT (INTEGER)". I also created a simple form, with a region of 10 tiers, locating a Field for DUMMY_INT and defining a VAR, vDummy_INT = DUMMY_INT. I INSERTed a couple dozen records, so that I'd have more records then the tier could display. Then I added this Field eNtry Procedure : --DUMMY_INT Test IF vDUMMY_INT < 15 THEN NEXTROW ENDIF I've tested this and so should y'all. Also, and I don't mean this insincerely nor insultingly, but, having observed this behavior and now having taken the time to better define it, I don't want any patronizing or condescending responses from Razzak or RBTI. As I've said, I've been a user since the release date of System V, so any use of the terms such as "glorious" or "magical" will not only irritate me, but lead me to doubt those entities||attributes, Glory and Magic, especially as they are based on my perception of what the product does f/me now, not what I hope RBTI is going to do to improve the product. Nor do I want to see any admonitions, albeit gentle, about remaining current w/my versions, as the problem either : - was present in the past or - is now present and, in either case, is wholly insufficient w/re: to S/W Q/A and expected performance. As I said, I don't mean to be ugly, but I paid my money and I ain't that happy right now. So, in a cooperative spirit, I'll tell you exactly what I do want. I want RBTI to test this, acknowledge that it is either a bug, or that the documentation is such that I, the user, could not have known about certain limitations in the use of EEP's, and that this will be addressed in v7, whether because it's fixed or because a change in the architecture of RB is such that it is irrelevant. Look, I been comin' back to RBase f/years now, but I keep gettin' the feeling of being a jilted lover. So, all this rah-rah-rah-sis-boom-bah stuff is garbage in my ears. I expect everyone at RBTI to be proud of their efforts, but I expect the bulk of that pride not come from vision, aspiration, motivation, but rather from the humble acceptance of praise from us, the developers and users, based on our positive perception that peformance is proof, end of discussion. As my wife likes to tell me, and I think I once read it in Latin, "Actions speak louder than words." Lookin' fwd to what y'all have to say, Steve in Memphis ================================================ 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/ > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Ben Petersen > Sent: Tuesday, March 19, 2002 9:06 AM > To: [EMAIL PROTECTED] > Subject: Re: ENTER USING ... FOR 1 ROW ... W/IN a WHILE Loop and > "Flashing" as FormName is Cleared > > > Stephen, > > I've already lost your original post. What is the cursor doing? > or > How about this. Let your form have all variable fields. After > completion an eep verifies the data entry, does an insert into the > target table, set all the vars to null, and skips back to the > beginning? No loop, no flashing, etc > > Ben Petersen > > > > On 19 Mar 2002, at 16:15, J. Stephen Wills wrote: > > > Okay, some of y'all been readin' my messages and maybe you're > wondering what > > I was about - or maybe not. Anyway, I've persisted (though I don't know > > what that means in reference to objects) in implementing a > work-around to my > > TIERed REGION in a FORM problem, w/some of y'all offering > pointers along the > > way - my thanks. However, life, love, and lines of code are about > > trade-off's and I'm hoping that somebody out there can help me avoid a > > certain trade-off. > > > > I've set up a CUR to manage the sequencing and navigation and w/in the > > WHILE-loop I'm ENTERing USING a form FOR 1 ROW. What troubles me is the > > clearing & re-drawing of the form while the error and skip checks are > > processing. Although the reponse-time seems quick enough f/even > > accomplished 10-key data-entry users, that "flashing" makes me > worried that > > it'll be too big a distraction f/my users. > > > > Anybody got any good ideas about how to at least simulate what > some previous > > versions of RB allowed you to do when you checked YES/NO to clearing the > > screen on form exit? > > > > Thanks, > > Steve in Memphis > > > > ================================================ > > 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/ > > > > > ================================================ > 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/ > ================================================ 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/
