Jump to content

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Find out more here. X
X


Photo

Calling the on screen keyboard in windows 7


  • Please log in to reply
10 replies to this topic

#1 computergroove

computergroove

    Universalist

  • Active Members
  • PipPipPipPipPipPip
  • 622 posts

Posted 21 January 2011 - 12:47 AM

I have added "Run("OSK")" in my script and tested it in xp and it works. When I do it in Windows 7 it gives me an error "Could not start On-Screen Keyboard." Why is it doing this? I have also tried osk.exe but it seems like more of a security feature in Windows.







#2 JohnOne

JohnOne

    John

  • Active Members
  • PipPipPipPipPipPip
  • 12,989 posts

Posted 21 January 2011 - 01:28 AM

hmm, same here.

This works though.

ShellExecute("osk.exe")

AutoIt Absolute Beginners Require a serial
 
 
OMG! Women are the cows of people.


#3 computergroove

computergroove

    Universalist

  • Active Members
  • PipPipPipPipPipPip
  • 622 posts

Posted 21 January 2011 - 01:53 AM

No it is still giving me the same error. Any other suggestions?

#4 JohnOne

JohnOne

    John

  • Active Members
  • PipPipPipPipPipPip
  • 12,989 posts

Posted 21 January 2011 - 02:04 AM

I assume you tried..
#RequireAdmin.

And for your reference my win7 &86 didnt throw up an error of any kind with run, it simple never started it.

AutoIt Absolute Beginners Require a serial
 
 
OMG! Women are the cows of people.


#5 computergroove

computergroove

    Universalist

  • Active Members
  • PipPipPipPipPipPip
  • 622 posts

Posted 21 January 2011 - 02:33 AM

I am going to be making this for an auto installer where the end user will need to enter a customer id and pin on computers that do not have keyboards or mice, just touch screens. Is there any way to make it work without having to type in the admin password? Also adding #RequireAdmin does not make the program work. I will be happy if I can get it to work even if they have to add their admin password.

Edited by computergroove, 21 January 2011 - 02:37 AM.


#6 computergroove

computergroove

    Universalist

  • Active Members
  • PipPipPipPipPipPip
  • 622 posts

Posted 21 January 2011 - 02:38 AM

OK I am running Windows 7 Pro 64 bit and when I compiled it for 64 bit it worked. Is there a way to make the same code work for 32 bit and 64 bit OS's?

#7 Kendall

Kendall

    Seeker

  • Active Members
  • 42 posts

Posted 05 February 2011 - 07:13 AM

OK I am running Windows 7 Pro 64 bit and when I compiled it for 64 bit it worked. Is there a way to make the same code work for 32 bit and 64 bit OS's?


I am having the same issue, Windows 7 (retail)HAL (6.1.7600) 64Bit

I have tried running this in powershell and get error ( Could not start onscreen keyboard )


Using the

Run ("osk.exe") does not launch the application at all even with the full path.

This is wierd because when you send keys to a powershell it should be just like typing it in and pressing enter.

Using command prompt using send keys does the same thing.

I can type it in without any problems and bring it up. this is just silly. It has to be something with the way it is sending the keys to it like its too fast or it knows its not someone typing it in. I will look into the send key and put some winwait 's in to see if it will have issues.

there should not be a issue with wether it is 32 or 64bit becuase it is just asking to launch it.

Last person was saying that it had to be compiled to 64bit for it to work. :) Strange)

#8 Kendall

Kendall

    Seeker

  • Active Members
  • 42 posts

Posted 05 February 2011 - 07:28 AM

K, did some digging after multiple failures.

Note: OSK.exe is in 2 folders, SysWoW folder and system32 folder.

This is an issue with 64-bit OS, it affects any 64-bit version of Windows.

"Basically you are calling osk.exe, but your program you are calling it from is a 32-bit app. ( Autoit) Windows won't allow you to call a 64-bit OSK.exe from your program"

This is why the Application must be compiled to the correct Bit version.


Workarounds,

1. Disable Wow64DisableWow64FsRedirection in windows.

2. Pull it from a 32bit version of windows 7 or Windows XP and Add it to your applicaton. ( If you are distributing it you may want to look into the licencing)


;) Woot, thought i was going to lose my mind on this one.
:)

#9 taietel

taietel

    I'm the third from the left...

  • Active Members
  • PipPipPipPipPipPip
  • 726 posts

Posted 05 February 2011 - 09:13 AM

When tried on Win7 32 bit,
Run("osk.exe") is not working
but
Run(@ComSpec & " /c " & 'osk.exe', "", @SW_HIDE)
it's working.

#10 Kendall

Kendall

    Seeker

  • Active Members
  • 42 posts

Posted 05 February 2011 - 06:52 PM

When tried on Win7 32 bit,
Run("osk.exe") is not working
but
Run(@ComSpec & " /c " & 'osk.exe', "", @SW_HIDE)
it's working.



When running on 32bit win 7 with command prompt or powershell it works fine. The issue is 64bit OS's. When using the same above command you get the same error ( " Could Not Start On-Screen Keyboard ") Also windows XP works fine with just using the "RUN" command. @comspec just launches it with the command prompt.

Anyone else have anything other that the 2 ways i listed above to start it without compiling it?
I found a diffrent OSK app made from autoit that i may add to it so that i dont have to worry about the compatibility issues.

Unicode Keyboard Unicode
http://www.autoitscript.com/forum/topic/57413-unicode-keyboard-v-10-this-rocks/page__hl__keyboard

#11 PayasoXIII

PayasoXIII

    Seeker

  • New Members
  • 2 posts

Posted 26 September 2011 - 04:25 AM

I know I am responding to an older thread but just wanted to post my work around for calling osk.exe on win7 x64 from a x86 compiled script.

Just made a one line script and compiled a x64 version.

ShellExecute(@SystemDir & "\osk.exe")


My main script is compiles as x86 version. I added:

If @OSArch = "x64" Then;
ShellExecute("C:\Your_Path_Here\keyboard64.exe")
Else
ShellExecute(@SystemDir & "\osk.exe")
EndIf




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users