Disable or Hide Save/Print Preview Dialog popups - c#

I'm working with an ActiveX control placed on a winform. I'd when the user tries to save or print, it will always show a dialog box first; I'd like to either immediately close the dialog box or keep it from displaying in the first place.
The control in question does not raise any events that would let me know what button they pushed, so I can't really cancel it out by looking for an "on_print" notification.

I ended up just sending escape via SendKey() whenever WM_ENTERIDLE was processed and that did the job. Dirty hack, but it worked.

Related

Close a Popup Dialog Box with Selenium Webdriver C#

I'm writing a test using C# for our website. When a record is deleted online, a popup dialog box appears that basically asks the user to confirm. Usually I can just inspect an element by right-clicking, but when this dialog box is up, nothing can be selected, in or out of the dialog box. When I tried using the IDE to see how it would handle the dialog popup, it gave this command:
Assert.IsTrue(Regex.IsMatch(CloseAlertAndGetItsText(), "^Are you sure you want to delete this batch[\\s\\S](\n|\r\n)All claims in this batch will be permanently deleted\\.(\n|\r\n)This action cannot be undone\\.$"));
That didn't work, so I also tried:
CloseAlertAndGetItsText();
But that didn't work either.
The box has two buttons, OK and cancel, and the OK button is already highlighted, so if there is a way to just do something like this:
driver.sendKeys(return);
But driver doesn't have a sendKeys command to call on its own.
driver.SwitchTo().Alert().Accept();
That should be able to handle the type of dialog box you're describing. I've been able to use it for any dialog I've had to come across, so it works pretty well. I've also read about using IAlert but since I've never needed to use it, I have no idea how well it works, but if my solution doesn't work for you, maybe look into that.

How to add a popup textbox for submitting a message - Windows Phone

Shame I have to install another toolkit, but this seems to be pretty useful: Coding4Fun InputPrompt.
I am having an issue with it though:
There only seems to be functionality for triggering an event when the input is 'completed' without being able to differentiate between whether the tick is tapped or if the cross is tapped.
Rushed into asking for help unnecessarily there. Found a solution, will post below.
Original question:
Users of my application can currently submit messages which they do by tapping on a textbox and typing in the message and then tapping send.
I want to make this cleaner by not having a permanent textbox for this and instead have users tap on a button on the application bar along the button which brings up the keyboard along with a textbox to type into, and when users tap submit the textbox and keyboard disappear again.
I can't see any way of creating a popup with a textbox in it, so how would I do this?
I'm using the WP Toolkit already for a messagebox with a ListPicker inside, by even this toolkit seemingly has no way of adding a textbox.
I'm not sure what your trying to do is even possible. However, what you could do is have a Parent Form which contains your ideal Interface. Within this Parent you could create an Event Handler that is listening for a response.
Then when it comes to that Textbox it actually creates a Child Form or Page. Which they can input their value into. Then the page automatically closes, which then the Event Handler will already know the change for you to manipulate with the rest of your Logic.
As mentioned above, normally you would go to another page. I don't know if my solution is viable, but it does accomplish your goal. I'd recommend possibly refactoring your interface so that it makes it slightly more elegant. That way your logic handles it more elegant as well.
Hope that helps.
Shame I have to install another toolkit., but this seems to do the trick just fine: Coding4Fun InputPrompt.
They've added input.IsCancelVisible = true to add a cancel button and then use e.PopUpResult.ToString() == "Ok" within the input_completed method to only submit when the tick button is tapped.

How can I temporarily prevent a form from getting focus/activating?

my application opens n forms and the user can freely switch back and forth among these forms.
When the user decides to confirm the operations performed on one of the forms, I would like to block the other ones until this process (which can potentially open MessageBoxes and/or other forms) comes to an end.
It is not enough to disable the forms, since the user can't do anything on them, but the Activated event is fired, and this is exactly what I want to avoid.
I tried to set ControlStyles.Selectable to false to all these forms, but it doesn't work.
Just in order to make it clearer, the forms cover the whole screen, so the users activate them clicking on the taskbar. This is the situation where opening a modal form and having the confirm code executed there does not prevent the Activated event to be fired.
Try to use Form.ShowDialog() method.
You can use Form.ShowDialog Method method to display a modal dialog box in your application. When this method is called, the code following it is not executed until after the dialog box is closed.

How do I block all keyboard and mouse input to my WinForms app?

I have a WinForms app that is retrieving data from a web service on a worker thread and I need to disable all input to my app until the data is loaded.
Currently, I create a semi-transparent form and place it over my application. When the data call completes I close this overlay form. This works fine accept that it causes considerable performance problems for users running the application over terminal services. I tried making the overlay entirely transparent but that still triggers two redraws of the entire window so this did not help at all.
I know that a common recommendation for handling this is to disable all the controls, but that would also redraw much of the screen so I'm looking for another way to block all user input. Any assistance would be greatly appreciated!
UPDATE: I should have mentioned that we have considered the modal dialog. Currently we show the overlay, start the data access thread then construct the form. If there is no better way to block input (App.BlockInput() might be nice) then we could use the modal dialog idea, but we would need to wait until the form construction had completed and there isn't currently a nice, central location to do this.
You could display a small modal (modalForm.ShowDialog(yourForm)) form with progress bar rolling on top of your app. This won't cause big areas to be redrawed.
If your app really is blocked while the operation is running, I'd do what Microsoft frequently does: open a modal dialog box with some kind of throbber animation or ProgressBar, and a Cancel button. Redraw is limited because you're only drawing the size of the new dialog, and input to the rest of your application is blocked because the dialog is modal. Also, users are much more willing to wait when you have some kind of status updates and or animation, because it looks like the computer is "working".
However, if there are operations your user can do while your web service request is running, it's better to leave the controls accessible. At very least, there should always be a way to interrupt/abort the process.
Update: Since you now changed the question: How long is it taking to construct the modal dialog? Why not simply construct the dialog empty, and then populate its controls? If all you have is a small dialog box with a single button and a single ProgressBar, then calling dialog.ShowDialog() should happen faster than your user can interact with your UI. Is that not the case?
One thing you could try for keyboard input is setting the KeyPreview property of the form to True. This will pass all keyboard events to the Form object first instead of to the individual controls. Create an event handler for the KeyPress event of the form and in there you can set the Handled property of the KeyPressEventArgs to True to prevent the key stroke from being passed to any of the controls. If you're currently retrieving data from the web service, set the Handled property True otherwise set it to False and the key stroke will be passed to the controls.
If someone has a good idea on how to handle the mouse input yet you're set.
I'd typically create a LockUI() and UnlockUI() functions in my form that toggle controls and flip a local form field that acts a flag to indicate a long running process. This approach works really well if you use a command pattern.
As previously mentioned, you could toggle keyboard input by using the KeyPreview property of the form (as suggested by TLiebe).
As far as mouse input is concerned, you could disable mouse activity by hooking the WinProc messages and intercepting mouse input messages. This is basically what KeyPreview does.

Desktop Development : Remember Target After Losing Focus

Is it possible to take focus from another program to respond to an event, but then once the response has been handled, switch back to the previous program and restore the cursor where it was?
This sounds like a weird question, but think of it along the lines of
User is typing in a text box in Program A.
A window for Program B pops up and user presses a few buttons to confirm something.
Program B returns control to Program A and restores the selection of the textbox.
If there is a complete C# solution, then great, but this sounds like it might require a little more effort than usual.
Any thoughts?
Personally, doing this could very likely result in the user selecting undesired values in the popup window. For example, someone is typing away in Word. Your application pops up a window, where hitting "Enter" selects a value ... such as the default button. Without wanting to, the user "selected" an incorrect value on your form.
Windows itself tends to do this, and it's very annoying. Quickly double-clicking a desktop shortcut to open an application and then switching back to (for example) an e-mail before the app launches, will tend to remove focus from the focused e-mail window and put focus in the just-opened application, causing your e-mail text or keyboard strokes to go to the just-opened window.
In my experience windows programs work just this way. It often appears that they don't because the user is returning focus with a mouse-click, which itself resets the focus. If it's a winforms app you can probably do something with the lost focus/got focus events at the form level.

Categories

Resources