Prev: Windows7 - No App icon in task bar?
Next: [SOLVED] Windows7 - No App icon in task bar?
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?