Can anyone recommend any good websites or videos to learn GDI?
Can anyone recommend any good websites or videos to learn GDI?
I don't know any specific websites.
I too am just learning GDI.
I recommend you "search" the archives at this site for "GDI".
Also, Charles Petzold's book: Programming Windows 5th Ed., available on Amazon.
I recently picked up, (for cheap) on Amazon: Windows Graphics Programming, by: Sanchez and Canton.
The usual solution to tutorials for Windows is theForger's Win32 API Tutorial. Considering they have GDI pages, I think that's another fine job done by theForger.
Try these:
The GDI
(this one is easier to start)
Win32 Programming - FunctionX
(this one is more detailed)
Why do you need to learn GDI?
Originally Posted by Adak
* Legacy support
* Smaller files
* Less overhead and bloatation
* No need to force user(s) to install various runtime/driver-packs in order for application to run
etc
Eh? I would say GDI is far more overhead than needed and extremely bloated.Less overhead and bloatation
I'm also not convinced about the smaller files bit since most resources in GDI apps are embedded in the executable thus making it extremely large.
As in what, the 1% that uses versions prior to XP? Also, you realize that many libraries support legacy operating systems, as well?
Besides Ace's point, what is a MB or two these days? Seriously? The overhead is negligible at best.* Smaller files
This one is rich. Oh, so you think your Visual C++ programs will run without runtime? Of course they won't. Why don't you go back to the roots and do pure Win32 so you don't have to use any external libraries?* No need to force user(s) to install various runtime/driver-packs in order for application to run
Point is, this is typically what installers take care of. Otherwise, you can just link them statically and the worry is out the window. Not a very convincing argument.
Point taken...
When you're writing a program that comes in at 100K without the bloat... an MB is a big deal.Besides Ace's point, what is a MB or two these days? Seriously? The overhead is negligible at best.
Actually it is a very convincing argument.This one is rich. Oh, so you think your Visual C++ programs will run without runtime? Of course they won't. Why don't you go back to the roots and do pure Win32 so you don't have to use any external libraries?
Point is, this is typically what installers take care of. Otherwise, you can just link them statically and the worry is out the window. Not a very convincing argument.
I'm thinking you don't have a lot of service contact with end users to realize the problem of reliance upon 3rd party libraries can cause people. I've seen entire companies have to shut down their networks for a day to install a new version of their software... and the 30 updates it forces and for some that's quite a hit.
I currently support a number of home theatre systems in my area. To a one, I got called "What does 'Please install latest version of Direct X' mean?" when the latest version of Media Player Classic Home Cinema came out. I ended up going out, at no charge, and updating all their systems for them.
So yes, it does matter.
You fail to see the point. 1 MB is nothing. Whether your executable is 100 KB or not. It is acceptable.
A fair point. However, this is a 3rd party library problem.Actually it is a very convincing argument.
However, it is also entirely possible to write libraries which do not force you to shut down all your applications to install or update. Mostly update.
And it's likely not going to matter when you install Qt, or some other small GUI library.
Actually, that IS the point... It's about the attitude.
Only a few years ago, when I was still working Pascal, we used to work to reduce code sometimes only by a few bytes. We cared how much of a customer's machine we occupied and smaller/faster was always better.
Now it seems the attitude has done a 180. Nobody cares if they are loading up 200megs to play a midi file (exaggeration to make a point). Customer machines are treated as infinite resources and programmers seem not to care that sometimes their code can force whole-cloth hardware upgrades on a company wide basis.
One or two MB may not be disastrous... but I've seen applications over 30mb that I can program in like 150K... It's a horrible lot of bloat that fails to consider what other applications a customer may be running concurrently. Think of the impact if everything is similarly bloated. More than once, when still on my career, we had to actually sell memory upgrades along with new software... and the customers were not amused.
No it's a programmer problem... Again, it's the attitude of not caring what you inflict upon your customers. I will agree that sometimes it's necessary to get a certain job done but the amount of raw bloat in software these days is seldom justified on any basis except "ease of programming"which in my opinion runs counter to the craft. We're supposed to be the smart ones that make life easy for end users, not the other way around.A fair point. However, this is a 3rd party library problem.
However, it is also entirely possible to write libraries which do not force you to shut down all your applications to install or update. Mostly update.
And it's likely not going to matter when you install Qt, or some other small GUI library.
I get your point. And I agree to a degree.
However, the point here is that there are limits in all and a megabyte is nothing.
It's another matter if it's 100 MB.
However, if it's a matter of rolling out my own solution that's inefficient, memory hungry, bloated and slow, I'd rather use a library at 100 MB that's fast and efficient. Don't roll out your own solutions just because they're smaller.
As a customer, I prefer software that works as I expect and is bug-free rather than smaller.
I can't tell you how many people are trying to roll out their own open dialog or file browser, only to find that it's inferior to the default one. Just because they tried to roll out their own solution!
Use an already tested solution instead!
Fair enough.
So would I... Anything I do is tested before it leaves my system... believe me, I don't sacrifice performance for size... It's simple rules, really: "First make it work. Then make it work right. Then make it faster. Then make it smaller."However, if it's a matter of rolling out my own solution that's inefficient, memory hungry, bloated and slow, I'd rather use a library at 100 MB that's fast and efficient. Don't roll out your own solutions just because they're smaller.
Yeah but it's like my Mom used to tell me as a kid... "You don't learn to cook by opening cans."As a customer, I prefer software that works as I expect and is bug-free rather than smaller.
I can't tell you how many people are trying to roll out their own open dialog or file browser, only to find that it's inferior to the default one. Just because they tried to roll out their own solution!
Use an already tested solution instead!
Sometimes the experience of not being able to beat the "canned" software is exactly the learning experience we need... and sometimes we actually do come up with something better.
I always enjoy these little debates of ours Elysia... keeps the ole noggin' working...
Last edited by CommonTater; 03-13-2011 at 08:02 AM.
It's one thing to create it. It's another thing entirely to ship it to your customers.
I must concur with the above statement.
I will digress...,
when my car gets a flat tire, I don't sit by the side of the road, waiting for some kind soul to stop and fix my tire. I jump out of my car a fix the damn flat, without skipping a beat.
If my engine stalls or has a problem, not to worry. I grab my tool box, locate the problem and fix it, myself.
I taught myself how to do that. What I couldn't figure out myself, I learned from others so that I could diagnose and fix it myself.
Why would I do that and not just call the tow truck ?
I bring the same attitude to programming....It's about the attitude.
I've been programming since the late seventies. However, never windows gui.
It's important to me that I know the internal working of how things work.
Not just how to install some third-party graphics tool kit.
How does installing a graphics tool kit teach me how GDI works ?
Correct me if I'm wrong, but, I don't think it does.
I enjoy working "under the hood", ...It's about the attitude.
why bother programming... when you can just buy software at the store ?
