I am essentially trying to create something like a launcher for an Unreal application. The expected behavior that I was looking for is that when I launch an application the launcher would minimize or hide in the background and then whenever you close the application the launcher would then be restored.
I can successfully get the launcher to launch the other app and minimize itself but, for some reason my method for re-maximizing it doesn't seem to work. However, I was able to get it to work if I keep the app on screen(& not in focus) but, at a small size. It just seems that minimizing or hiding the app causes this method not to work
Essentially, I am using FPlatformProcess::CreateProc and grabbing the processID and then listening to see if the application is running. If it quits running then I (try to) restore the window.
My guess is there is something happening that is most likely pausing the app for some reason. I should also note that I overrode the UGameViewportClient class so that it doesn't pause the game even if it loses focus and that doesn't seem to work either.
I could possibly modify some code on the other application but, I want to keep that at a minimum. Any help would be greatly appreciated.
I was able to get a hold of one of the Engine developers with my question. Essentially, there are two options for doing something like this. First, you can use the MessageBus class and establish a connection between the two game instances. The drawback to this method however, is that it isn't really possible to detect crashes and things of that nature.
The second method (the approach I took) is to create a watchdog program in something like Visual Basic that you can use to set up a listener to a process exiting. This also allows you to set up other things like listening for application crashes or sending logs to developers.
Related
I'm a developer and a long-time Windows user with an obsession about making my system as convenient to use as possible.
Yesterday I thought about something that has always annoyed me in Windows and that I've taken for granted, and I realized that I have a better idea for how it could work, and I'm now wondering whether it's possible to tweak Windows to work like that.
The thing that annoys me is when windows steal focus. For example, I could be running an installer for some program. While it's working, I'll switch to my browser and browse, maybe entering some text into an email in my browser. Then suddenly the installer finishes and its window steals the focus. Now I'm in the middle of writing an email, so I might press a key that happens to be bound to a button on that installer, and then that button gets invoked, doing some action that I never intended to happen!
This is doubly annoying to me because I'm using a multiple-desktop program called DexPot, and when a window steals focus, it also brings itself to the desktop I'm currently on, which can be really annoying, because then I have to put it back into its original desktop.
How my ideal solution to this problem would work: Every time a window tries to steal focus, we intercept that, and don't let it. We show something like a toaster message saying "Foobar installer wants focus, press Win-Whatever to switch to it". If and when you press the key combo, it switches to the window.
The question is: Is there an easy way to tweak Windows to make this happen? I know very little about Windows programming. I do know AHK and if it's possible with that, that'd be great.
No, there isn't an easy way to add this behavior, but Windows tries to do this automatically.
In theory apps shouldn't be able to steal the foreground while you're actively using another app. Unfortunatly there are some scenarios where Windows can't tell the difference between legitimate user actions that should change the foreground and unwanted foreground-theft. The window manager generally tightens up the holes a bit with each new version of Windows, but also needs to make sure that apps can come to the foreground when the user wants them to, even if that desire is expressed indirectly.
For example, a process launched by the current foreground process can put a window into the foreground. This is necessary so that when a user launches a window from Explorer the newly launched process can open its main window. This permission only lasts until the next user input, so if an application is slow to launch and you start working on an email the app may lose its foreground permissions before it can use them.
See the SetForegroundWindow function documentation for a list of requirements for a process to be able to set a window into the foreground.
There are also apps which specifically make use of these requirements to steal the permission (by joining the foreground queue or synthsising user input to themselves), but I suspect in your installer scenario it is accidental.
I'm not sure what exactly is going on, but I suspect that the problem comes from the installer running as a service and accidentally stealing the foreground permission when it tries to launch the app on your current desktop.
It would be theoretically possible for an external process to hook into the foreground system to override this and show your confirmation toast, but it would be tricky to get right and would require significant low level code (I'd probably start with a CbtHook). It would not be possible in a scripting package like AHK (assuming you mean AutoHotKey) but would need to be native C/C++ code injected into every running process.
On Microsoft Windows (8), I would like to start a process, and prevent it from showing any windows at all. Alternatively, to force-close any windows that are shown. Is there a way to do this?
My application is this: I'm running an automated (nunit) test suite on my continuous integration (teamcity) server. The code under test is also used by an interactive application. Developers occasionally slip in a dialog with a user prompt, without realising what they are doing. This causes the CI process to stop, waiting for user input which never comes. I'd like to be able to dismiss any dialog that appears, or prevent them from being shown.
Even better would be to force an exception at this point, so that the test would also fail.
In my case, this is a C# application, and the dialogs shown are Windows Forms or WPF dialogs.
I did find a couple of similar questions. However each turned out to be solving a slightly different problem.
Stop a process from showing a window from C# (solves a different problem)
Preventing blocking dialogs/message boxes/hanging GUI from non-interactive processes on Windows? (promising solution but C++-specific)
Prevent child process from creating visible windows? (solves a different problem)
Have you considered asking your development team to have a "no dialog" mode of the app for testing purposes? Perhaps if you stopped referring to them as (!!*&%) they would be more inclined to partner with you. ;) Afterall, you do work at the same company on the same product :)
In any case, without a dev-specific solution, consider having a another app (process or thread) that continually sleeps for a few seconds, wakes up and looks for a modal dialog in your application. You can use APIs such as FindWindow to identify when a modal dialog has popped up. (Use Spy++ to get the class name for windows created by MessageBox and CreateDialog APIs).
I'm writing WPF application
application targets all sort of windows and low performance computers
so I want to write launcher/splash screen for it which will be displayed before application loads
I'm not sure what language to use or what technology
I want it to be very fast and lightweight
can you suggest anything ?
Displaying a flash screen is as easy as popping up a dialog. If the dialog has the various resources such as bit maps already included then it is quite fast. However one issue that will determine this speed is how much other stuff is being initialized at application startup before the code is hit to display the dialog.
So one option would be to have a very simple application that does nothing more than display the flash screen and then start up the actual application. A simple Windows dialog application would do that. You would need to figure out how to synchronize the actual application finishing its initialization and the launching application stopping if you choose this route. There are several techniques for this and the most likely would be to use an interprocess mutex or perhaps just look for a file to be created.
For a point of sale I work with that is launched as part of turning on the terminal we ran into problems in which the application would start before some required system services such as database manager were up and running.
We have found that some environments require much more time than others so a registry variable makes it easy to tweak the delay in the field.
So as part of the application initialization what we did was that when the application starts up, it displays a dialog with a progress bar. The progress bar does a count up and we have a loop that does a one second sleep then increments the progress bar.
The number of seconds to wait is a registry setting for the application with a default value.
One problem we ran into was that when doing development and testing in a debugger, the default value was way too long for impatient programmers wanting to get started so we have condition compile so that if it is a debug compile, the delay is set to a couple of seconds. Otherwise the default is 10 seconds. However it can be changed with a change in the registry value.
See also this Stackoverflow about a launcher.
If you want something realy fast and lightweight, C would be nice.
If you dont want to learn C, you can also make a console application with .NET and C# it's fast too
Edit for comment: You can use a library like SDL wich is very fast and powerfull, and can draw images from a console application.
I have an application that called several other .exe components written in delphi. The question I ask is that is it possible to close the delphi app along with all application it opened (when clicking the '[x]' button)?
Also, obviously, I have learned how to open and close external application, but in several cases like Windows Media Player it just doesn't seem to work... can anyone give me some solution to this?
Thanks in advance
You can use Job Objects , read the documentation for these functions CreateJobObject and AssignProcessToJobObject.
A job object allows groups of processes to be managed as a unit....
Examples include enforcing limits such as working set size and process
priority or terminating all processes associated with a job.
If you keep track of the applications you open, you can post a WM_QUIT message to each one's window handle in the OnClose event of your Delphi app's main form.
The same should work for Media Player, but it's hard to say when you don't give any information about how you opened it.
I'm writing a Cocoa application that installs itself as an menulet in the menu bar (i.e. like the volume or battery icons). When the program crashes, it isn't possible to use the Force-Quit dialog, because it doesn't show up in the list. Of course, I can still kill it using the command-line, but my users don't know how to do that. Is there any way to fix this, say by making the program show up in the Force-Quit dialog?
(Note: the app is Leopard only).
To be honest, the proper solution is to make sure your app never hangs or crashes for users. This should be your #1 priority, rather than figuring out how to let users deal with crashes and hangs. Obviously it isn't always possible to make sure your app never breaks in these ways, but it should definitely be the exception rather than the rule.
On another note, MenuExtras is a private API which I hope you aren't using to create your "menulet". Rather, the public class NSStatusItem (part of Cocoa) is the Apple-approved, recommended way to install icons into your menu bar.
Not really an answer, but hopefully helpful still ...
I think that most people who know how to force quit also know they can kill a process in the activity monitor. Just make sure it's not named '93AZkZ' or something.
You could provide a PreferencePane for your application that can send the proper signal to it, if you want to allow users an easy way to shut it down or restart it. This is the pattern that MySQL uses on OS X.