Tablet and form style for Windows 8 (desktop ver.)

[nageswaragunupudi]

We can add these two modifications to any dialog.
1) Find whether it is touch screen. ( please see new tximage class)
2) If touch screen, handle invoking virtual keyboard in the gotfocus block

[dutch]

Dear Rao,

It's great, hope to see soon.

Regards,
Dutch

[Otto]

Hello,
this is what I would need for my application.




Thanks in advance
Otto

[cnavarro]

first tests

Code: Select all

// Testing GETs

#include "FiveWin.ch"
#define WM_SYSCOMMAND 0x0112
#define SC_CLOSE 0xF060

function Main()
   LOCAL oDlg, oGet
   local oGet1, oGet2
   LOCAL cCad := "Testing    " // pad("Testing Gets",40)
   LOCAL nNum := 0
   LOCAL dDat := Date()

   Set century On
   Set Date Ansi
   Set Date format "mm/dd/yyyy"

   SET _3DLOOK ON

  DEFINE DIALOG oDlg TITLE "TGet from " + FWDESCRIPTION

   @ 1,    2 SAY "Text..:" OF oDlg
   @ 1,    6 GET oGet VAR cCad OF oDlg SIZE 60, 10 COLOR "W/G" PICTURE "@K"

   @ 1.8,  2 SAY "Number:" OF oDlg
   @ 2,    6 GET oGet1 VAR nNum OF oDlg SIZE 60, 10 PICTURE "9999999.99"

   @ 2.6,  2 SAY "Date:" OF oDlg
   @ 3,    6 GET oGet2 VAR dDat PICTURE "@E" OF oDlg SIZE 60, 10  // "@D"
   
   @ 3,    7 BUTTON "&Ok" OF oDlg SIZE 30, 12 ACTION .T. //oDlg:End()
   @ 3,   16 BUTTON "&Cancel" SIZE 30, 12 OF oDlg ACTION oDlg:End() CANCEL
   
   // TGet():SetColorFocus( nRGB( 200, 120, 120 ) )

   ACTIVATE DIALOG oDlg CENTERED VALID ( HideInputPanel(), .T. ) ON INIT ControlsDlg( oDlg )

return nil

//------------------------------------------------------------------------//

FUNCTION ShowInputPanel( oDlg )
Local hWndInputPanel
//hWndInputPanel:= FindWindow("IPTip_Main_Window") 
//if Empty( hWndInputPanel )
   ShellExecute( oDlg:hWnd, "open", "C:\\Program Files\\Common Files\\microsoft shared\\ink\\tabtip.exe") 
//endif
RETURN NIL

FUNCTION HideInputPanel()
Local hWndInputPanel
hWndInputPanel := FindWindow("IPTip_Main_Window")
if !Empty( hWndInputPanel )
   PostMessage( hWndInputPanel, WM_SYSCOMMAND, SC_CLOSE, 0 )
endif
Return nil

Function ControlsDlg( oDlg )
Local x
Local nLen := Len( oDlg:aControls )
Local aObj := { "TGET" }
For x = 1 to nLen 
      if !Empty( Ascan( aObj, Upper( oDlg:aControls[x]:ClassName() ) ) )
         WITH OBJECT oDlg:aControls[x]
            :bGotFocus   := {   | o |  ShowInputPanel( oDlg ) }
            :bLostFocus  := {   | o |  HideInputPanel() }
        ENDWITH
      endif
Next x
Return nil

 

I do not understand if you need

[Otto]

Hello Cristobal,
thank you for the code.
I didn’t had much time for testing.
But on the first try it seems to me that every time you press a key on the virtual keyboard you loose focus of the get and do not return to the get field.
I tried to find out the logic of WINDOWS IE and it seems that you loose only focus if you click outside of a get field.
I will do some more tests tomorrow.
I had to change to c:\Windows\System32\osk.exe as I do not have ink.exe.
Best regards,
Otto

[cnavarro]

No usa Windows 8 ?

Do not use Windows 8?

If you use Windows 8 is to put the full path

"C:\\Program Files\\Common Files\\microsoft shared\\ink\\tabtip.exe"

I use it, and the focus returns to get after pressing a key on the virtual keyboard

I used osk.exe and have had small problems, so I use Tabtip.exe

http://stackoverflow.com/questions/1770 ... -windows-v

[MOISES]

Mr. Rao,

We can add these two modifications to any dialog.
1) Find whether it is touch screen. ( please see new tximage class)
2) If touch screen, handle invoking virtual keyboard in the gotfocus block

Yes, this is required for our software to be used in tables and next Windows 10 ecosystem, without rewriting each Dialog.

When those changes will be available please?. Thank you.

[nageswaragunupudi]

I tested Mr Navarro's program. This is a good beginning.
Possible improvements are:
1) Restrict the display of OSKb only when a touch screen is present.
The new ximage.prg detects if a touch screen is present, though it does not use this information in this version. Same logic can be used.

2) It is better lostfocus does not hide/dismiss the OSKb, because the next control again can be a text-edit control. So we better change the logic as when a non-edit control/widow gets focus, then we hide/dismiss the OSKb, if it is being displayed. This avoids the OSKb getting hidden and shown when focus changes from one control to another.

I am using the word "OSKb" as a common word to represent either OSK.exe or TabTip or any custom keyboard developed by the programmer. I understand that there are some issues with the good-old osk.exe.

I am a novice and I do not have a touch screen PC. Till I get one, I have no way of testing and be sure of what needs to be done.

This is my concept of how to provide a fairly useful touch interface. Not advanced but reasonable enough.

1) Detect presence of touch screen and then only handle touch-aware behavior.
2) At present we depend on the windows' automatic translation of some important touch events as mouse events and this should be ok, for the time being.
Tap --> single click
Double Tap --> Double click
Press wait and release finger --> right click
Press and drag --> mouse drag
Pinch and Zoom --> MouseWheel with ctlr key pressed
Pan --> MouseWheel without ctrl key pressed
(I am not very sure about some of these and I stand corrected if advised.)

Though this behavior is default, it is possible that the user can disable or enable all or some of these translations in the control panel. At times this behavior can be off initially and the user needs to turn them on explicity for the translations to work. In such cases the user may be thinking that our FWH application is not responding to touch.

3) We need to accept that in a majority of cases the user may be simultaneously interacting with our applicaion through touch as well as with keyboard and mouse. Even when there is a touch screen, when the user is seriously working with keyboard and mouse, it may be annoying for him to keep seeing the OSKb coming on and off the screen.
So, when we first display the OSKb, we should make sure that the control got focus only by Tap of finger but not by mouse-click or tab key or through program. Even if the OSKb is not displayed, if the user Taps on the control, we should display the OSKb.

When to Display OSKb:
To summarize, we display the OSKb when focused window is an Editable control and "true finger tap" happened just a little while before the event we are responding to. For this we extend the event handler and keep watching finger press and release, but not act on it and wait for translation to mouse events.

When to Hide OSKb:
a) When a non-editable control/window gets focus.
b) When the user starts using mouse or keyboard direcly (not by touch)

Design:
The controls should be designed in such a way that they are not hidden by the OSKb when displayed.

Which OSKb?
TabTip.exe appears as a better alternative than osk.exe.
Bit I feel it is better a programmer develops his own custom keyboard. We are a hard working community and this should not be difficult for us when we already developed so many complex components.

This is just a loud thinking. These views may change when I start working and testing with a touch screen. If and when I do not know yet.

[Otto]

Dear Mr. Rao,

thank you for your work on tabtip.exe.

I did some more tests with Mr. Cristobal code.
I copied tabtip.exe to my WINDOWS 2012 Server and now it works fine.

I did some Google search on “tabtip.exe + parameters”. I think it would be fine if you could change the keyboard layout depending if the get field is a numeric or an alphanumeric field.
But it seems that you can only change the layout through registry. But maybe this is to slow for real work.

http://stackoverflow.com/questions/1564 ... ric-textbo

Cristobal, thank you for your help.
Best regards,
Otto

[Gale FORd]

You can make the Windows 8.1 keyboard into extended keyboard so it has a row of numbers across the top.
Swipe from right then select the following: Settings/Change PC Settings/PC and Devices/Typing
Then turn on the option "Add the standard keyboard layout as touch keyboard option"
Then when the on-screen keyboard is displayed there will be another keyboard style option available in lower right icon.
With this keyboard layout you can press tab, alt, and function keys.

[Gale FORd]

Check out Tabtip On-Demand. It is $1.99 and it works with any desktop app with no coding needed.
They also have a version for Remote Desktop so tablet will call local Tabtip.
http://chessware.ch/tabtipod/

[nageswaragunupudi]

Check out Tabtip On-Demand. It is $1.99 and it works with any desktop app with no coding needed.
They also have a version for Remote Desktop so tablet will call local Tabtip.
http://chessware.ch/tabtipod/

Excellent application.
This is what we wish to provide for in our own FWH applications without external application support.

[Gale FORd]

Would be nice to have code inside program but I found several problems I cannot seem to overcome yet.
1. Remote Desktop and using the tablets local Tabtip. If you use the Tabtip or OSK inside RDP session it acts different than Windows 8.1 on tablet.
2. Distinguish between needing on-screen keyboard and using actual keyboard. If the tablet is in physical keyboard/docked mode, app should not show on screen keyboard.
3. There is a difference between using the mouse/keyboard/tab/arrow to enter field and using your finger/stylus to enter field. With finger or stylus you are using tablet mode and need on-screen keyboard. If you start typing on physical keyboard, on-screen keyboard should automatically hide.
4. Problems with focus. There seems to be some problems with oGet:bOnFocus starting keyboard. I can get keyboard to start but field does not act correctly at times. This may be working for other people but I can't seem to get it stable. I am also having problems getting keyboard to hide. In windows 8.1 keyboard never closes, it just hides. But I can't get it to work.

[nageswaragunupudi]

I mean to address all the problems you mentioned.
Please allow FWH team a little time.

[Gale FORd]

No problem. I think it would be great to have tablet features built in. The only thing that I don't think we can manage is the Remote Desktop app with local Tabtip.