Our clients have fat fingers, and so do we. We take touchscreen netbooks apart to insert them into our custom hardware, and I write a software interface that shows up on the touchscreen. The problem is that it has about a 3/4" bezel over the screen, which means hitting that little red "X" becomes a challenge, especially considering reduced capacitive ability on the edges and corners.
Is there a way to make this standard close button larger? Of course in the application I can always make really nice 80x80 buttons that are perfectly usable, but there seems to be no way to override the default frame of the form. We have tried enabling Large Fonts and all the built-in accessibility features, but nothing seems to make it large enough to hit successfully.
Simply adding a toolbar button is also not much of an option. We prefer to utilize the standard look and feel of a normal Windows application.
Alternatively, should we be looking at making some sort of "kiosk mode" where we simply go fullscreen and do nothing involving the taskbar or title bar? How difficult is this to accomplish, if so?
Well, since you're setting up the hardware, I presume you're able to configure preinstalled software, including Windows. Can't you just go into Display Settings and make the title bar larger, so that the close button grows accordingly?
See MS Article about distributing windows themes: http://support.microsoft.com/kb/310514
Getting a large close button is fairly easy to do. It is hidden well since Vista, in Win7 it is Control Panel + Personalization + Window Color, Advanced appearance settings, Item = Caption buttons, change the Size. You probably won't like this much though, you'll get a rather large caption bar, lots of waste screen real estate.
Tackling this from the other end: your request is unusual. Most anybody that sets up a touch screen app wants to know how to prevent the user from closing the window. Windows Forms makes it too easy to design a bunch of forms and switch between them. That isn't much of a user interface on a regular desktop, especially not here. You can design your forms as user controls as well and switch them in and out of the main window as the user navigates through the UI. Not unlike, say, Microsoft Outlook. You can even turn your existing form into a control. Set its TopLevel property to False, FormBorderStyle to None, Visible to true.
Related
There are some programs such as Google Chrome and this:
They have a windows forms border that is different than the default. How do these programs do this and still allow the user to drag the window around? Is it possible in C#?
There are plenty of component suites (DevExpress, Infragistics, Telerik, etc.) doing this but you can do it on your own as well. But prepare to get dirty - really dirty!
Basically you have to catch the windows messages (yes, native!) and handle them properly. To make the form draggable is the easiest thing in this chapter (you just have to tell windows that the mouse is over the titlebar area even if it is not >> see here on CodeProject).
Let me get back to the painting: Don't do it!
There are so many things to handle ...
is your form maximized, minimized, normal state
which of the buttons (min/max/close) are enabled?
is it a tool window or a sizeable one?
is there a help button?
is the form sizeable? if so, you have to draw that border as well ...
... and so many more.
In addition, painting in the non-client-area is not as easy as painting usercontrols with a Graphics object. And even if that does not scare you by now, you might probably find yourself breaking the layouting logic of your forms' controls because the forms' size is the same as its ClientSize.
So, please consider to use DevExpress or any other toolkit. Speaking of DevExpress - I knew there was a free set of their fantastic controls and I'm pretty sure that the XtraForm (which does all the titlebar painting) is included as well.
Save big parts of your life and skip that chapter.
(However, if you're brave enough, check this article to do it anyway).
I have a form, originally developed to be used on XP, containing a .NET 4.0 ProgressBar control. It's part of a composite control, where I write some info on top of the bar using TextRenderer. (I didn't go for a label, because the transparency doesn't seem to work.)
I've now upgraded the OS to Windows 7, and it seems the whole look and feel of the controls has changed. The progressbar now has a kind of "swoosh" effect, a highlight that moves quickly from left to right. The problem is this animation is removing my rendered text. My app happens to update often, so the result is a blinking text on top of my status bar.
How can I fix this?
Any reason you have to write the text superimposed on the bar itself instead of underneath it, as everything else does? It sounds like it would be a lot easier to read the text if it were separate from the bar. That's certainly been my experience of progress bars as a user: keep any status messages away from the graphics.
EDIT: I've just checked, and if you don't call Application.EnableVisualStyles it uses the very old "big blue blocks" style, as far as I can tell. Personally I find this pretty ugly - I'd recommend that you stick with the nicer visual style, but move the text.
If you want to go all the way, you can remove calls to the Application.EnableVisualStyles method, which enables "colors, fonts, and other visual elements that form an operating system theme."
Visual Studio typically adds a call to this method in the Main method of a WinForms application.
I'm writing a system tray app for Windows (with much info gleaned from this thread). I have the ContextMenu working - you can right click and execute functions that way.
I want to have a modern, rich interface pop up on a left click, however, much like most of the built in Windows 7 (and possibly Vista) tray icons have. By this I refer to the Aero lining, and apparent ability to add seemingly arbitrary controls (e.g. volume slider, network chooser).
I'm not really sure where to start. Is it a matter of creating a "normal" window and restricting it heavily? If so, how? (If it comes down to Windows Forms vs. WPF, the latter is preferable).
For what it's worth, you can display anything you like when you receive the mouse click on your notification icon. Usually it's a pop-up menu, but you could show a window instead.
I am trying to create a panel which will have a set of "buttons" on it.
These buttons should have the following behaviour:
Appear similar to a tag (with
rounded edges)
Contain a red
cross to remove the filter/tag from
the panel, similar to the way internet
explorer tabs have an embedded cross to close the individual tab.
allow the user to click
on the tag and respond like a normal
button (as long as the click is not
in the red cross)
Number 1 is no problem, this is just appearance, however, regarding numbers 2 and 3, I am not sure if there is already code out there do to something similar...and I dont really want to reinvent the wheel if I can avoid it!
My question is: Does anyone know if there is something out there in infragistics which will do this simply, or will I need to write this myself by subclassing winform buttons?
Thanks in advance!
Is this new development or maintenance of an existing project?
If it is maintenance, you have a somewhat tougher time ahead. You'll implement a UserControl, probably segmented into two buttons. Use docking to get the behavior as correct as possible. The far right button would contain your cross image; the left (which would need to auto-expand as you resize the control) would contain your primary button behavior. Play with the visual styles until you get them right (EG, removing borders, etc).
If this is new development, and you haven't gotten too far into it, you might consider using Windows Presentation Framework (WPF) instead of WinForms. It will be easier to build the control and get it to look exactly how you want it. WPF includes an extremely powerful control compositing system which allows you to layer multiple controls on top of each other and have them work exactly as you'd expect, and it carries the added advantage of allowing full visual control out-of-the-box.
Either way, this is more work than dropping in an external component ... I've used Infragistics for years, and I can't think of anything they have which is comparable. The closest, but only if you're building an MDI application and these controls are for window navigation, is the Tabbed MDI window management tools -- and there, only the tabs (which replace window title bars) have this behavior.
I don't think that infragistics can do something like this. The UltraButton control can't.
Implementing a own control wouldn't be that hard.
your probably going to have to make a costume control for this type of work.
I need to create a status dialog for a Windows Mobile application (C# 2.0) that needs to be updated, so MessageBox is out. I tried to just create a new Form class, change the size and call ShowDialog, but it always comes up full screen (minus the title bar of course). The only way I could figure out how to display it small is to set FormBorderStyle to None, but then it really does have no border or title bar at all!
I want it to still look like a message box (with title bar and borders) but, I need to actually use a Form so I can update it.
Any ideas of how to do this?
The challenge here is the WinMo shell itself. What's not apparent is that the caption on the form (at the top of the screen) is actually not the caption of the Form you see - it's a completely different application. So to get your Form to "float" requires subverting the way the shell handles Form display. A quick and dirty way is to set the Form BorderStyle to none, but then you lose your caption bar. An option then is to manually draw it in with a FillRect and DrawString in OnPaint. Not too difficult and doesn't require any P/Invoke shenanigans, but it does require that you take the new header into consideration when you layout your controls.
Another option is to use P/Invoke and manipulate the Form's style bits yourself. This works well, but take care that you do it in the right location in code, as some bits have to be set on Window creation. Also beware the shell, as it might want to change the bits back on you - so this mechanism requires more testing and attention to detail. IMO this is a better route, and I've blogged about it in more detail here. That blog entry isn't specifically about floating forms, but it covers style manipulation well. For more specifically on non-fullscreen Forms, see my other blog entry here.