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.
Related
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.
I wonder: Is there some way of programmatically preventing the Windows 7+ taskbar from grouping an application's icons on a taskbar when multiple instances get started? I am happy with the grouping as it is, except that in one specific application of my own design I would prefer ungroupped icons.
When I came across SetCurrentProcessExplicitAppUserModelID, I was sure that was the answer - I would simply generate a new random string for each instance and that would get me a new taskbar icon. Unfortunately, it doesn't seem to work that way - even though I set a different AppUserModelID for each instance, they still get all groupped under the same taskbar icon. I would almost suspect that I got it wrong and AppUserModelID can only be used to group "unrelated" applications but not ungroup the related ones, but this article seems to indicate that my use case should work just fine.
About the only other cause of my problems which seems reasonable is the function's documentation's remark "This method must be called during an application's initial startup routine before the application presents any UI or makes any manipulation of its Jump Lists.", but as far as I can tell, I am adhering to the condition. Unless SetCurrentProcessExplicitAppUserModelID cannot be used with command-line applications because the taskbar icon gets created even before the application starts?
My program is for rendering an animation clip, but every frame has to be computed before rendered. It seems that if the computation takes seconds, windows starts to recognize my process as "not-responding" and refuses to render anything any more, although in the Task Manager, the process itself appears to switch between "running" and "not-responding" all the time.
I have been searching solutions online for a while. A lot people suggested to delete some registry entries:
HKEY_USERS.DEFAULT\Control Panel\Desktop\HungAppTimeOut
HKEY_USERS.DEFAULT\Control Panel\Desktop\WaitToKillAppTimeOut
HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeOut
HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillAppTimeOut
HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillServiceTimeOut
But I could not find those entries. And according to the descriptions, all those entries mentioned are about controlling how long the system waits after the user requires to end a process or log off to kill a process or service. So they are not what exactly I want. I guess there must be some threshold to control when the system should start to consider one process as "not responding" and I want to change that threshold into a slightly bigger one.
Thanks for your attention and time, any suggestion is welcome!
You should avoid hanging the UI in the first place by doing your processing/computation in a background thread, rather than on the UI thread. If you're using WinForms or WPF, use a BackgroundWorker.
See here for some BGWorker examples: WPF Threads: Build More Responsive Apps With The Dispatcher
I'm using Microstation to build a model, so this is a similar process. About half way through building the model everything freezes up and adds the "application not responding" message to the title.
Disabling the Desktop Window Manager Session Manager worked for me, however in a enterprise environment this is not the best solution, as common users don't have rights to access the services panel.
Try disabling Desktop Window Manager Session Manager from services. Worked for me. That also disabled aero theme by the way. Win7 really looks fancy but it has to operate normally.
I'm facing a problem for an application I'm writing (http://code.google.com/p/blazingstars/issues/detail?id=25), where my program is a menulet (menu bar) application that uses the Accessibility API to interact with and control another program. I do the usual things like registering for the API notifications and getting the window list through API calls, etc., but I realized a while ago that if my program is started in a second Space (virtual desktop) after the program I'm interacting with is started in the first, my program will crash and burn because it can't access any information about its target. (Is there a way around that problem I'm missing?)
A simple solution would be to popup a dialog asking the user to restart the program in the correct Space, but for the life of me I can't figure out how to tell which Space my target is in, either through NSWorkspace or the Accessibility API, so that I can compare it to the Space that I'm in. Any ideas?
Note that setting the collection behaviour to NSWindowCollectionBehaviorCanJoinAllSpaces isn't going to do me any good because I have to do a bunch of work upon launch, so I have to be in the same space as my target right from the start.
I think you can do this with the APIs in CGWindow.h..
Specifically see CGWindowListCopyWindowInfo() and kCGWindowWorkspace.
I've used these APIs to do all types of things like getting window contents, window frames, etc...
If that doesn't work then you might want to try this private API:
extern CGSError CGSGetWindowWorkspace(const CGSConnectionID cid,
CGSWindowID wid,
CGSWorkspaceID *workspace);
The trick would be getting the connection ID of the target process.
You should probably redesign your app so that it delays its initialization until the app you want to control is in the current space.
There is no easy way to do this under Leopard because there are no official "space change" notifications, but the blog post and comments on this page may help.
In a fairly graphics intsensive application the requirements state that it should default to full screen mode even though the application is running under Windows. I know many games do this but I find it annoying. The default IMO should be to open in a window rather than full screen mode. I am proposing the first time the user runs the application they should select the default behavior. Am I wrong?
I think the annoyance-factor depends a lot on what the application tries to do.
If it is some utility that I might start while working in 5 different applications and it forces its fullscreen-ness on my, then I'd get highly annoyed.
If it is a specialized application that helps me with the entire workflow of a given task (so that I never or rarely need any other apps open at the same time), then fullscreen might actually be a valid default.
Whatever you do, just make sure that toggling the startup behaviour is very discoverable. Because no matter which way you'll go, some of your users will disagree with your decision. And for them it should be very easy to change to their prefered way.
I would follow the requirement the first time the application is launched. I would also provide a simple way to switch from full screen to windowed, for instance by pressing ESC (and another way to go back to full screen). Then I would store the mode when quitting the application and restore this mode at next launch.
Before doing the opposite of what your requirements say, I'd have the requirements changed.
However, what about giving the user the choice at install time?
The window at first-start-up should default to the optimal size for the largest proportion of users. For a graphics-intensive full-featured app, that may very well be full screen.
As for individual user preferences for window size, it seems to me most users won’t know if they want full screen or not until after they’ve started to use the app and see how much screen space they need and how much they use the window in conjunction with other windows. Asking them which size they want at install or first-start-up could thus be annoying and even confusing. It’s better to put such a setting under Options/Preferences.
Perhaps the best thing to do is save the window status on exit. Users who like it non-maximized thus only have to non-maximize it (and size it) once and then forget about it. The only consideration is to have some way to reset the window to the default (e.g., Window > Standard Size menu item) for novice users who accidentally resize or reposition the window to something bizarre and don’t know how to get it back. Alternatively, you could have a Window > Keep Sizes and Positions menu item for users to explicitly save the window status across sessions.
Go back to the requirements writers and ask them if they have considered non-traditional monitor setups, such as:
30" or larger monitor. Do you really want your app hogging up all the screen real-estate?
Multiple monitors. Which monitor will you run on? Can the user move your app from one monitor to another? Can your app span more than one monitor?
Virtual desktops. Can the user move your app from one desktop to another? Can they switch desktops while your app is running? Can your app span more than one desktop?
Such setups are increasingly common, especially large monitors. IMO, full-screen mode (the default for many older Windows apps) is becoming less and less useful.
The problem with presenting the user with the option of initially selecting fullscreen / vs windows is that they haven't used the software yet. How can they make a decision on which is better for them, without experience?
I would run the app in whichever mode provided the best user experience and then offer an option to change it both in the Preferences and though a hint while starting up the application for the 2nd time.