Odd compile error when renaming source files from c to cpp

[darrenecm]

After a lengthy time away from C gauge dabbling I now have time to try and get my head around it all again.

At the moment I'm startiong off by simply getting a plain old static background image into my gauge and using it to test GDI+ calls in order to draw on the gauge surface.

I believe to avoid some errors when including the gdiplus.h header you have to rename your source files from .c to .cpp (for reasons that remain myserious to me).

Having renamed my source files to .cpp though I am constantly getting the following error message:

------ Build started: Project: GDIPlusTest2, Configuration: Release Win32 ------
Compiling...
GDIPlusTest2.cpp
c:\documents and settings\administrator\my documents\visual studio 2005\projects\f2004 gauges\gdiplustest2\gdiplustest2\..\..\panel-sdk\inc\fs9gauges.h(4631) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
Build log was saved at "file://c:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\F2004 GAUGES\GDIPlusTest2\GDIPlusTest2\Release\BuildLog.htm"
GDIPlusTest2 - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

The gauge code I have in place at the moment compiles fine without this error only if my source files are .c files.

Clicking on this error I'm taken to the fs9gauges.h file at the following line:

typedef (*GAUGE_KEY_EVENT_HANDLER) (ID32 event, UINT32 evdata, PVOID userdata);

The above line also concerns me because the parameter 'ID32 event' shows the variable 'event' highlighted in blue as though it's a keyword instead of the name of a variable. Is this somehow tied to the problem? I'm using VC 2005 Pro edition so maybe my code editor is highlighting 'event' as a keyword because it's a new one that's been introduced? I'm wildly guessing here though :)

Here's the code for my 'master' .cpp gauge file.

// The 'master.c' file
#include "..\..\panel-sdk\inc\fs9gauges.h"
#include "GDIPlusTest2.h"
#include <MMsystem.h>
#include <math.h>

#define GAUGE_NAME "GDIPlusTest2\0"
#define GAUGEHDR_VAR_NAME gaugehdr_GDIPlusTest2
#define GAUGE_W 100

#include "GDIPlusTest2G.cpp"

GAUGE_TABLE_BEGIN()
GAUGE_TABLE_ENTRY(&gaugehdr_GDIPlusTest2)
GAUGE_TABLE_END()

[darrenecm]

After some searching through the VC 2005 docs the basis of this error seems to indeed be exactly what the error message says, that C++ does not apply a default type when a type specifier is missing.

I've never seen a typdef syntax like...

typedef (*GAUGE_KEY_EVENT_HANDLER) (ID32 event, UINT32 evdata, PVOID userdata);

..before so it's very confusing as to what type to explicitly apply to it. Give me standard C/C++ syntax any day over all these damned FS SDK macros, they only serve to make things as clear as mud. I hope to God the guy Microsoft has hired to create the sdk for FSX knows his stuff and steers clear of imposing pseudo-language macros on us all ;)

I'd be grateful if any of you code gurus out there could offer confirmation on exactly what type would be safe to explicitly apply to this struct. If type long would be suitable I guess it would be a simple question of changing the fs9gauges.h header entry for this structure to...

typedef long (*GAUGE_KEY_EVENT_HANDLER) (ID32 event, UINT32 evdata, PVOID userdata);

However I'm no expert on the header file so I would welcome any suggestions :)

In the meantime I'll apply a long type to it and see if anything breaks :)

Grassy arse amigos.

[ddawson]

Darren,

No recollection whatsoever as to where I got this, but looking at my copy of fs9gauges.h, I see this:

//typedef (*GAUGE_KEY_EVENT_HANDLER) (ID32 event, UINT32 evdata, PVOID userdata);
typedef void FSAPI VGAUGE_KEY_EVENT_HANDLER (ID32 event, UINT32 evdata, PVOID userdata);
typedef VGAUGE_KEY_EVENT_HANDLER *GAUGE_KEY_EVENT_HANDLER;

Further, I do recall that this was an issue for me prior to the change being made...

Doug

[darrenecm]

Excellent. Thanks Doug.

It makes a little more sense but still unclear on some points. It appears to be re-hooking a structure containing a function pointer to the other structure name - VGAUGE_KEY_EVENT_HANDLER. I'd guess it's a way of interecpting the value of a standard WM_KEYDOWN message that you find under the standard Windows messaging system...again...wildly guessing there.

Does anyone know just how many versions of fs9gauges.h there are? Or is this just a one off user edit on the part of someone who obviously knows quite a lot about the quirks and errors of the original sdk header file from which fs9gauges.h was created? Strange that there's no mention of it in other posts and forums.

I'll just throw caution to the wind, change my header file to match and trust the anonymous edit :)

If anyone has any further comments on clarifying this quirky problem, I'd appreciate further education ;)

[n4gix]

Hi Darren,

I sent you a copy of my (heavily) modified fs9gauges.h file along with a "GDI+ Gauge Template" project. It should convert and load directly into your MSVC++ .NET 2005 Pro IDE.

[darrenecm]

Wild Bill to the rescue again. You sir are what is commonly called (in my neck of the Manchester-UK woods) as a star :)

I was beginning to think I'd be better off reverting back to my VC 2003 setup...espcially when more odd compiler errors such as the one below turned up:

------ Build started: Project: gdiTest2, Configuration: Debug Win32 ------
Compiling...
GDIPlusTest2.cpp
c:\documents and settings\administrator\my documents\visual studio 2005\projects\f2004 gauges\gditest2\gditest2\gdiplustest2g.cpp(46) : error C2664: 'Gdiplus::GdiplusShutdown' : cannot convert parameter 1 from 'ULONG_PTR *__w64 ' to 'ULONG_PTR'
There is no context in which this conversion is possible
Build log was saved at "file://c:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\F2004 GAUGES\gdiTest2\gdiTest2\Debug\BuildLog.htm"
gdiTest2 - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

The problem stems when trying to start up GDI+ with the following line:

Gdiplus::GdiplusStartup(&gdiPlusToken, &gdiPlusStartupInput, NULL);

I guessed it might be assuming I'm compiling to a 64-bit Windows version and therefore the conditional compilation commands in basetsd.h were defining the ULONG_PTR type as:

typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;

However, my project is definitely set up as a Win32. I also checked my compiler switches for any 64-bit code generation commands but couldn't see anything. So I don't know what's cuasing the ULONG_PTR to be type-deffed to something the GDI+ startup function doesn't like.

Why is life so complicated? Seems to me that the more complex Visual Studio becomes, the more you have to fight it to get things done the way you want :)

[darrenecm]

LOL.

After looking through your Template code Bill, I now see why I was getting the error in my post above.

I needed to redefine the ULONG_PTR as a DWORD.

The VC 2005 documentation help file listing the GDI+ SDK samples totally fail to point this out as can be seen in the sample code below...sigh ;)

#define UNICODE
#include <windows.h>
#include <gdiplus.h>
using namespace Gdiplus;

VOID OnPaint(HDC hdc)
{
Graphics graphics(hdc);
Pen pen(Color(255, 0, 0, 255));
graphics.DrawLine(&pen, 0, 0, 200, 100);
}

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, PSTR, INT iCmdShow)
{
HWND hWnd;
MSG msg;
WNDCLASS wndClass;
GdiplusStartupInput gdiplusStartupInput;
ULONG_PTR gdiplusToken;

// Initialize GDI+.
GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL);

wndClass.style = CS_HREDRAW | CS_VREDRAW;
wndClass.lpfnWndProc = WndProc;
wndClass.cbClsExtra = 0;
wndClass.cbWndExtra = 0;
wndClass.hInstance = hInstance;
wndClass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wndClass.hCursor = LoadCursor(NULL, IDC_ARROW);
wndClass.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
wndClass.lpszMenuName = NULL;
wndClass.lpszClassName = TEXT("GettingStarted");

RegisterClass(&wndClass);

hWnd = CreateWindow(
TEXT("GettingStarted"), // window class name
TEXT("Getting Started"), // window caption
WS_OVERLAPPEDWINDOW, // window style
CW_USEDEFAULT, // initial x position
CW_USEDEFAULT, // initial y position
CW_USEDEFAULT, // initial x size
CW_USEDEFAULT, // initial y size
NULL, // parent window handle
NULL, // window menu handle
hInstance, // program instance handle
NULL); // creation parameters

ShowWindow(hWnd, iCmdShow);
UpdateWindow(hWnd);

while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}

GdiplusShutdown(gdiplusToken);
return msg.wParam;
} // WinMain

LRESULT CALLBACK WndProc(HWND hWnd, UINT message,
WPARAM wParam, LPARAM lParam)
{
HDC hdc;
PAINTSTRUCT ps;

switch(message)
{
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
OnPaint(hdc);
EndPaint(hWnd, &ps);
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
} // WndProc

[n4gix]

:) Well, that won't be the last complication, but perhaps you're over the hump now...