You can use the Windows GDI functions like Rectangle, Ellipse, TextOut, LineTo, MoveTo etc. to draw in the window. Each of these functions take a device context (DC) as its first parameter. It is this device context that determines where the drawing appears. In your case use the GetDC function with the handle to the window to get the device context of the window where you want to draw.
«_Superman_» I love work. It gives me something to do between weekends.
In a general win32 program you should handle the WM_PAINT (and maybe the WM_ERASEBKGND) message of the windows you want to paint. In WM_PAINT you might get a HDC handle to draw on (with GDI functions[^]). If you are not working with a framework that gives you a HDC to draw on then you have to call BeginPaint()[^] and EndPaint()[^] in your WM_PAINT handler and beginpaint gives you a HDC draw on before you call EndPaint().
Its important to draw you window from the WM_PAINT handler because the surface of your window might get lost any time (at least this was the case before 3D accelerated desktops) for example when someone brings a window in front of your window and then it switches back to your window. In this case windows might send a WM_PAINT to your window to redraw its surface and the thing you drew on it will disappear if you don't redraw it from the WM_PAINT. You can't assume that the thing you draw on a window remains there if you perform drawing from outside the WM_PAINT handler.
For simple drawings, go with GDI... it'll give you a basic understanding of how Windows draws things. Obviously, this isn't really suitable for complex graphics, but it's a great starting point for someone with no experience with graphics development.
It really is relatively simple to work with, it may take a bit of a learning curve depending on your depth/breadth of knowledge in the area of C/C++ programming, sockets, web development (including services).
Any one can explain about MFC design pattern. Past 3 years Iam developing MFC application, but i never gone through such design pattern procedure. I have refered some of the articles, but i feel difficult to understand it. Can anybody help me....
1.what MFC design pattern?
2.why we need to go for MFC design pattern?
3.Any real time example there?
There is no dificult to understand ... in fact, you have to write so such code that could easely reuse it ... I think that is design patterns ... you could search on wikipedia ... and like hint, search for singleton pattern ...
MFC is a deprecated framework. Don't invest time in learning it unless you have to maintain legacy systems written in it. MFC is not just a GUI library, its a set of classes for a lot of other problems too but ppl are using MFC mainly as a C++ gui framework. Unfortunately I can't recommend a really good C++ gui library for you but Qt is definately a much better solution because its much more object oriented than MFC and its crossplatform. MFCism is a religion coming from the previous century, avoid it if its possible.
EDIT: I see there are some downvoter MFC fans here, but they are afraid to show their names and opinions... :P
MFC is not a deprecated framework, agreed that there are sections of it that are and always have been useless (all the collection classes), but it is still worked on and still offer good bang for the money for classic and modern application designs, especially when working with C++.
The design of the gui part is deprecated, and would say that its only half C++. I'm talking about gui because thats part is the most widely used from MFC. Among the helper classes I think there is some useful stuff but don't use them anymore because of crossplatform development. You can say "it works" even about the worst library of the world, its never a good reasoning. Its cost is zero if I'm right if you bought visual studio, but buying even the most expensive gui library is usually only a fraction of the development of a software. Of course you can put together nice gui in MFC, but its more difficult than doing the same with a better system. Not to mention the maintaining of the code, especially if a lot of ppl are working on it, and not all of them are MFC experts. You might be very good at it for now, but imagine how many things you must be aware of to handle MFC well: Win32 dialog resources, subclassing/hooking, window messages to some degree, etc... Its not a small piece... And its not just C++! A good gui library gives you a pure nice C++ interface.
EDIT: Its no problem to downvote something, the '1' button is there for this reason!
I need to draw a spikey 3D surface plot. It might include 300 x 500 points along the horizontal x and y axes and the height (z-axis) might be an integer between 0 and 100. I want the hight to be represented by colour banding...i.e. a point at the front of the graph with a value of 100 would be a tall bar going from green through brown through orange through to white at the top. And a value of 50 would only be a bar with green through to brown.
The most simple (and hopefully effective) solution I can think of is to draw a vertical bar for each point, rather than any triangle drawing as Excel does for it's surface plot.
My question is...how can I do this quickly? I'd do some vector maths to skip any points that don't need to be drawn (hidden bars) and merge others that sit on the same pixel, but could still have 1-2000 points to draw! So would it be possible/quicker to use a cached bitmap of a single full height bar and just copy a portion of it (depending on the z-value) onto a memory dc 2000 times or to use GDI+ and draw 2000 gradient lines/bars? I've not used GDI+ so am trying to work out which bit of darkness to stumble into and read up on!
Any thoughts/suggestions/relevant articles would be hugely appreciated.
Does the class output data to Excel and draw a surface plot within Excel? If so, thanks, but I've already implemented this as an interim measure. I actually need to do the drawing within an MFC application, so various settings can be modified and the results updated in real time.
Otherwise, if your class draws 3d charts within an MFC view, that would be awesome - yes please!
He is no fool, who gives what he cannot keep, to gain that which he cannot lose.
This class could control excel graph in two way : like excel ActiveX object inside of an MFC application or, could control an excel graph in new created file, in exterior of an MFC application but with control from inside of MFC application ... if you say that could help you, I will gladly give you ... and more, I will try to make a little demo ...