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

This is a discussion on #include <gdiPlus.h> problem with Code::Blocks within the Windows Programming forums, part of the Platform Specific Boards category; Hello all, I need to do some GDI+ stuff for Uni and I've decided to use the Code::Blocks IDE. When ...

  1. #1
    Registered User
    Join Date
    Oct 2011
    Location
    Derby, UK
    Posts
    8

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

    Hello all,

    I need to do some GDI+ stuff for Uni and I've decided to use the Code::Blocks IDE. When I #include the gdiPlus.h, I get the following error report:

    C:\C_Tutorials\SimpleWindow\main.cpp:7:21: error: gdiPlus.h: No such file or directory Process terminated with status 1 (0 minutes, 0 seconds)
    1 errors, 0 warnings

    I've done everything correct according to the MSDN website and my notes from Uni... but Code::Blocks doesn't seem to like it whilst Visual Studio 2010 does. Is this a problem with Code::Blocks?

    Many thanks!

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    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).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Registered User
    Join Date
    Oct 2011
    Location
    Derby, UK
    Posts
    8
    Thanks, I'll have a look through the dox.

    S.

  4. #4
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,856
    Quote Originally Posted by Elysia View Post
    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.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  5. #5
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    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

  6. #6
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    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.
    Last edited by CommonTater; 10-20-2011 at 11:38 PM.

  7. #7
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by New_To_C++ View Post
    Hello all,

    I need to do some GDI+ stuff for Uni and I've decided to use the Code::Blocks IDE. When I #include the gdiPlus.h, I get the following error report:

    C:\C_Tutorials\SimpleWindow\main.cpp:7:21: error: gdiPlus.h: No such file or directory Process terminated with status 1 (0 minutes, 0 seconds)
    1 errors, 0 warnings

    I've done everything correct according to the MSDN website and my notes from Uni... but Code::Blocks doesn't seem to like it whilst Visual Studio 2010 does. Is this a problem with Code::Blocks?

    Many thanks!
    It's probably a problem with the libraries supplied with MinGW... which is the compiler used by code:blocks.

    If you have VS2010... use that.

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by novacain View Post
    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.

    Quote Originally Posted by Codeplug View Post
    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.

    Quote Originally Posted by CommonTater View Post
    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.
    Last edited by Elysia; 10-21-2011 at 02:57 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Registered User
    Join Date
    Oct 2011
    Location
    Derby, UK
    Posts
    8
    Quote Originally Posted by CommonTater View Post
    It's probably a problem with the libraries supplied with MinGW... which is the compiler used by code:blocks.

    If you have VS2010... use that.
    I do have Visual Studio 2010 Ultimate, but like a lot of MicroSoft products, I find that it gets in the way of what I'm trying to do, whereas C::B seemed easier to get started. But yes, I'll have to use VS and just work around any issues that arise.

    Many thanks,

    S.

  10. #10
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,856
    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

    Quote Originally Posted by Elysia View Post
    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

    Quote Originally Posted by Elysia View Post
    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.

    Quote Originally Posted by Elysia View Post
    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?


    Quote Originally Posted by Elysia View Post
    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.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  11. #11
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by novacain View Post
    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
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #12
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    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...)

    Name:  os.png
Views: 1061
Size:  7.6 KB

    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.
    Last edited by CommonTater; 10-22-2011 at 04:02 AM. Reason: grabbed the wrong image

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    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.
    Last edited by CommonTater; 10-22-2011 at 04:29 AM.

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by CommonTater View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Code::Blocks run problem
    By Coga1900 in forum C++ Programming
    Replies: 34
    Last Post: 09-20-2011, 03:49 AM
  2. Replies: 17
    Last Post: 07-08-2011, 07:11 AM
  3. compilation problem........code::blocks...
    By Souradeep in forum C++ Programming
    Replies: 3
    Last Post: 12-20-2010, 02:04 AM
  4. Code Blocks compiling problem
    By Lehsyrus in forum Tech Board
    Replies: 2
    Last Post: 07-13-2010, 02:28 PM
  5. Code::Blocks problem
    By eaane74 in forum C++ Programming
    Replies: 6
    Last Post: 05-24-2007, 07:24 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21