locked
After launching or Activate an App, the Main App goes into background.

    Question

  • We are doing an enterprise app. Our app will not be listed in App store.

    Task:

    I need to launch an app to turn on the camera light on/off.

    issue : Some Tablet Camera don't respond to Mediacapture for the task. The one we selected has this issue.

    I had tried all means using mediacapture api to do this task. Found out that mediacapture can not talk to the specific OEM-tablet's driver. However, the OEM has provided me their DeskTop-base exe file for this task.

    I managed to use below code to call the DeskTop-base exe file and it works. The camera light turn on.

    Problem:

    When user press the button to call the desktop-base exe file, the camera light get turned on.

    But the WinRT- App goes into background or goes in to hiding, the user need to swipe from Left to right to bring back the winRT-App.


               string batFilePath = @"C:\Program Files (x86)\OEM-name\lightsw\lightsw.exe";

               string command = "AppRT://" + batFilePath;

               var options = new Windows.System.LauncherOptions();
               options.DisplayApplicationPicker = false;
               options.TreatAsUntrusted = false;

        bool success = await Windows.System.Launcher.LaunchUriAsync(new Uri(command),options);

    would appreciate your help on this matter. Thank

    Monday, November 17, 2014 12:25 PM

Answers

  • Hi FireDance,

    This is expected behavior and there's no good way around it. Launching a file or protocol switches to the default handler with no expectation of return.

    Launching an app via protocol like this a hack in the first place. Since you are a side-loaded app look into writing a Brokered Windows Runtime Component to allow proper use of desktop API and communication with a desktop back-end.

    See:

    Brokered Windows Runtime Components for side-loaded Windows Store apps

    • Proposed as answer by Magnus (MM8)MVP Tuesday, November 18, 2014 10:03 PM
    • Marked as answer by Jamles HezModerator Wednesday, November 26, 2014 9:47 AM
    • Unmarked as answer by FireDance Friday, November 28, 2014 5:32 AM
    • Marked as answer by FireDance Friday, November 28, 2014 5:38 AM
    Monday, November 17, 2014 10:36 PM
    Owner

All replies

  • Hi FireDance,

    This is expected behavior and there's no good way around it. Launching a file or protocol switches to the default handler with no expectation of return.

    Launching an app via protocol like this a hack in the first place. Since you are a side-loaded app look into writing a Brokered Windows Runtime Component to allow proper use of desktop API and communication with a desktop back-end.

    See:

    Brokered Windows Runtime Components for side-loaded Windows Store apps

    • Proposed as answer by Magnus (MM8)MVP Tuesday, November 18, 2014 10:03 PM
    • Marked as answer by Jamles HezModerator Wednesday, November 26, 2014 9:47 AM
    • Unmarked as answer by FireDance Friday, November 28, 2014 5:32 AM
    • Marked as answer by FireDance Friday, November 28, 2014 5:38 AM
    Monday, November 17, 2014 10:36 PM
    Owner
  • Hi,

    For my question, I understand the reason behind it now.

    But this problem has not been resolved using the Broker component. still working on this issue. I open another thread.

    Friday, November 28, 2014 5:37 AM