I have a C# application that has an existing WinForm that I now need to display upside down.
The application will be displayed on a touchscreen Windows 7 device. If two people are using the device, one person is viewing it right-side-up while another user will be simultaneously viewing it upside-down. I will need to have one control displayed right-side-up while another control is displayed upside-down, each duplicate forms. Both need to be functional. It is not necessary for the title bar and Windows close, maximize, and minimize to be rotated.
Is there a way to easily rotate this Form and all of its contents without having to rewrite it from scratch?
Unfortunately, rotating controls is not directly possible in WinForms.
At least, not if you want them to retain their functionality. It would be relatively simple to draw the control into a bitmap, rotate the bitmap, and then draw that back to the desired location on the form. But you would obviously lose the ability to interact with the controls. They would just be static representatives of their original selves.
But making functional upside-down controls just isn't going to happen. I mean, you could try to write a bunch of custom drawing code for owner-drawn controls, but you'll still run into a bunch of bugs, corner cases, and compatibility problems. The Win32 controls that WinForms is based on just don't support this. No big surprise, really, considering they were invented some 20–25 years before anyone thought of computer screens that you could carry around in your pocket and rotate in any direction. There is a good reason that UI technologies like WPF came out around the time that touch screens and tablets did.
There are some possibilities that can be explored when it comes to flipping the entire screen, but that's not going to help when you want different controls going different directions. (And I guess it betrays my vantage point as a desktop app guy when I say this, but that just sounds like an incredibly confusing UI.)
If you absolutely have to have this, someone else is going to have to give you another route to hack it, perhaps along the lines of Dhawalk's comment: hosting the WinForms control inside of a WPF app that does provide built-in support for rotated controls. I don't know enough about this to make any concrete suggestions down that path. From a few minutes of searching, it appears that WindowsFormsHost does not actually support rotation transforms, so this may be a non-starter anyway.
Related
I've decided to learn a bit of WPF and I've created an application with the Mahapps Metro library and it interacts with a SQLite database (Unrelated but a bit of background).
I'd like to draw an object, let's say a triangle, in a new window.
I've seen this - Click - but the drawing of the shape needs to be visible to the user. So the user will see the line being drawn from point A to B to C to A. The image will "reload" after a few seconds i.e. Clearing the window/canvas and redrawing the triangle.
Are they any libraries out there that might make this easier or does WPF have something else I can use to achieve this?
Also, the redrawing of the triangle will be in a separate thread running a loop. Something tells me this isn't going to be very efficient. Is there a better way initiate a "redraw"?
My "answer" are some helpful searches and a few results that might help you get to the next step of deciding on a design that works for you.
Yes, WPF does have facilities to help you achieve some animation in drawing lines.
I searched for "wpf animate line drawing" and some interesting links for your research are:
How do you animate a line on a canvas in C#?
generating animated line
Drawing line "slowly" programmatically with wpf
Hopefully this gets you going in a good direction. Best of luck with your project.
I am standing between major decision in my WP7 application. It's majore purpose is to display images, always one at a time on fullscreen.
I need perfect support for pinch to zoom, moving image (while zoomed) and switching between images via flick gesture. Most of these things are already implemented in WebBrowser control, so I would just have to generate proper html source with path to image in Isolated storage.
Or should I use common Image control and implement these gestures on my own? I would like your advice before I make this decision.
Are you targeting Windows Phone 8 or 7?
Generally, I would implement my own.
Issues with using the web-browser:
1. Perf is going to be slower.
Memory footprint is going to be higher (though I doubt you really care about this - it's not going to be massive).
If you are going to favorite/download images, it will be harder (if at all possible) to navigate to them in the browser.
The background will always be white, unless you generate HTML each time that will control that bit.
The biggest issue is that the zooming in/out will be.. Janky... You won't be able to control how zoomed out the user can make it - meaning that they can zoom out enough to make the picture very small and it won't "snap back".
It's not a bad stop-gap, and the issues with it are not so big that one can say "no - don't do it", but they are enough that you should reconsider.
Is it possible to display an icon in the top left corner of a Windows Form that is a different shape than the standard 16X16 pixel icon?
It appears that Skype has an icon that is much wider than standard:
Is it possible in a Windows Forms app?
You can do this but it's probably more effort than it's worth just to have a larger icon.
Hans has posted an article that roughly points to the information needed to figure out an answer this question, but hasn't posted an answer itself and so I'll clarify.
The old (pre Vista) way to do this is to override the WndProc method on your form and handle the WM_NCPAINT message. Note that this means that you are now responsible for drawing the entire window frame (the window border, title, close / restore icons etc...), not just the icon - i.e. this is a lot of effort to do a relatively minor thing.
The newer (post Vista) way to do this is to use the DWM API - note that this API is not directly exposed through the .Net Framework and so you need to use P/Invoke for this in C#. The bit that you want to do is the section titled "Drawing in the Extended Frame Window", where you extend the area that you are responsible for drawing outside of the normal client area and into the window frame. This is less hassle than it used to be (you don't have to draw things like the close buttons), however still means that you take responsibility for a lot of things that you wouldn't normally, like hit-box testing for resizing and moving.
Basically its nowhere near as simple as providing a larger icon and for most applications its probably way more effort than its worth, however you can do this in C# and that article should get you started if you really want to give it a try.
I know your looking for a plain code way to do this, but I invite you to check out DevExpress manged (yes it's third party forgive me), just google it.. I seen this thread and I started asking questions at devexpress with support and got some impressive results that you might be interested in.
Here is the ticket I put in... http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q399941
Here is the result... http://www.devexpress.com/Support/Center/GetSCAttachment.ashx?id=684270b5-faed-415e-9010-64338523f8cf
So Far I used this on Xp, Vista and Windows 7 without problems using winforms only.
I hope this helps or gives you another option if the windows API don't pan out like you want on different versions of windows.
Thanks,
David
Don't think it's an icon, if you mean precisely the ICO image format.
Considering the Skype window is definitely ownerdraw window, that image can potentially be whatever you want format.
The trick is, basically, render an image skipping the pixels of some color (background color) of the "icon", so render it in "transparency".
This article can give you a hint:
Drawing Transparent Images and Shapes using Alpha Blending
It's old, but always a good one.
Yes. Override WndProc and implement WM_NCPAINT.
OK, I am sure some of you already know whats happening just by my title, since I get this is very common question. But my question is in fact little deeper, so please be patient wíth me.
All my programing I have done in past years were in Assembler, mainly 8051 and AVR as weel as in C, but also for microcontrollers. I was more fascinated by HW than SW. But I am also fascinated with function of OS, its APIs and so on. Few days later I told my friend that to create a very simple program to plot a function graph should be very easy, if you had math parser. He doesent believed me so I tried to make one.
I decided to go with C#, even I have no knowledge of OOP. But I thought that if I get everything done in one buttons action it would be like good old C.
So I get math parser to work, and than started to draw using Pen object. My first attempt was to draw simple line. After reading one tutorial a managed to do so, and I created simple axis for my plot.
But than I noticed something strange, when I minimalised my program, drawing dissapears. This made me think a bit about how this all drawing is done on system level.
I thought that system hold image of active window untill its changed. So when you move your windows it just changes its position in famebuffer. And when you minimase it, it just skips it during drawind to framebuffer.
But I saw its not like this. So, please, could you tell me why is this happening? I can read how to prevent it in many tutorials, but I would want to know more why. More, wheather this is becouse of how system API works, or becouse how C# drawing class works.
Also, this made me think what in C# and .NET libraries is function thats just a call for WinAPI function that works exactly the same way, and how many libraries and function do something more. Like if there was no function to draw line in GDI, and you could only draw dot, than C# would add function to draw line from this dots. I hope you understand me.
Thank you.
This is how it works in the Win32 API. When the window is minimized, the area which it occupied gets "invalidated" so the windows system knows that this area of the screen needs to be redrawn. This leads to a WM_PAINT message being sent to the windows program(s) responsible of drawing that area. You can read more about invalidating the client area (the area of which your program is responsible) here.
If you're truly interested in this stuff and want to get deeper understanding on how the system handles drawing (and other things, like windows messages), I recommend reading more on the Win32 API, e.g. beginning on Charles Petzold's classic, Programming Windows.
Your drawing didn't disappear, it simply isn't there. Bear with me:
to draw on the windows window, you have to respond to the callback indicated by the WM_PAINT message. It was in Win 3.11 and it is so NOW.
to draw on button click is a waste of time, because next form/control/window repainting will draw background color there
move the same code from button event handler to OnPaint - of course, handle the differences in semantics
windows don't save the copy of your screen buffer - your drawing - so you have to save it somewhere or draw it on-the-fly
In Windows (prior to Vista / DWM and MIL) the application is responsible for drawing its own GUI. That is, the application has to paint its own GUI When the operating system tells the application to do so. Resizing or moving a form will trigger the paint event. This is how it works in User32+GDI. That is, the application draws its own pixels.
A WPF application will however use the Media Integration Layer (Vista and Windows 7) and the "mil core" is responsible for drawing the visual tree of the application. In this case the operating system is responsible for the rendering, but the application is responsbile for what it wants to be rendered.
If you want to plot, use microsoft chart controls.
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=130F7986-BF49-4FE5-9CA8-910AE6EA442C&displaylang=en
or ZedGraph
http://zedgraph.org/
If you want to plot yourself: The window is redrawn when you resize.
You need to redraw your plot on the redraw event, or whatever it is called.
That is perfectly normal.
Also, use .NET 4.0, because else, you have no possibility of removing anything you drawed programatically, unless you remove (repaint) everything.
So here's the situation: I need to take a (user-specified) graphic, and allow the user to define and label regions within that graphic. For example, if you uploaded a picture of a face, you might want to define "right eye", "left eye", "nose" etc. Also, having defined the regions, if I select a previously defined region, it should be highlighted on the image somehow. These regions are (obviously) not necessarily rectangular, and they cannot overlap. And if you click within a defined region in the graphic, I would be able to identify which region was clicked on.
There are a couple ways I can think of for doing this, none of which are quite satisfactory. Another developer before me tried doing it with a transparent grid overlaid on the original graphic, fiddling with the background alpha/color for highlighting regions, but I think they rather kludged it. I could either get my hands really dirty trying to clean up their code, or try a completely new approach.
What would you suggest for maximum speed and user-friendliness?
Bounty added: for the best solution that will get me up and running in the minimum time.
The GraphicsPath class is made to do this. Keep a list of them along with the image. Draw the image first, then Graphics.DrawPath() to draw the regions on top of the image.
Hit testing is simple with GraphicsPath.IsVisible(). Iterate the list in reverse order so overlaps work.
Assuming you haven't decided yet on the technology you'll use, I'd suggest WPF; I find most graphics-related tasks easier with WPF (at least in version 4) and it's specifically geared for interactivity, so creating non-rectangular regions using mouse clicks and hit-testing clicks to select shapes would be pretty easy. Loading images is also easy.
However, if you haven't used WPF or Silverlight until now, there is some overhead in learning the basic concepts and APIs; so I'm afraid there's no real way I can recommend it as a maximum speed solution without knowing your (or whoever's will be working on it) competencies. That said, using MVVM and WPF would be definitely the maximum speed solution for me. Also the maximum user-friendliness since WPF enables quite interesting interaction models out-of-the-box, like multi-touch support (that's the trendy one that should be mentioned, right?) and easy non-standard layout and placement of controls.
You need polygons, saved as list of points. And you need hit testing for them. See the link:
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/40ebadc1-6154-4c7c-9cb1-d608a426b29c