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.
Related
I'd like to create some animations to make my (old) winforms app look a little nicer. The basic premise would be something like this:
I have a button I can press, and when I do, a random letter appears on top of the button and "flies" over to a textbox. Once the letter arrives at its destination, the letter vanishes and is appended to the text in the textbox.
This should be async, meaning there can be multiple letters on the way at the same time.
My problem is that I do not really know how to accomplish this. I know I can draw things on top of my controls by creating a graphics -object and drawing with it, but unless I force a redraw (Invalidate, or something else), the previous drawing is not cleared. However, if I do force the redraw, things tend to go all flickery (with or without DoubleBuffered set to true).
So I'm a bit at a loss in here, and despite my best efforts at googling, I wasn't able to find a suitable solution. Probably because drawing animations on winforms isn't all that popular (wpf would probably suit this ten times better), but I'd still like to at least learn if it is possible to accomplish.
What if you first draw it on a bitmap, then bitblt it to the screen/form. Look at the accepted answer in: Simple Game in C# with only native libraries
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.
I have quite an uncommon question: Does anyone know whether it is possible to draw something on the backside of a WPF Window?
Normally people create Controls or draw images on the front side of a WPF Window. However, I would like to draw things on the backside. Here is an Image taken with the Snoop tool. Snoop has the functionality of viewing a WPF Application in 3D. Using the so-called Zoomer it is possible to look behind a window.
I would like to either draw an Image or put a Control so that you can see it with using the Zoomer functionality of snoop at the back of the application.
Has anyone got an idea of how this could be done?
Thanks,
Christian
There is no backside.
What most applications do is simply replace the control/window by another one as soon as it has rotated by 90 degrees.
I want to create an app to declare microprocessor's pin as input/output with mouse clicks. I created a mockup - http://i.stack.imgur.com/GOHQ5.png. I think it would be best to declare each pin as an separate class so I can change its state easily, but I dont know how to achieve that along with graphical representation of it. Each square should be clickable and changin its color. Then foreach loop to iterate throu them and get state information of each.Should I go with WPF or Silverlight or just simple click events? What is the best approach to implement that in .NET?
If you want a website, do Silverlight. Otherwise do WPF because it will be easier.
I'd just do an image for the center piece, unless it's going to change size, in which case you could just draw it out of lines and an ellipse. Use a Canvas in your main window, not a grid. Make a Pin class that handles the state/color/positioning information. You can draw the square with a Rectangle.
Don't worry about MVVM, that's going to be more trouble than it's worth for your case.
Silverlight or WPF doesn't make much of a difference in this case. Deployment of the application (web or not) might help you chose.
Implement the state machine/processor as a class (ViewModel) and implement the UI as a View. That will help to keep the code clean. Look up MVVM Model-View-ViewModel.
You could do this in WPF, Silverlight or Winforms.
From a graphical perspective, it might be easier to reproduce your mockup in WPF or Silverlight. Choosing between WPF and Silverlight really comes down to how you want to deploy the app (eg for SL you need a web server).
Make your choice, start writing code and then come back here with specific issues as you encounter them.
Good Luck.
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.