Hi
Is there any way to find out if the close button (x button on form) was clicked. However without involving FormClosing and FormClosed events ?
Without those Events? That's a tough one...no, I don't think so.
I mean, you hook yourself into the message pump of the form to figure out if those actions were invoked, but seems like a little overkill to me.
You can use PreProcessMessage to see the message on its' way to your form.
Related
I want to simulate a simple left mouse click that would be "pressed" after 5 seconds I clicked a simple button form.
enter link description here
I tried that way but it didn't work. Couldn't things be simplier?(sry I'm new here)
Unfortunately for a relatively low level operation like this, you'll have import the user32 WinAPI dll and do exactly what the answers in your link suggested. The only simpler thing to do is to use a library someone else built that wraps around the WinAPI, like http://inputsimulator.codeplex.com/ as suggested in this answer:
https://stackoverflow.com/a/15146334/3063835
It's not 100% clear from your question, but this is all assuming you want an actual "click" message to be sent to your form. If you just want to simulate a click event on a control in your form, you can always just call the click event handler when appropriate!
I'm building an app in C# using VS 2008 - I've added a method of checking if a file has changed when it is closed, but this only works for the File>close menu. Is there any way to get the red X in the top right to actually do anything before shutting everything? If so, how? I've only been doing C# for a few days, and this is incredibly confusing - there are no methods for the overall interface window anywhere. Help is much appreciated. Thanks.
Use the Form.FormClosing event. Or the FormClosed event, that comes later and cannot cancel the closng.
And from the File|Close menuItem, just Close() the Form.
If you do that, you have 1 spot (FormClosing) where all the possible ways of closing a Form (including ALT+F4 and TaskManager) converge.
Do take a look at e.CloseReason, you don't want to be in the way when it is for example WindowsShutDown
You could probably do it through the window's closing event: http://msdn.microsoft.com/en-us/library/system.windows.forms.form.closing.aspx
I have a C# windows forms application. The way I currently have it set up, when Form1_Load() runs it checks for recovered unsaved data and if it finds some it prompts the user if they want to open that data. When the program runs it works alright but the message box is shown right away and the main program form (Form1) does not show until after the user clicks yes or no. I would like the Form1 to pop up first and then the message box prompt.
Now to get around this problem before I have created a timer in my Form, started the timer in the Form1_Load() method, and then performed the check and user prompt in the first Timer Tick Event. This technique solves the problem but is seems like there might be a better way.
Do you guys have any better ideas?
Edit: I think I have also used a background worker to do something similar. It just seems kinda goofy to go through all the trouble of invoking the method to back to the form thread and all that crap just to have it delayed a couple milliseconds!
I would use Form1_Shown()
Use the Shown event. It seems to suit what you need, and will only display the first time the form is shown.
Form f1 = new Form();
f1.Shown += new EventHandler(f1_Shown);
public void f1_Shown(object sender, EventArgs e)
{
// Show dialog in here
}
Try the "Shown" event:
Form.Show Event
Using a Windows.Forms.Timer is a good, stable, well-known, and easily understood technique for doing what you want. I would avoid any other timer objects.
The form's Shown event works well.
Overload / override the Show method. (My preferred technique for greater control.) In this method, I would do the checking needed. When ready, I would call the base.Show method, then do any other processing, such as message boxes, prompts, logging, or whatever.
HI,
I have a form in C# app. On this form I capture a KeyDown event Alt+U which will open a second form. In the second form I have a toolStripButton with shortcutkey Alt+U (the same which I used to open the form with) which prints a document. Now, my problem is when I open the second form It will automatically trigger the event of clicking toolstripbutton since it has the same shortcutkey as I used to open the form with. How can I prevent this from happen.
Regards Johan
This doesn't answer your question, but you really should think about making two different shortcut keys for these two very different actions. Having two identical shortcut keys that do two entirely different actions is very confusing IMO.
To answer your question though, I would have some property on the second form like "ShouldRaise" or something, and only raise the Alt + U event in the second form if that flag is true. Set it to false initially, but then in the KeyUp in the first form, set it to true.
Would it not just be easier to change the shortcut of one to something else? I agree with BFree its not the best design have the same shortcut for 2 completely different functions. All shortcuts/accelerator keys should be unique.
Why not change the shortcut for the form page changing to something like:
Ctrl+Right (Go to next page)
Ctrl+Left (Go to previous page)
On the second form do you actually have a ToolStripMenuItem instead? (a ToolStripButton doesn't have the ShortcutKeys property).
Do you instantiate a new form when the user presses Alt-U on the parent form?
Did you check the sender object on the handler that prints the document to see if it was the parent form?
Can't seem to reproduce your problem; a little explaining would help.
Another easy solution is to do some check of what form you are in from the event listener. You could just return inside the event handler inside your second form.
Again not the most elegant solution but should be a decent fix.
We need to handle this event in the base form, regardless of which controls currently have focus. We have a couple of global key commands that need to work regardless of control focus.
This works by handling the PreviewKeyDown event in the form normally. When we add a user control to the form, the event no longer fires.
Am I missing something trivial here? Or do we need to handle the event in the user control first?
Thanks for your help!
Thanks Factor. When I get more time :) I'll get it working 'properley'!
The hidden menu you are using works fine for shortcuts that are valid menu item shortcuts, but if you want to use any key as a shortcut (such as Page Up/Page Down), you'll need a different trick.
Another way to do this that doesn't involve P/Invoke is to set the Form.KeyPreview property of your form to true. This will cause all key presses to be sent to the form first, regardless of which control has focus. You can then override OnKeyDown, OnKeyPress, and/or OnKeyUp to handle the key press before any of your controls.
This is probably not the best way of doing it, but the first way that comes to mind.
In your forms constructor, after you call InitializeComponent(); do something like this:
foreach (Control control in this.Controls)
{
control.PreviewKeyDown += new PreviewKeyDownEventHandler(HandlePreviewKeyDown);
}
I THINK that should do the trick. In your HandlePreviewKeyDown method you can then do your work and it should trigger regardless of which control has focus.
PreviewKeyDown only works when the control has focus. It sounds like you should look into an application level hook for a special shortcut keys. You'll have to do it with a P/Invoke. SetWindowsHookEx on pinvoke.net is a good place for an example. Here's a MS KB article about a mouse hook in c#, which appears to be expanded to a keyboard hook in this article.
We ended up doing this:
I found a workaround for this by setting up a hidden menu item by setting:
ToolStripMenuItem.Visible = false
(Thanks to this article).
It appears that the Main Menu of a form always gets searched for your shortcut key combination. This works regardless of whick control has focus