"Not responding" message if the user clicks in the SplashScreen | WPF - c#

I have an WPF application which takes a little bit to start up, I have a SplashScreen which tells to the user to just wait for a bit till the application is completly loaded. So far so good.
The problem is the user (like always), and if he starts clicking desesperatly everywhere in the SplashScreen, he gets the typical Windows™ message saying "This program is not responding", in this messagebox he can choose to close the program, this will close another process where I make all the loading stuff, but not the WPF app. Then the WPF Application starts, but you cannot do anything on it. This behaviour doesnt happen if the user clicks just a couple of times.
So my questions are, Is it possible either to block this message from Windows™, either block the user interaction with the SplashScreen?
Thanks in advance for your suggestions.

Any slow processes should be in a separate thread to the GUI. This will keep the GUI responsive to user input.
BTW, if you display a progress bar (even a fake one that just moves 1% every second) the user should be more patient as they can see that the application hasn't crashed.

Related

C# WPF Multithreading with real-time PLC

I have an application that monitors bit states from external socket/Ethernet connections, known as a PLC device.
These states trigger database calls and UI updates, some of which require Modal dialogs, others require Modeless dialogs.
The issue is that the process needs to continually monitor even when a Modal dialog is displayed.
I have tried using a DispatcherTimer, but this will block when a Modal dialog is displayed. I understand the reason why.
I tried a standard Timer, but I get an exception stating something like 'Some UI components require the thread to run in STA mode.'
So I create a standard Thread and set the ApartmetState to STA. The thread runs just fine after adding DispatcherInvoke around the part of the processing loop that requires UI interaction, but whenever a Modal dialog box is displayed, the thread is blocked until the Modal dialog is closed.
Now I really do not want to get into inter-thread messaging and over-complicating the whole thing.
I have also tried putting the Modal dialog into its own thread whenever a Modal dialog is needed. Everything works fine and it was almost acceptable, but the owner window of the application is still accessible, essentially making the Modal dialog a Modeless dialog. I tried setting the IsEnabled flag on the owner window and at first I thought that would be okay, but it is still active when clicked and hides the dialog.
Any suggestions?
I have solved the issue! I reverted back to a standard Timer and was able to get around not requiring STA mode; this reguired another judicial placement of Dispatcher.Invoke.
Now everything works as I expect.

Prevent MessageBox from minimizing other windows

In my project I have a MessageBox that pops up from time to time.
When I'm playing a game and the MessageBox appears, the game is minimized and I'm back to the desktop.
This might depend from app to app, but this specific app/game minimizes when MessageBox appears.
How to avoid this behavior? Is there anything I can do to the MessageBox to make it lose focus/not activated ? I tried to look at the MessageBox methods but no luck.
It sounds like you want the message box to be able to display while the rest of your code is still running. Type of messagebox you are using is modal and needs to be closed until it allows you to interact with the other open window.
I suggest you start a new thread for the message box so that the thread can continue to run allowing you to be able to interact with the other windows.

Why is this WinMobile (Compact Framework) app hanging after photo taken?

I am having a very difficult time trying to debug/fix an application.
Briefly:
- I created a "wizard" type app that starts with the user taking a photograph (using the common dialog for photos)
If the user tries to use the text input window (SIP) (the little keyboard input window) after a photo is taken the event loop seems to hang - the event is not processed or is delayed for a while.
If the user does not take a picture the SIP keyboard works great.
This only happens on some of my devices. Specifically it is not a problem on an MC65 but is a problem on an ES400.
It appears that the app's event loop gets screwed up with the way I am displaying forms and taking photos.
If created a simple test app with single form containing a button (Event handler takes a photo) and a text box that accepts input. That works fine. But it is only a single form app that does nothing else.
When I combine the photo taking with my form displaying (making a "wizard" ) things go badly.
I wonder what kind of event loop should I be running?
Essentially the user takes a photo then goes through some forms (I hide one form and show another when they click the "next" button.)
The Form.Show is called from the main form after a picture is taken and then I have something like:
while(UserNotFinished)
{
Application.DoEvents()
}
Where UserNotFinished is a flag set from my wizard/forms after the "submit" button is pressed.
I will be happy to provide more code but not sure what would be useful.
I am new to C# and CF development (lots of years of C++/Win32)
The real confusing part is that this works on one device but not on another. In fact, the device hangs completely. It ends the activesync connection and sometimes I have to hard reset by removing the battery.
I think your problem stems from the while(true) { DoEvents(); } and perhaps how you are trying to go between forms. The only time I've used the DoEvents() method is when I'm already in the scope of a windows event and I need to be sure something in the message queue is processed so screen updates are correct. I'd suggest making a controller class to manage the screen flow for your wizard. You can control the screen flow by either using ShowDialog() and execute the flow control directly in the scope of a single call, or you'll have to use Show() and an asynchronous mechanism such as subscribing to and handling specific form and control events in the controller class. Also saw the comment about introducing another thread, beware that Forms belong to the thread they were created in and you must Invoke(...) all Form members in the context of the creating thread.
Hmm. Very strange
I started a new thread and basically call Application.DoEvents() in in as well and it seems to fix the problem...
I don't know why the
while(true)
{
DoEvents()
}
in the main thread doesn't work.

WPF - Show an application hidden but active in the Task Manager

I would like to set up a persistent state for my application. Let me explain.
The startup time is kinda long (mostly due to many database requests to a remote server, which take 5 - 10 seconds, and even more since my users usually have too much applications running...) and I'd like to set up a way to hide & show my application when needed.
What I am doing now is to only reduce app to tray when user clicks on the red cross. (The application really exits only when a user chooses File -> Exit).
All users are launching an installer which is checking the version installed, then the version available online, and update the app if needed before launching it.
Now, I'd like it to first check on the process monitor (the one found in Task Manager, Processes tab), and if a process is already running for the application, it'll just show the window again. Otherwise, if no process is running, we can process the classic-check-for-update-then-launch steps.
This would especially remove a lot of stupid customer requests I regularly have ("hey, your application takes too long to load, so I clicked on it again 5 times and it launched 6 instances!!!!" :/ ) and therefore save me a lot of useless time spent asking them to stop launching 50 instances of the same application cause it won't make it any faster...
So my main question is: how to perform such a trick in C#/WPF?
For now, my minimization process is kinda simple (even though maybe too simple): I just hide the window & the task bar entry. Now I don't know how to show it back from my installer
Any ideas?
Your customers' requests can never be stupid - they pay you money.
To bring window to front - create system wide mutex and check its presence on application startup. If it's there - use interprocess communication mechanisms to send message to that other instance to bring its main window to front (a window message or named pipe - both are fine). Here is an example (make sure to check related answers too).
And by any means show splash screen as soon as you can to prevent relaunching application again and again. If it does not appear in 1-2 seconds (2 is too long) it's bad. Responsiveness of your application makes feeling like it works faster.
Is it something like this you're looking for?
foreach (var p in Process.GetProcesses())
{
if (p.ProcessName.Contains("myProcess"))
{
//process is already running
}
}
Or, with LINQ:
if (Process.GetProcesses().Where(p => p.ProcessName.Contains("myProcess")).Any())
{
//process is already running
}
If the users complain about startup times, maybe consider checking the version on exit, instead of startup.
I have answered a very similar question yesterday. The only bit that's missing there is how to hide and show the window: use Window.Visibility, set it to Visibility.Hidden to hide the window and to Visibility.Visible to show it again.

calling the user attention outside of app

I want to create an alarm app for myself. On certain conditions (i need to poll websites) i want my app to inform me and make it HARD TO MISS. So i can take appropriate action or ignore it if i need to do something else.
I wrote a test app and using a BalloonTip (ShowBalloonTip with notifyIcon) isnt great. One of my previous apps brings the window in front of you and does a MessageBox however that doesnt always work or work well (if i somehow miss it or accidentally forget to click ok no futher messages will occur).
What are your suggestions?
You could also make it a system tray application and change the icon out if there is something which requires attention, a la a messenger application. That may not be "hard to miss" but I am trained (for better or worse) to look down at the icon tray when I see something blinking.
Where I work, we have a TimeTracker application (built in house) with which developers are supposed to log what we worked on and when. I am notorious for not using it. So, I wrote my own (Windows Forms) version for my own use which, every hour opens up and takes over my screen:
It is a frameless dialog which consumes the entire screen.
TopMost = True.
On resize, it sets WindowsState = Normal and resizes to fill the screen.
While it is open, it polls for taskmgr.exe and procexp.exe and kills them if found.
It disables the start menu to prevent cmd.exe commands from the menu in Windows 7.
The only way to close it is to enter a log, only then is the OK button shown!
So far, it's working out well - no one has been able to break it!
My less drastic suggestion would be to have a notification which pops up momentarily above the system tray. After a second or two, fade it out. Keep showing the notification every 30 seconds or so until it is dismissed.
Always-on-top window in the corner of the screen?
You could always set your window to be a top most window, make it full screen, and activate it. It would be very, very hard to miss...
Granted, it would also be very annoying, and not something I'd do to other users...
My "real" suggestion would be to use sound along with standard notification methods if this is going to be used by other people, as that's an easy way to grab attention without necessarily killing their workflow. A modeless window that appears in a corner of the screen, especially if combined with sound and color, can be very effective to grab attention.
The industry has been adopting these ambient orb devices and variations of it when such a hard-to-miss notification is required. It is used for tracking the stock-market and for broken-daily-builds.
http://www.ambientdevices.com/cat/orb/MAN_Ambient%20Orb_3-23-03.pdf
Regards

Categories