Prev: How big is the VO community
Next: SetCueBanner
From: Geoff Schaller on 21 May 2010 21:19
Lu,

Small warning: DO NOT MAKE A HANDLER WORK AGAINST ITSELF.

The idea of a handler is that it is called as the result of an event.
EFC happens when focus is changing. It is now NOT the place to go about
prevent and changing focus because all that happens is you get more
focus change events and you get hopelessly lost in the sequence.

You really have no option but to get involved with the Dispatch and
learning about all the events that track one another as you press keys.
Every key press can involve up to 8 consequential messages but some
controls swallow some of them and some generate more. Sometimes you even
have to subclass the WndProc itself for a control to gain complete
control of messaging.

You need to read Petzold (the first 5 chapters are enough) and gain for
yourself a thorough understanding of Windows messaging and then you will
be better placed to manage this kind of thing.

Geoff



"Lu" <lu2k(a)hotmail.com> wrote in message
news:5e2786d4-f435-45e3-a9bd-56c32715c4dd(a)c7g2000vbc.googlegroups.com:

> Now I tried it with this EditFocusChange Method. It works fine if I
> use the tab key in one way but if I want go back with shift + tab
> from sle1 it focus the sle4 in the sub window. The reason is that if
> the sle1 has focus and I press the shift+tab key it goes to the last
> control in the sub (sle5), and EditFocusChange method is called again
> and now it focus sle4 because it should focus sle4 if the shift+tab
> key is pressed on sle5.
> I hope you know what I mean. Is it possible to prevent the behavoir
> that the focus change from the first sle to the last sle in the sub if
> I press shift+tab or another way to solve the problem. It is probably
> nicer to solve it with a dispatch method but I am not familiar making
> a own dispatch method.
>
> METHOD EditFocusChange(oEditFocusChangeEvent) CLASS Sub_Tz1
>
> LOCAL oControl AS Control
> LOCAL lGotFocus AS LOGIC
> oControl := IIf(oEditFocusChangeEvent == NULL_OBJECT, NULL_OBJECT,
> oEditFocusChangeEvent:Control)
> lGotFocus := IIf(oEditFocusChangeEvent == NULL_OBJECT,
> FALSE,oEditFocusChangeEvent:GotFocus)
> SUPER:EditFocusChange(oEditFocusChangeEvent)
>
> IF lGotFocus == FALSE
> IF oControl:NameSym == #sle1
> IF LOGIC(_CAST,_And( GetKeyState(VK_SHIFT),SHORT(_CAST,
> 0x8000))) //Shift key
> SELF:oParent:odccmbTz:SetFocus()
> ELSEIF SELF:oParent:_cStatus == 'A' .and.
> SELF:oParent:cmbTz != 'y'
> SELF:oParent:LoadFromTo()
> ENDIF
>
> ELSEIF oControl:NameSym == #sle5
> IF LOGIC(_CAST,_And( GetKeyState(VK_SHIFT),SHORT(_CAST,
> 0x8000))) //Shift key
> SELF:oDCsle4:SetFocus()
> ELSE
> SELF:oParent:odccmbPers:SetFocus()
> ENDIF
> ENDIF
> ENDIF
>
> RETURN NIL
>
>
> Lu

From: richard.townsendrose on 22 May 2010 07:36
Lu,

we use markus mitterauer's Tabcontrol(-plus) which was based on
STEPHANE HEBERT's work, and then modified by Paolo

Tab controls dont support "hot keys" as are used for buttons and
menus, so we use AFHook in conjunction ...

Its all very easy ... email me if you want the code. richard at tdoc
dot net

We also integrated bbrowser into tab pages allowing indexed seeking
and locate searchs .. again code available. see tdocplus dot co dot uk
and have a look at our on line manual

these days we replaced many of our tab pages with a datadialog instead
launched from a button. its visually nicer. but a page with two tabs -
one page for finding a record from a bbrowse, and the next for editing
is good. and then we have many places where the edit page has a load
of subtabs ...

see also jotika dot co dot uk which alos uses the same setup

richard
From: Lu on 23 May 2010 13:27
Thank you for the hints.

Lu
First  |  Prev  | 
Pages: 1 2
Prev: How big is the VO community
Next: SetCueBanner