Reading an Ini File in C (MinGW)... doesn't appear to work in VS 2005

[byork 2,259]

If you want to read an INI file, here's how.Note: This works for me using the MinGw © compiler.The same code when compiled through VS 2005 C++ is another story (it'll compile, but I'll get warnings and it'll return as a string 'data not found' when I run the gauge in FS9/FSX as per the code). Why? Dunno, still looking into it. // Read INI File Code in a C gauge. Display pilot's name as a string.char buffer1[100];char FILEPATH[300];{ GetCurrentDirectory(300, FILEPATH);strcat(FILEPATH,"FS2CrewStart CenterA320F.ini"); // Path to INI fileGetPrivateProfileString("FS2Crew Data","PILOT","Data not found",&buffer1,100,FILEPATH); }The INI file (named A320F.ini) that the code above would read, for example, would look like this:-FS2Crew Data- // Use squarebrackets here..Avsim forum formatting!PILOT=Captain XIn your gauge, you could now display "Captain X" as a string.sprintf(pelement->string,"%s",buffer1);-Bryan

[Guest Patrick_Waugh]

Much better to build a class that will read (and write) whatever you want to any .ini, that way you don't have to re-invent the wheel each time.Also, you should look up the warnings on MSDN2 so that you can learn the new functions to use to both avoid the warnings, and to discover the more secure versions that have replaced them.

[mgh 89]

The original poster specifically refers to the C language. Classes don't exist in C.EDIT"&buffer" should surely be replaced by "buffer"? The name of an array is a pointer to the first item in the array and the relevant argument in GetPrivateProfileString is:LPTSTR lpReturnedString, // points to destination buffer

[mgh 89]

As an off-topic follow-up, GetPrivateProfileString shows a subtle trap for the programmer on changing operating systems.http://msdn2.microsoft.com/en-us/library/ms724353.aspxIf the key can't be found then the DefaultString is copied to the ReturnedString buffer and any trailing blanks removed.In Windows Me/98/95 the trailing blanks are also removed from the DefaultString (even though it's declared as a constant parameter!) This does't happen with other operating systems - such as XP and Vista.According, a programmer who tested if the key was found by comparing the ReturnedString with the DefaultString would get different results if DefaultString contained trailing blanks and the key wasn't found. The ReturnedString would equal the DefaultString - ie key not found - using Me/98/95 but it wouldn't using XP/Vista!I wonder what other similar traps there are on changing from XP to Vista?

[Guest Patrick_Waugh]

As I have helped him in the past, I know he can compile in C++ should he desire, despite the what you have assumed from his post.

[Guest Patrick_Waugh]

If you are still developing for Win98 or ME, you need more than programming help. :D

[byork 2,259]

For those following this thread, I resolved the issue.Stupidest thing, in VS 2005 I had the Character Set in the Properties set to Unicode instead of Multi Byte.So now you know where to look if you run into the same thing :-)Cheers,Bryan

[mgh 89]

1 - I assumed nothing. The original poster specifically refered to using the MinGw © compiler for his code. Anyway, why bother with a creating an inappropriate class in C++? The original poster's code is tight and efficient.2 - Do try to understand posts before rushing to reply. I was pointing out that code correctly written for Windows Me/98/95 could give an error when run under later operating systems and speculated if there were any similar changes between XP and Vista. Anyway, my understanding is that FS9 contains legacy code which may have been written pre-XP.