Announcement

Collapse
No announcement yet.

BAT file better than AMS?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BAT file better than AMS?

    Obviously I don't think so, surely my fault!
    I want to execute Windows 10 default OnScreen Keyboard with a button launching the original file called osk.exe.

    I used
    Code:
    File.Run(_SystemFolder.."\\osk.exe", "", _SystemFolder.."\\osk.exe", SW_SHOWNORMAL, false);
    and
    Code:
    Shell.Execute(_SystemFolder.."\\osk.exe", "open", "", "", SW_SHOWNORMAL, false);
    with no effects.

    If execute a simple .bat file with this code
    Code:
    start osk.exe
    All works fine and the keyboard is launched correctly.

    Any solution?
    Thanks in advance as usual.


  • #2
    If using File.Run(), leave the argument for "Working Folder" (the 3rd parameter) blank. It's only required if you wish to set the directory to something other than what the file is in. So, use ...
    Code:
    File.Run(_SystemFolder.."\\osk.exe", "", "", SW_SHOWNORMAL, false);

    Shell.Execute() will work fine, just like you already have it. At least it does on both Win7 & WinXP. (I've not tried it on Win10).

    Or you could even resort to a simple File.Open action for this ...
    Code:
    File.Open(_SystemFolder.."\\osk.exe", "", SW_SHOWNORMAL);

    Comment


    • #3
      Sorry but ...
      No problem on Windows 7, nothing happens on Windows 10 1809.
      Strange things!

      Comment


      • #4
        See if either of these work ...
        Code:
        File.Run(File.GetShortName(_SystemFolder.."\\osk.exe"), "", "", SW_SHOWNORMAL, false);
        Shell.Execute(File.GetShortName(_SystemFolder.."\\osk.exe"), "open", "", "", SW_SHOWNORMAL, false);

        Comment


        • #5
          Have just been taking a closer look at this issue. Try adding in the following command-line switch ("/C") to the 'arguments' parameter for each of the Shell.Execute and File.Run actions. Like this ...
          Code:
          Shell.Execute("osk", "open", "/C", "", SW_SHOWNORMAL, false);
          [COLOR=#008000][I]-- or[/I][/COLOR]
          File.Run("osk", "/C", "", SW_SHOWNORMAL, false);
          These both seem to work under Win7 & WinXP. So just check to see whether having that command-line switch in there makes a difference under Win10.
          ..............

          Otherwise, you could also try executing your target-file (osk.exe) via a suppressed command window. Like this ...
          Code:
          Shell.Execute("cmd", "open", "/C osk", "", SW_HIDE, false);
          [COLOR=#008000][I]-- or[/I][/COLOR]
          File.Run("cmd", "/C osk", "", SW_HIDE, false);
          These both work under Win7 & WinXP, too. So see what happens when using this approach under Win10. (Use the attached demo-apz to run some tests if you like. I'd be curious to see the results).

          Nb.
          When mapping Windows system files (ie. cmd, osk, etc...) neither folder-paths nor file-extensions are required. It's actually sufficient to just point directly at the target file itself. Example:
          _SystemFolder.."\\osk.exe" can be mapped as: "osk.exe" (or even just as: "osk")
          _SystemFolder.."\\cmd,exe" can be mapped as: "cmd exe" (or even just as: "cmd")
          Attached Files

          Comment


          • #6
            Dear Bio, I really appreciate your efforts but ...
            No problem on Win7 as you mentioned, Win10 last version no positive results.
            Launching a bat file from AMS solve the problem.
            A dirty solution, I hope in some elegant workaround.
            Thanks a lot for your time

            Comment


            • #7
              Am I correct to assume that the Windows 7 is 32-bit, and the Windows 10 PC is x64?

              Ulrich

              Comment


              • #8
                No, both are x64

                Comment


                • #9
                  Good enough. Windows 7 had osk.exe in both System32 folders, for 32-bits applications (such as AutoPlay Media Studio) and 64-bit applications.

                  Click image for larger version

Name:	SCRN-2019-05-05-01.png
Views:	343
Size:	5.2 KB
ID:	303304

                  In Windows 10 x64, you have osk.exe only in the System32 folder reserved to 64-bit applications, so it cannot be reached by a 32-bit process - but it works when you call a batch file. The work around is to use the Wow64 plugin, and turn off the file system redirection before running osk.exe:

                  Code:
                  Wow64.DisableFsRedirection();
                  Shell.Execute(_SystemFolder.."\\osk.exe", "open", "", "", SW_SHOWNORMAL, false);
                  error = Application.GetLastError();
                  if (error ~= 0) then
                      Dialog.Message("Error", _tblErrorMessages[error], MB_OK, MB_ICONEXCLAMATION);
                  end
                  Wow64.RevertFsRedirection();
                  When I remove the call to Wow64.DisableFsRedirection(), then I see an error that osk.exe cannot be found, as expected, because AutoPlay Media Studio has no access to it.

                  Ulrich

                  Comment


                  • #10
                    Wow, finally it works correctly.
                    Thanks Ulrich, when I see your answers I remember AMS great days!

                    Comment

                    Working...
                    X