March 15, 200620 yr Moderator I have successfully managed fetching the ATC ID in a C++ gauge, but am having a spot of difficulty with ATC Flight_Number, which is listed in the aircraft.cfg file as:atc_id=N515CSatc_flight_number=2284First, I set up the PCSTRINZ declaration -PCSTRINGZ atc_flight_number;Next, I fetch the string variable in PRE_UPDATE section -case PANEL_SERVICE_PRE_UPDATE: /* Fetch Variables */ execute_calculator_code("(A:ATC FLIGHT_NUMBER, string)",NULL,NULL,&atc_flight_number);break;Then in the PRE_DRAW routine, I print the variable -WCHAR ATC_FlightNum_wch[8] = L""; //forum code converted square bracket to angle bracket!swprintf(ATC_FlightNum_wch, L"%s",atc_flight_number);RectF rectFfltid_num(100*dx, 129*dy, 100*dx, 22*dy);stringFormat.SetAlignment(StringAlignmentNear);graphics.DrawString(ATC_FlightNum_wch,-1,&Arial20,rectFfltid_num, &stringFormat, &greenBrush);However, even though I don't spot anything obviously wrong, I get bupkiss (nothing) in the sim...Anyone with an idea what might be wrong? http://forums.avsim.net/user_files/144999.jpg Fr. Bill AOPA Member: 07141481 AARP Member: 3209010556 Avsim Board of Directors | Avsim Forums Moderator
March 15, 200620 yr Bill,I'm wondering if the execute_calculator_code function is returning the value '2284' as an integer, rather than as a string. I wouldn't like to think so, but given that you're not getting a string returned, it might be worth investigating.Doug
March 15, 200620 yr Author Moderator >Bill,>>I'm wondering if the execute_calculator_code function is>returning the value '2284' as an integer, rather than as a>string. I wouldn't like to think so, but given that you're>not getting a string returned, it might be worth>investigating.>>Doug>Parameters.doc in the SDK lists all of the ATC_xxx variables as "String data"...I'm 99.9% sure the problem is in the swprintf routine, but I'll be darned if I can figure out what!In the N-Registration gauge, I am using the MAKE_STRING macro instead of GDI+ (which would be overkill for this simple gauge!):{sprintf(pelement->string,"%s", n_number );This works just fine for n_number, but I just tested with atc_flight_number and got a "0." for the return... ODD!OK, I've now tested all of these:atc_type=Cessna..................works fine!atc_model=C750...................works fine!atc_airline=Netjets..............doesn't work; returns "NULL"atc_id=N515CS....................works fine!atc_flight_number=2284...........doesn't work; returns "0."What a GOOF! MS made a mistake! The correct parameter name is "ATC FLIGHT NUMBER" not "ATC FLIGHT_NUMBER" as listed in the SDK... TWO HOURS WASTED chasing a stupid error in the SDK! Fr. Bill AOPA Member: 07141481 AARP Member: 3209010556 Avsim Board of Directors | Avsim Forums Moderator
March 15, 200620 yr Bill,if you want to swprintf a normal char* into a WCHAR* or vice versa, you have to use "%S" instead of "%s". Otherwise it won't work.Hope that helps.
March 15, 200620 yr Author Moderator >Bill,>>if you want to swprintf a normal char* into a WCHAR* or vice>versa, you have to use "%S" instead of "%s". Otherwise it>won't work.>>Hope that helps.Odd, since this works:sprintf(pelement->string,"%s", n_number );but this does not work:WCHAR fltid_wch[10] = L"";swprintf (fltid_wch, L"%s",atc_flight_number);Changing to this:WCHAR fltid_wch[10] = L"";swprintf (fltid_wch, L"%S",atc_flight_number);I get a run-time error about the stack around fltid_wch being corrupted...Increasing the size of the WCHAR to:WCHAR fltid_wch[80] = L"";swprintf (fltid_wch, L"%S",atc_flight_number);I eliminated the error, but got "garbage" displayed...Obviously, my pointer isn't pointing right... ;)I've already verifed that the XML data fetching is working just fine, as long as the variable NAME is properly formed... Fr. Bill AOPA Member: 07141481 AARP Member: 3209010556 Avsim Board of Directors | Avsim Forums Moderator
March 15, 200620 yr Like Hans said, the problem is with the wide char.>Odd, since this works:>sprintf(pelement->string,"%s", n_number );Because pelement->string is not a wide char, and you're not using swprintf like he said.Either do what he suggested or use MultiByteToWideChar().Be sure to read up on exactly what a wide char is, and it'll make sense why you get junk. ;) Matt KaprockiFor fastest support, please submit a ticket at http://support.precisionmanuals.com
March 15, 200620 yr Author Moderator >Like Hans said, the problem is with the wide char.>>>Odd, since this works:>>sprintf(pelement->string,"%s", n_number );>>Because pelement->string is not a wide char, and you're not>using swprintf like he said.>>Either do what he suggested or use MultiByteToWideChar().>>Be sure to read up on exactly what a wide char is, and it'll>make sense why you get junk. ;) Matt, I did do precisely what Hans suggested, and got an error about ATC_FlightNum-wch being corrupted around the stack...WCHAR ATC_FlightNum_wch[10] = L"";swprintf(ATC_FlightNum_wch,L"%S", atc_flight_number);Increasing the buffer size to [20] produced garbage... Fr. Bill AOPA Member: 07141481 AARP Member: 3209010556 Avsim Board of Directors | Avsim Forums Moderator
March 16, 200620 yr Author Moderator Just as a followup, there were several issues at work:1) The XML variable is "A:ATC FLIGHT NUMBER,string", not "ATC FLIGHT_NUMBER,string" (The MS SDK is wrong!)2) As Hans (and Matt) pointed out, it is necessary to use L"%S" instead of L"%s" in the swprintf statement.3) More to the point though, it is a matter of the PCSTRINGZ myPcStringZ; declaration!It must be within the scope of the callback, or else the pointer is lost during the next gauge cycle......PCSTRINGZ is a char *, so therefore passing the address-of-an-address (in other words, &myPcStringZ) is passing an address to an address)...This works when in the _PRE_DRAW section:PCSTRINGZ atc_flight_number; WCHAR ATC_FlightNum_wch[10] = L""; execute_calculator_code("(A:atc flight number,string)",NULL,NULL,&atc_flight_number); swprintf(ATC_FlightNum_wch,L"%S", atc_flight_number); Fr. Bill AOPA Member: 07141481 AARP Member: 3209010556 Avsim Board of Directors | Avsim Forums Moderator
Create an account or sign in to comment