C#, Windows Forms, Kiosks

A

Artanis0

n00b
Joined
Jul 13, 2004
Messages
57
Is there any way to make a windows form (preferably designed using .net and C#) a full screen and essentially un-closeable application. The goal here is for the app to be stable and run at a kiosk.

Obviously having the big ol' X button in the top right corner on a maximized window is not going to cut it when the public will be using this app.

Thanks.
 
Are you running Windows in kiosk mode?

If you don't want the close button in the caption, then you can just edit the Window Style in the WinForms designer and turn the ControlBox property to false.

If you want to make the window full screen, just have it resize itself after measuring the dimensions of the screen. You might need to handle WM_MINMAXINFO to make this work right; there's a sample on my website in native code at http://www.mooseboy.com/code/MFCSamples.htm. It is named Fully and was written for Visual C++ 4.2, I think. (Which means it was written in 1996 for Windows 98 and Windows NT 4.0. But I don't think WM_MINMAXINFO has changed.)
 
I would also like to be to protected from shortcut keys so I cannot be closed/minimized via keybord [except for a custom and secret key sequence that would close/minimize the app].

As for running windows in kiosk mode, I didn't even know windows had a Kiosk mode, I guess I'll look into that as well.
 
If you don't want the window to close, then code it so it doesn't. Add a handler for FormClosing() event, and cancel the event.

Your secret keystroke trick doesn't sound very secure. How you implement it will depend on what other controls you have in your window, but you'll probably end up needing to hook WM_KEYDOWN or WM_CHAR messages.

If you want to learn more about WinForms programming, I'd recommend Chris Sells' book on the subject. I wrote the foreword for it.
 
As an Amazon Associate, HardForum may earn from qualifying purchases.
I'm not sure how to make this work perfectly. However..

I'm not sure I agree that you should be trying to handle windows mesages. The other guys seem to be more familar with C++ because they are giving you MFC examples which are different than the .NET framework, however their intent and ideas seem to be on track.

Handling windows messages directly can be done in C# (I'd have to look up how). However, you should probably only resort to this if you have no other choice. I do not think it's a good idea.

I suggest you start playing with ideas and create a new project with one form.

Here's a few things I did in 30 sec or less and started to get the feel of a kiosk program.

Code: 
public Test()
{
	InitializeComponent();


	Rectangle screenSize = System.Windows.Forms.Screen.PrimaryScreen.WorkingArea;
	this.Width = (int) (screenSize.Width);
	this.Height = (int) (screenSize.Height);
	this.Location = new Point(0,0);

        this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;
        this.ControlBox = false;
	this.MaximizeBox = false;
	this.MinimizeBox = false;
        this.SizeGripStyle = System.Windows.Forms.SizeGripStyle.Hide;
        this.Closing += new System.ComponentModel.CancelEventHandler(this.Test_Closing);
}

private void Test_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
	e.Cancel = true;
}

Then I'd proceed to lock them out of the task manager, load the program on boot, and try to lock them out of opening the task bar and running any programs. You can handle key presses by extending System.Windows.Forms.Form and handling the ProcessCmdKey event like so (you have to create a new control (class) that inherits Form, this is how you catch keys in c#)

Here's a snippet I use to disable CRTL + TAB and CTRL + SHIFT + TAB on a tab control

Code: 
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
	// only thing this control does is disable CTRL+TAB of tabpages so
	// that the user cannot tab through the pages accidentally
	if(keyData == (Keys.Control | Keys.Tab) || keyData == (Keys.Control  | Keys.Shift | Keys.Tab))
		return true; // tell it I've handled this key (cancels it)
	return base.ProcessCmdKey (ref msg, keyData);
}

Anyway, I don't know if you can catch all the keys like this that you may need but I would definately try stuff like this before I tried using the windows messages in C#.

The code I gave you should yield a form with no border, control box, minimize box, maximize box, which cannot be closed with ALT F4. However you can still get to the task bar etc. I think you can fix this setting windows security rights, or catching some keys, or prehaps even disabling the windows key in the registry (though probably not a convenient idea), or some other means (What's Kiosk mode?).

Let me know if what I said here is working for you and if you have any questions on how to do this. I could probably throw together a sample app in a few minutes if you'd like.
 
aL Mac said:
However, you should probably only resort to this if you have no other choice. I do not think it's a good idea.
Click to expand...
I'm not sure I'd consider handling messages a bad thing; you'll probably have to do it sooner or later as you start to gain requirements that extend past the boundaries of WinForms. And any Windows program is handling messages, either directly or indirectly through whatever framework might have been used to write the app.

But I probably should've come out and explicitly said that you'd want the effect of handling the messages that I mentioned. If there's an easy override for handling the notifications in WinForms, then by all means use it at your convenience. It's just that I've grown weary of trying to find all the stuff they've renamed and making sure it does nothing more or nothing less than the underlying OS concept implied.

"Catching keys" for example, will require writing a system message hook. Does .NET provide a way to do this?
 
Well yes you are right, I would be dealing with windows messages. Somewhere I remember seeing something I was looking for to show but I cannot seem to find it. If you want to test for a certain windows message you have to define it I think.

This isn't bad, but somewhere I saw someone go out of their way when dealing with windows messages.

Here's a good example of how to capture keystrokes
http://support.microsoft.com/?id=320584
 
aL Mac said:
If you want to test for a certain windows message you have to define it I think.
Click to expand...
Yep. Even though the definitions exist multiple times in the framework (and therefore, in your working set), you have to look them up and redefine them yourself.

aL Mac said:
Here's a good example of how to capture keystrokes
http://support.microsoft.com/?id=320584
Click to expand...
The command key event is another artificial WinForms abstraction that doesn't exist in the OS.

As far as I can tell, it is fired for key messages in the application's input stream (eg, input keystrokes while it has focus). If the window doesn't have focus, the event isn't fired. If the user presses ALT+TAB or ALT+ESC, the event isn't fired. I don't see some of the Windows+Key messages, either.

I think that capturing these to truly lock-down the machine will require a system-wide hook. Is there a way to install a hookproc in managed code? Or some other way to react to those events?
 
Thanks Mike.

I did say I wasn't sure how to make this work perfectly. What you said about system hooks seems to be true. I did find some info on it in C#

Global System hooks
Hooks

edit:

Havent' had the time to read through these so they could be off somewhat between global/local/system hooks but I think it gets you to the correct direction.
 
You must log in or register to reply here.
Back
Top