Thread: #include <gdiPlus.h> problem with Code::Blocks

You probably need to set up an include path (dunno how to do it for C::B, though).
Also be aware that GDI+ is a bad API that you should not use outside your assignment. It is deprecated. You should use DirectX for any graphics in Windows (or OpenGL; but that probably won't work as well as DirectX for some things).

Originally Posted by Elysia

Also be aware that GDI+ is a bad API that you should not use outside your assignment. It is deprecated. You should use DirectX for any graphics in Windows (or OpenGL; but that probably won't work as well as DirectX for some things).

Sorry, what?

When was GDI+ ever depreciated?
Why is GDI+ not an easy and reliable API to use for 2D drawing?

Please link me to your source.

AFAIK it was GDI that was depreciated, never GDI+.

But WIN7 re-introduced support for GDI drawing under the WDDM.

GDI+ is also available for all versions of MS OS's up to and including Win7.

I find GDI to be a quick and reliable RAD drawing method, especially after the changes in 2002 to the way GDI objects are handled by default in MS OS's.

In addition (shame on you Elysia), it looks like gdi+ is not part of the win32api that MinGW provides: https://encrypted.google.com/#hl=en&...w=1083&bih=812

gg

Originally Posted by Elysia

You probably need to set up an include path (dunno how to do it for C::B, though).
Also be aware that GDI+ is a bad API that you should not use outside your assignment. It is deprecated. You should use DirectX for any graphics in Windows (or OpenGL; but that probably won't work as well as DirectX for some things).

Will you PLEASE stop dumping on Windows API every chance you get?

Seriously, it doesn't make you look smart or good.

There is a ton of perfectly good code out there written entirely in Windows API and there's no reason to ditch on it the way you do. I work mostly in Windows API for my projects in C and don't have any problem with it.

Yes, there are cases where DirectX offers better facilities... and cases where it's overkill by miles... You don't need DirectX or OpenGL to draw a line on a screen or move a little bitmap around... it's about the right tool for the job... not about how much you hate Windows API.

Originally Posted by novacain

Sorry, what?

When was GDI+ ever depreciated?
Why is GDI+ not an easy and reliable API to use for 2D drawing?

Please link me to your source.

AFAIK it was GDI that was depreciated, never GDI+.

But WIN7 re-introduced support for GDI drawing under the WDDM.

GDI+ is also available for all versions of MS OS's up to and including Win7.

I find GDI to be a quick and reliable RAD drawing method, especially after the changes in 2002 to the way GDI objects are handled by default in MS OS's.

I mean, sure, GDI/GDI+ might be possible to use under XP and Vista or so.
In 7, Microsoft introduced Direct2D, and for a reason, I believe.
In 8, Metro-style will very likely have to abandon GDI+ as well (GDI is already forbidden territory).
From what I can remember, Microsoft admitted as much that DirectX is what is used to perform all graphics and that GDI is available for backwards compatibility. Especially for Metro-style, and you know that's a big thing.

Originally Posted by Codeplug

In addition (shame on you Elysia), it looks like gdi+ is not part of the win32api that MinGW provides: https://encrypted.google.com/#hl=en&...w=1083&bih=812

gg

I do believe the OP has VS10 installed (or hinted as much), so that would basically mean using the header(s) that ships with that installation.
It might, or might not work, I don't know, but one might as well try.

Originally Posted by CommonTater

Will you PLEASE stop dumping on Windows API every chance you get?

Seriously, it doesn't make you look smart or good.

There is a ton of perfectly good code out there written entirely in Windows API and there's no reason to ditch on it the way you do. I work mostly in Windows API for my projects in C and don't have any problem with it.

Yes, there are cases where DirectX offers better facilities... and cases where it's overkill by miles... You don't need DirectX or OpenGL to draw a line on a screen or move a little bitmap around... it's about the right tool for the job... not about how much you hate Windows API.

Good for you. Windows API will be less important in the future with the introduction of Metro-style apps. They can only use a subset of API for backwards compatibility. Desktop apps can still use them, but you don't think Microsoft is moving away from them... for a reason?
In this case, it's about GDI(+) which will very likely be superseded by DirectX in the future. Think Direct2D.

EDIT:
http://social.msdn.microsoft.com/For...8-fc15f8cdbdb2
GDI+ is a legacy API and slower than GDI and D2D.
GDI will no longer be supported.
Makes sense to dump it, yes? Unless you are targeting XP/Vista, but they are going away, thankfully.

Elysia, you fail to provide any reason why GDI+ is not the right tool for THIS job, nor why it is a bad API.

You keep presenting you OPINION as fact, where you ahve little to no actual commercial, real world experience.

I am annoyed you are misleading new coders who believe the lies in your sig, simple because you have a high post count.

I have coded many commercial apps and web pages using GDI over the last decades.

Please try to stick to things you ACTUALLY know, not making incorrect sweeping generalisations about things you clearly have little to no experience with.

You remind me of the people who used to bash VB6, never having coded in it. Never having found how useful VB6 was when developing with COM, DCOM+ etc

Originally Posted by Elysia

I mean, sure, GDI/GDI+ might be possible to use under XP and Vista or so.

Incorrect.

GDI+ is available for ALL MS OS's, including MS Server versions and WIN7.

What versions of MS OS's support Direct2D?

Only Win7 and Win8

Originally Posted by Elysia

In 7, Microsoft introduced Direct2D, and for a reason, I believe.

Yes, to enable hardware acceration as image sizes get larger.

I hit the limits of GDI+ when developing a C# .NET viewer for GIGAPAN images.

But how often do you need to rapidly manuipulate and display over a Gb of image data on a screen at once?

If ALL you just want to create a simple graphical representation (line drawing on a bitmap) of data you do not NEED this increase in speed and reduction in CPU use. Nor do you need to waste the development time.

What you need is a RAD method of getting this data to the screen of your app or web page.

GDI/GDI+ provides this and has lots of well developed and tested code / tutes and examples available.

Originally Posted by Elysia

In 8, Metro-style will very likely have to abandon GDI+ as well (GDI is already forbidden territory).

Your 2 original recomendations the OP use (DirectX and OpenGL) are also depreciated in WIN8 METRO apps.

However as details still seem fluid as there is still talk that GDIPlus.dll is still included in the ARM (METRO) SDKs.

Windows 8 on ARM limited to metro style apps?

Originally Posted by Elysia

GDI will no longer be supported. Makes sense to dump it, yes? Unless you are targeting XP/Vista, but they are going away, thankfully.

Or web apps using ASP.NET, XAML etc.

Or .NET apps running under any version of an MS OS.

Or any MS Server versions.

Or Win8 non METRO.

If you want to develop strictly for ARM based processors under WIN8 (ie pure METRO) you MIGHT have to move to Direct2D and abandon any backward compatibility.

Originally Posted by novacain

Elysia, you fail to provide any reason why GDI+ is not the right tool for THIS job, nor why it is a bad API.

No, I did say.
In future windows versions, we will be moving away from GDI(+). AKA, it's deprecated.

You keep presenting you OPINION as fact, where you ahve little to no actual commercial, real world experience.

Sigh... how often does THAT not happen on this board?

I am annoyed you are misleading new coders who believe the lies in your sig, simple because you have a high post count.

Lies they are not. Misleading it might be, but to call it a lie would be a lie.

Incorrect.

GDI+ is available for ALL MS OS's, including MS Server versions and WIN7.

What versions of MS OS's support Direct2D?

Only Win7 and Win8

I did not say that (or you misunderstood).
Yes, GDI(+) is available on all versions, but on Win7+, GDI(+) should be preferred. If you are targeting older versions such as XP/Vista, then you have no choice and as such GDI(+) might make a better choice (unless there is a better tool available).
Sure, you can go ahead and use GDI(+) in your app. Just remember that you might lose compatibility in the future. Isn't is better, then, to invest in tools that will work in the future more guaranteed than not?

What you need is a RAD method of getting this data to the screen of your app or web page.

GDI/GDI+ provides this and has lots of well developed and tested code / tutes and examples available.

So... D2D is not a RAD tool? Is that why you would recommend GDI(+) over it?
(Seriously, I don't know...)

Your 2 original recomendations the OP use (DirectX and OpenGL) are also depreciated in WIN8 METRO apps.

OK, I will admit I haven't entirely looked at WinRT, but the graphics subsystem is built on DX. They will just expose it in some way, I imagine.
Probably not too different from today's DX, but who knows? One thing is probably for sure, it won't be GDI(+).

Anyway, let's not argue about this.
You are the master on Win32 programming.
If you say it's a good idea, I'll believe you, and the OP shall benefit from your knowledge, as well.
Let's just say I've expressed my concerns.
You win

Trust me Elysia... the Windows API and it's various "technologies" isn't going away any time soon...

You don't really think that because Microsoft is heading in a different direction for Windows 8, we're just going to drop highly successful softwares and data systems do you?

Windows 8 would be an even bigger failure than Vista if all of a sudden hundreds of thousands of applications just stopped working... They cannot just drop the Windows API or desktop devolopment, it would be financial suicide.

Metro-apps are merely one more phase in the dumbing down of computing. In a great many situations both corporate and private, such silly --child like-- interfaces just get in the way of the real work that has to be done... writing a report, updating data bases, handling transactions, etc. Trust me you won't see the silly sliding tiles in the head office of major corporations any time soon. Heck, some of them are still running Windows 2000 on their servers because it's fast, lightweight and extremely efficient, plus the changeover cost to reload all their machines and then update all their software would kill them.

With market shares looking like this... (Yes the blue line is XP...)



The old stuff is going to be around for a good long time.

What Microsoft (and apparently a lot of younger programmers) do not seem to appreciate is that people don't want a bunch of fancy-schmancy grap going on... they want to do their work and get home to their families. Form over Substance has been a mistake made in every new version of Windows since 2000.

Personally I don't give a crap if my windows have rounded corners or shadows, I routinely defeat the animated BS, and I really don't much care what colour things are... Just do I can get what I need done in a reasonable amount of time, all the rest of it is meaningless.

Tater, Microsoft has spent a lot of time making things easier, simpler and faster to access. Metro evolved from the fact that the start menu was a pain to find things on, for example.
Also, you need to separate old versus new applications. Yes, Microsoft will not break backwards compatibility if they can. But that doesn't mean they can't or won't remove APIs, or especially likely--deprecate APIs.
If you have an old application that needs to be maintained, OF COURSE you should use legacy APIs if you can't use new ones.
But if you are creating a new application, then you should not use legacy APIs.

I also remember reading that Win7 had surpassed XP, and that in around 2 years. So in an additional 2 years, the number of XP users should dwindle more, hopefully.
And regarding corporate users... sure, they'll stick to old operating systems because it's expensive to upgrade. Yes, of course, Microsoft will make sure their applications still work.
But eventually they will upgrade too: they have to. Support for an operating system only lasts so long, and security is becoming a hotter and hotter topic these days.

Originally Posted by Elysia

I also remember reading that Win7 had surpassed XP, and that in around 2 years.

The graph is from August 2011 (sorry it's a bit blurry, the original was huge), taken from Wikipedia's user/browser stats.

The plain truth is that more than half the world still runs on what you call legacy aps and there are primarily two reasons for it:
1) As we seem to agree the cost of upgrading every 2 years is prohibitive.
2) The new stuff coming out is, despite all the eye candy, totally unimpressive to IT people.

Further; in terms of security... anybody with more than one computer who relies upon Windows firewall or defender for system security is a darned fool... Even my little $79.00 home router has a hardware firewall and DMZ isolation build in.

Originally Posted by CommonTater

The plain truth is that more than half the world still runs on what you call legacy aps and there are primarily two reasons for it:
1) As we seem to agree the cost of upgrading every 2 years is prohibitive.
2) The new stuff coming out is, despite all the eye candy, totally unimpressive to IT people.

A lot of businesses don't upgrade because it costs too much... the end.
I wonder why people are moving to Win7 if all it does is give more eye candy...

Further; in terms of security... anybody with more than one computer who relies upon Windows firewall or defender for system security is a darned fool... Even my little $79.00 home router has a hardware firewall and DMZ isolation build in.

The firewall isn't the only thing in terms of security in an operating system, you know? When companies upgrade operating system because of security, it isn't to get a better "built-in" firewall.