[kricker]

What is the difference in these 2 commands?

XBMC.System.ExecWait
XBMC.System.Exec

They seem to do the exact same thing. They both cause XBMC to minimize then restore after the called app is closed. Also, is there a way to call an app that doesn't have XBMC minimize 1st? Now that XBMC doesn't force itself to be ontop it would be great if there was one command that caused it to minimize itself and one command that just left the XBMC window alone.

[CapnBry]

The difference is that with XBMC.System.ExecWait it actually locks up the thread that made the call until the program closes, preventing it from processing further commands in your handler. They both always minimize XBMC and restore it when the application terminates.

EDIT: And at least under win32, there is no code in XBMC to not minimize/restore when launching the other process.

[kricker]

The difference is that with XBMC.System.ExecWait it actually locks up the thread that made the call until the program closes, preventing it from processing further commands in your handler

Sorry to be programmer dense, but I don't understand what that mean exactly. I assume it means XBMC will not respond to any commands until the called app is closed.

Is it possible for win32 to have code that will not minimize/maximize XBMC?

[junk]

Yes, it means it wont respond to any commands until the launched app is closed.

However, I ran a emulator for SNES that way, and all keypresses I did on the gamepad "stacked" until I closed the emulator. Then they all ran off at the same time... fixed this by blocking commands to XBMC through EventGhost though.

[kricker]

What I really need is XBMC not minimizing/maximizing itself and I can control that thru EventGhost. I guess I'll make a feature request.

[Livin]

What I really need is XBMC not minimizing/maximizing itself and I can control that thru EventGhost. I guess I'll make a feature request.

Ideally there would be options...

Onscreen
1. Minimize XBMC
2. Keep XBMC the same

Input
3. block input to XBMC
4. allow input to XBMC

so for example... if you wanted to launch an app with a small window as an "overlay" you should choose options 2 & 3 - thus the app would act like a pop-up window to XBMC.

I could definitely use this.

Kricker, have you put in a feature request?

[kricker]

Ideally there would be options...

Onscreen
1. Minimize XBMC
2. Keep XBMC the same

Input
3. block input to XBMC
4. allow input to XBMC

so for example... if you wanted to launch an app with a small window as an "overlay" you should choose options 2 & 3 - thus the app would act like a pop-up window to XBMC.

I could definitely use this.

Kricker, have you put in a feature request?

I've been too busy. Can you write up a detailed one if you get a moment before me? I think your idea is a good one.

[Livin]

Trac ticket created

Description...

Ideally there would be options for both Display Presence & Input Awareness.

Display Presence
1. Minimize XBMC
2. Keep XBMC on screen in same location (max, min, windowed, etc)

Input Awareness
3. block Keyboard input to XBMC
4. allow Keyboard input to XBMC
5. block Keyboard input, allow external API calls except changes to the primary video output.
6. block ALL input to XBMC (all API, keyboard, etc)

These would be used in combo to get desired effect...

Example 1: You wanted to launch an app (say it had a small window) as an "overlay". Thus the app would act like a pop-up window to XBMC and receive all the keyboard input. It would still allow external API calls to XBMC in case things are needed on the background.
Options 2 & 3

Example 2: You wanted to launch an app full screen and take over all keyboard controls but allow external apps to interact with XBMC. This could also be good for future functionality like Multi-Zone Audio control and secondary video outputs
Options 1 & 5

[kricker]

Cool. Thanks.