From: Bill Tillick on 26 Jul 2010 21:52 Steve, I thought you were on to it with your suggestion, But after I deleted the InfoBoxes I still got the same error. And also, I realised that I setting focus to the bBrowse on every FocusChange/GotFocus anyhow. Gerhard, I am seeking on an SQL Table, and the seek parameters are correct as I have them. Also, the seek works as it is, because the program certainly finds the correct record - it just goes a bit wild by putting the seeked record into every row!!! Any more suggestions, please??? Thanks, Bill
From: Geoff Schaller on 27 Jul 2010 04:11 Bill, RULE #1 - NEVER POP UP A DIALOG in the midst of a key stream. This is just asking for trouble. Use only DBGView debug output. It is way too hard to work out what might be happening here. Geoff "Bill Tillick" <wtillick(a)gmail.com> wrote in message news:ed61113d-6c3c-4f8d-9245-f6c689c1d19c(a)l25g2000prn.googlegroups.com: > Hi Steve, Geoff, etc, > I now have bRegisterByEventHandler(self:oDCbBrowse, self, #KeyChar) in > my PostInit for the owner window. > > My KeyChar method is now:- > ---------------------------------------------------------------------------------------------------------------- > METHOD KeyChar( oKeyEvent ) CLASS Product2List > LOCAL cText as string > > IF oKeyEvent:uMsg = WM_CHAR .and. oKeyEvent:window = > self:oDCbBrowse > cText := Upper(CHR(oKeyEvent:wParam)) // get the > key's character and convert to UCase > self:server:SuspendNotification() > IF cText == self:cLastKey // have we got a repeat of previous key > press? > self:server:skip(1) // yes, so skip to next record > IF self:server:ProductName > cText .or. self:server:eof > // does this still have the same initial letter? > self:server:skip(-1) // no, so back up to the previous record > ENDIF > ELSE > // new letter, so do a fresh seek > IF self:server:seek(#ProductName, cText, true ) > InfoBox{self,,self:server:ProductName}:show() // check that > we have positioned corrcetly > else > InfoBox{self,,"seek failed"}:show() > endif > > self:cLastKey := cText // and save the initial letter > ENDIF > self:server:resetNotification() > self:server:Notify(NOTIFYRECORDCHANGE) // do I need both these > Notifys? > self:server:Notify(NOTIFYFILECHANGE) > self:oDCbBrowse:Refresh() > RETURN true // = SUCCESS > ENDIF > RETURN nil // key not processed > ------------------------------------------------------------------------------------------------------------------------- > > Using InfoBox and the debugger I have determined that the method is OK > until the point at which the InfoBox shows the ProductName correctly. > BUT when I pause before closing the InfoBox, the bBrowser > automatically refreshes at that point and then every row displayed is > a repeat of the row corresponding to the Seek! > If I increase the auto refresh delay, so that the method sends its own > refresh, then the browse is positioned as expected after the Seek - > UNTIL the subsequent auto refresh which again causes every row to be > displayed as a repeat of the row corresponding to the Seek! > > Weird??? or have I missed something? > > Thanks for your help, > Bill
From: BillT on 27 Jul 2010 20:24 Geoff et al, 1. I now have a working program, thanks. 2. The two recent things that had to be done to achieve this are (a) bregisterByEventHandler the KeyChar() method and (b) set the AutoRefreshTime to zero. 3. Geoff, you wrote back on July 25 that "bBrowser works by registering its own event handler PRIOR to the WndProc. This gives bBrowser the ability to trap and respond to all key events but the trick is that you must register this handler for it to work." I got caught by the seeming (to me) inconsistency in this statement - you first say that bBrowser registers... then that I must register. I assumed that if bBrowser does registering and that Jaochim's Help doesn't say anything under KeyChar() about having to register that it wasn't needed. Guess I was wrong again!! 4. I remain puzzled about why the autorefresh, either removed or set to a non-zero value, caused the seeked record to be repeated on every visible row. Maybe Joachim can shed some light on all this? Regards, Bill
From: Stephen Quinn on 27 Jul 2010 22:41 Bill AFAIK there is no need to register any CALLBACK method (at least I never had to), I think that's the automatic registering that Geoff was referring to. IIRC the help says that bBrowser checks to see if the callback method exists on the parent window and uses it if it does otherwise it'll do it's normal processing. You have to use bRegisterByEventHandler() when using the KeyEventHandler() The KeyEventHandler() is NOT a CALLBACK method therefore the need to register it. > 4. I remain puzzled about why the autorefresh, either removed or set > to a non-zero value, caused the seeked record to be repeated on every > visible row. Because the notification had been suspended and when that happens internal pointers never get updated Eg A simplified example SuspendNotification() AutoRefresh() - redraws the window but there's no movement in the database ResetNotification() AutoRefresh() - redraws the window with normal movement in the database CYA Steve
From: Geoff Schaller on 28 Jul 2010 06:45 Steve said it so nicely <g>. "BillT" <wtillick(a)hotmail.com> wrote in message news:3f0f22b7-7bcb-4d6d-8268-1c958faaaf0a(a)x1g2000prc.googlegroups.com: > Geoff et al, > > 1. I now have a working program, thanks. > > 2. The two recent things that had to be done to achieve this are > (a) bregisterByEventHandler the KeyChar() method and > (b) set the AutoRefreshTime to zero. > > 3. Geoff, you wrote back on July 25 that "bBrowser works by > registering its > own event handler PRIOR to the WndProc. This gives bBrowser the > ability > to trap and respond to all key events but the trick is that you must > register > this handler for it to work." > I got caught by the seeming (to me) inconsistency in this statement - > you first say that bBrowser registers... then that I must register. > I assumed that if bBrowser does registering and that Jaochim's Help > doesn't > say anything under KeyChar() about having to register that it wasn't > needed. > Guess I was wrong again!! > > 4. I remain puzzled about why the autorefresh, either removed or set > to a > non-zero value, caused the seeked record to be repeated on every > visible row. > > Maybe Joachim can shed some light on all this? > > Regards, > Bill
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Windows7 - No App icon in task bar? Next: [SOLVED] Windows7 - No App icon in task bar? |