Visual C++ .Net for Gauge Programming

[n4gix 4,947]

Is anyone using MS Visual C++ .Net for gauge programming?I'd like some assistance in setting up a proper workspace environment, that will make the job easier and more structured.Has anyone created a 'template' for a Project that could be used?Details, details... :)

[Guest HartmannH]

I use it. No problems whatsoever. Here's a short description. However I use a German version of VS.NET so some things may be named a bit different than I translate them.1) Add the path to your gauges.h (standard version - not an edited one) to the VC include paths (Extra->Options->Projects->VC-Directories)2) If you want to use DirectX things, also add the include and library path of the DX SDK. Always add those as the first entries!3) Create an empty Win32 DLL project (First select 'Win32 project' and in the next window select 'DLL' and 'Empty Project'). 4) To use C++ instead of C, just add a nameofyourgaugefile.DEF file to your project. It should look like this:LIBRARY nameofyourgaugefile.GAUEXPORTS Linkage ImportTableThat's it. Once you've done that, you can use VS.NET for development. If you still need a template project, just drop me a line.

[Guest zip]

Someone sent me an e-mail a few days ago about the config but somehow I can't seem to locate that message (if you were the sender, my apologies and please send me the e-mail again).I use Arne's modified gauge header that Dai Griffith put out, and .NET 2003.In addition to the above:Add MSVCRT.LIB and GDIPLUS.LIB in your linker library if you use standard library calls and GDI+. Check that MFC and ATL are turned off (chaos ensues with the header files if you do). Block every header file with an #ifdef / #endif block to avoid multiple definitions and duplicate linker entries.Debugging from the environment:The neat thing about VS Studio is its excellent debugger and conditional breakpoints.Things to know:- only debug with FS9 in windowed mode - DirectX tends to crash if you switch from windowed to full screen and back in debugging mode, and you will get stuck at breakpoints with no ability to switch back.- use a separate config for debugging (debug/release) and include MSVCRTD.LIB (add the "D" at the end) which gives you access to the _RPT0,_RPT1, etc functions for output to the console. These are macros that evaluate to nothing in the release version of the runtime so you don't have to remove them from your source.- turn off optimizations in the compiler page to avoid the odd breakpoint/execution path.- start a debugging session by outputing the gauge file directly in the FS9 gauges folder, and tell the debugger to start FS9.EXE as the start executable. You must start FS9 from the debugger for this to work.- Breakpoints will show up as a red dot with a question mark in the margin until the gauge is loaded. If the question mark doesn't go away, that usually means that the debugger loaded a different file (this can be due to a number of things but the chief reason is your output file isn't placed in the gauges folder and never loaded by FS9).- the debugger can have problems recognizing the type of variables if you declare them as FLOAT64 instead of double for example. That's because the pre-processor hides the type and it may not be entered correctly in the debugger's map file. That's a hit or miss thing for me. I end up using the _RPT statement quite a bit to work around this.- just know that the heavy use of macros can sometimes throw breakpoints for a spin, and I would avoid using breakpoints on lines that have pre-processor macros.Hope this helps,

[Guest HartmannH]

>- the debugger can have problems recognizing the type of>variables if you declare them as FLOAT64 instead of double for>example. That's because the pre-processor hides the type and>it may not be entered correctly in the debugger's map file. >That's a hit or miss thing for me. I end up using the _RPT>statement quite a bit to work around this.>>- just know that the heavy use of macros can sometimes throw>breakpoints for a spin, and I would avoid using breakpoints on>lines that have pre-processor macros.Hmm. I never ran into those two problems here.

[Guest zip]

Hans, good for you. These two items are documented on the MS knowledge base but I suppose do not affect everyone the same way.

[n4gix 4,947]

WHIZZ................!!!!!That "whizzing sound" you just heard were the informational bullets screaming way over my head... :)Fellows, I am nearly a virgin with respect to any of this, so please be gentle.Fortunately, thanks to both your replies, a "tutorial" that was sent to me by another "Paduan Learner," and some plain old fashioned dumb luck, I have managed to get the environment set up for quasi-efficent gauge production. :)What WOULD be really cool, would be a "Template" (.js file?) that would automagically set all the necessary parameters for a new gauge project... Is there even such a creature?

[n4gix 4,947]

>1) Add the path to your gauges.h (standard version - not an>edited one) to the VC include paths>(Extra->Options->Projects->VC-Directories)No such beastie in my VC++ .Net IDE...I did however, place all FS specific files, such as fs9gauges.h, gpsinfo.h, etc. in a separate folder in my Gauge build environment, so I can explicitly list the path in the .cpp file:include "../inc/fs9gauges.h"etc.>If you still need a template project, just drop me a line.Please, any help would be gratefully received!n4gix@comcast.net

[Guest HC001ST - Stick]

> 2) If you want to use DirectX things, also add the include and> library path of the DX SDK. Always add those as the first entries!How do you do this? Is this the MS SDK/include and MS SDK/lib directories?> Add MSVCRT.LIB and GDIPLUS.LIB in your linker library if you> use standard library calls and GDI+.Not sure how to do this either in the new .NET. Any hints?>Check that MFC and ATL are turned off (chaos ensues with the>header files if you do). Also not sure I'm doing this right. ATL seems to have an "off" option, but not MFC.Thanks.

[Guest HartmannH]

Sorry guys. I have a German version of VS.NET and that uses a lot of localized stuff.I'll give it another try.1) Extras->Options->Projects->VC++-Directories"Extras" is the second last menu. In my version between "Debug" and "Window".2) DirectXYes, that's the DXSDKinclude and DXSDKlib directories3) MSVCRT.LIB/GDIPLUS.LIBOpen the project explorer (should be a docked window on the right side of the screen), right-click the name of your project (that's the bold one) in the treeview and select "Properties". Now select "Linker" and then "Input" in the dialog window.4) MFCAs long as you start from an empty DLL project, you don't need to worry about that.@Bill: I will send you that sample project later today. Please send me a PN with your email. Thanks a lot :-)

[Guest HC001ST - Stick]

The "Extras" is called "Tools" menu on the US version of VC++ .NET 2003.

[Guest HC001ST - Stick]

>1) Extras->Options->Projects->VC++-Directories>"Extras" is the second last menu. In my version between>"Debug" and "Window".Ok, this is called "TOOLS" in the US version. However, no need to add this directory except to make it easier to find the file. We both are putting the gauges.h and related headers in an include folder so that our includes look like this:#include "../inc/fs9gauge.h"which works fine. Nice to know that we can eliminate the "../inc" part by doing this though.>2) DirectX>Yes, that's the DXSDKinclude and DXSDKlib directoriesOk, added these directories in the: "TOOLS{Extras}/Options/Projects/VC++ Directories".>3) MSVCRT.LIB/GDIPLUS.LIB>Open the project explorer (should be a docked window on the>right side of the screen), right-click the name of your>project (that's the bold one) in the treeview and select>"Properties". Now select "Linker" and then "Input" in the>dialog window.Ok, put both of these files in there.>4) MFC>As long as you start from an empty DLL project, you don't need>to worry about that.Right, always start with a "blank" dll project, and not an MFC dll.Now, when I attempt to compile a test_gdiplus gauge I get:Linking...testvector.obj : error LNK2005: _get_listelement_pointer@8 already defined in testgdiplus.objtestvector.obj : error LNK2005: _add_imagedata_to_listelement@12 already defined in testgdiplus.objtestvector.obj : error LNK2005: _remove_imagedata_from_listelement@12 already defined in testgdiplus.objtestvector.obj : warning LNK4006: _get_listelement_pointer@8 already defined in testgdiplus.obj; second definition ignoredtestvector.obj : warning LNK4006: _add_imagedata_to_listelement@12 already defined in testgdiplus.obj; second definition ignoredtestvector.obj : warning LNK4006: _remove_imagedata_from_listelement@12 already defined in testgdiplus.obj; second definition ignored Creating library Release/gdiplus.lib and object Release/gdiplus.expMSVCRT.LIB(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function _WinMainCRTStartupRelease/gdiplus.exe : fatal error LNK1120: 1 unresolved externalsIdeas?

[Guest bartels]

Use my fs9gauges.h or change the #include to "gauges.h" in testgdiplus.cpp. Or start without the gdiplus example. Also you set up an EXE project, try an empty DLL project.Arne Bartels

[n4gix 4,947]

>Use my fs9gauges.h or change the #include to "gauges.h" in>testgdiplus.cpp. Or start without the gdiplus example. Also>you set up an EXE project, try an empty DLL project.>Arne BartelsHi Arne!We are both using the fs9gauges.h that was included in Dai's latest tutorial.I am not getting the same errors, but am getting these linker errors:Linking...testgdiplus.obj : error LNK2001: unresolved external symbol _ImportTabletestgdiplus.obj : error LNK2001: unresolved external symbol _Linkagetestgdiplus.obj : error LNK2019: unresolved external symbol _GdiplusShutdown@4 referenced in function "void __stdcall gauge_cb(struct GAUGEHDR *,int,unsigned int)" (?gauge_cb@@YGXPAUGAUGEHDR@@HI@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdiplusStartup@12 referenced in function "void __stdcall gauge_cb(struct GAUGEHDR *,int,unsigned int)" (?gauge_cb@@YGXPAUGAUGEHDR@@HI@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipCreateSolidFill@8 referenced in function "public: __thiscall Gdiplus::SolidBrush::SolidBrush(class Gdiplus::Color const &)" (??0SolidBrush@Gdiplus@@QAE@ABVColor@1@@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipDeleteBrush@4 referenced in function "public: virtual __thiscall Gdiplus::Brush::~Brush(void)" (??1Brush@Gdiplus@@UAE@XZ)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipCloneBrush@8 referenced in function "public: virtual class Gdiplus::Brush * __thiscall Gdiplus::Brush::Clone(void)const " (?Clone@Brush@Gdiplus@@UBEPAV12@XZ)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipFree@4 referenced in function "public: static void __cdecl Gdiplus::GdiplusBase::operator delete(void *)" (??3GdiplusBase@Gdiplus@@SAXPAX@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipAlloc@4 referenced in function "public: static void * __cdecl Gdiplus::GdiplusBase::operator new(unsigned int)" (??2GdiplusBase@Gdiplus@@SAPAXI@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipCreatePen1@16 referenced in function "public: __thiscall Gdiplus::Pen::Pen(class Gdiplus::Color const &,float)" (??0Pen@Gdiplus@@QAE@ABVColor@1@M@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipDeletePen@4 referenced in function "public: __thiscall Gdiplus::Pen::~Pen(void)" (??1Pen@Gdiplus@@QAE@XZ)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipCreateFromHDC@8 referenced in function "public: __thiscall Gdiplus::Graphics::Graphics(struct HDC__ *)" (??0Graphics@Gdiplus@@QAE@PAUHDC__@@@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipDeleteGraphics@4 referenced in function "public: __thiscall Gdiplus::Graphics::~Graphics(void)" (??1Graphics@Gdiplus@@QAE@XZ)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipSetSmoothingMode@8 referenced in function "public: enum Gdiplus::Status __thiscall Gdiplus::Graphics::SetSmoothingMode(enum Gdiplus::SmoothingMode)" (?SetSmoothingMode@Graphics@Gdiplus@@QAE?AW4Status@2@W4SmoothingMode@2@@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipDrawLine@24 referenced in function "public: enum Gdiplus::Status __thiscall Gdiplus::Graphics::DrawLine(class Gdiplus::Pen const *,float,float,float,float)" (?DrawLine@Graphics@Gdiplus@@QAE?AW4Status@2@PBVPen@2@MMMM@Z)testgdiplus.obj : error LNK2019: unresolved external symbol _GdipFillRectangleI@24 referenced in function "public: enum Gdiplus::Status __thiscall Gdiplus::Graphics::FillRectangle(class Gdiplus::Brush const *,int,int,int,int)" (?FillRectangle@Graphics@Gdiplus@@QAE?AW4Status@2@PBVBrush@2@HHHH@Z)Release/TestGDI.GAU : fatal error LNK1120: 16 unresolved externals

[Guest HartmannH]

Bill, your error messages look like a missing gdiplus.lib in the linker input line. Stick, it looks like you added some kind of .c or .cpp file twice. At least that could be the reason for those messages.

[Guest zip]

I think everyone who's written a gauge goes through linker errors due to duplicate object definitions - because every file that has an include file ends up with its own definitions, thanks, in part, to the preprocessor (and why I love the fact there is no pre-processor in C#).Solution: Enclose all header files in exclusion blocks as follows:#ifndef __MYGAUGEHEADERFILE__#define __MYGAUGEHEADERFILE__// code goes here#include // can insert files here too for safety#endifAnd I do mean ALL include files including gauges.h. You don't have to worry about the MS provided header files, they already do this.Also, the order of inclusion (processing) has a lot to do with this problem.And for the objects not being found, make sure that you include the proper LIB files in the linker library tab, and that the libraries are correct (in case there is a debug version for example).