Jump to content
The simFlight Network Forums

FPCUser with Delphi 2010


Recommended Posts

I tried to use the FPCUser.pas with Delphi 2010, so implementation is ok.

But when I try to connect to FSUIPC, "FSUIPC_open()" I get all the time "false" as result.

With Delphi 7 it works! So is there something special to keep in mind?

Sorry, I don't know Delphi at all (nor Pascal for that matter). The difference is obviously in how the two versions of Delphi are compiling or interpreting the code, because obviously the FSUIPC side of the interface is not changing. Doesn't Delphi has any debugging tools so you can find out what is wrong?

Regards

Pete

Link to comment
Share on other sites

Hello Pete, I dont, know if there is a tool to debug it.

I think the problem occurs only with the FSX.

So I will post the problem as well in a delphi forum.

Maybe there is a solution for this problem.

Thanks...

Maybe it helps: this is the error code which returns: "IPC request contains bad data"

Link to comment
Share on other sites

Maybe it helps: this is the error code which returns: "IPC request contains bad data"

It means the part of the code in your program cannot decode the data it read. Probably you have the structural byte alignment set wrong. But you need to debug our program. I cannot stress that enough. You cannot expect to develop programs which work first time. You must use the debugging tools your compiling system is sure to have.

If you do not understand Delphi, why choose it? Why not try Visual Basic, for example?

Pete

Link to comment
Share on other sites

Oh Pete,

I use Delphi since 7 Years, I know how to use it, and developed a lot of tools, also using the FSUIPC.

So now there is the problem with this code:

var FSUIPC_connect : boolean;
    error_code : dword;
begin
  if FSUIPC_Open(SIM_ANY,error_code) then
    showmessage('FSUIPC connected')
      else showmessage(ResultText[error_code]);

  Form1.Caption := 'Voice ATIS 2 BETA ' + ResultText[error_code];

So this doesn´t work:

FSUIPC_Open(SIM_ANY,error_code)

with Delphi 7 it works, with delphi 2010 not...

So I do not know how to search for Problem!

Link to comment
Share on other sites

So this doesn´t work:

FSUIPC_Open(SIM_ANY,error_code)

with Delphi 7 it works, with delphi 2010 not...

So I do not know how to search for Problem!

But that procedure is IN YOUR PROGRAM. It isn't part of FSUIPC! FSUIPC runs inside FS, and there will be, somewhere in that procedure, a call to "SendMessageTimeout", which is the Windows API call which communicates to FSUIPC. That's it. The rest is yours.

Your problem will be in that specific procedure, which presumably is compiled by your compiler? You need to find out why it doesn't work with your later software. I can't do that. I don't know Delphi and i don't have either of the compilers.

As I keep saying. Since the code is ALL in your program, you can debug it!

Pete

Link to comment
Share on other sites

  • 2 months later...

Hello,

I've just switched to the latest Delphi XE IDE, so I've been confronted to that issue as well.

Delphi versions prior to delphi 2010 are not unicode compliant. So, in order to make the FPCuser.pas compatible, you simply have to replace all "Pchar" functions to "PwideChar", and all "AnsiString" to "Widestring", it takes 2 minutes...

Pete, if you're interested, I can mail you the compatible version, but I'm not too sure about distribution of the modified file?

Jean Luc

Link to comment
Share on other sites

I've just switched to the latest Delphi XE IDE, so I've been confronted to that issue as well.

Delphi versions prior to delphi 2010 are not unicode compliant. So, in order to make the FPCuser.pas compatible, you simply have to replace all "Pchar" functions to "PwideChar", and all "AnsiString" to "Widestring", it takes 2 minutes...

Pete, if you're interested, I can mail you the compatible version, but I'm not too sure about distribution of the modified file?

Just missed a re-issue of everything, but if you'd be so kind as to put it into a thread up on "User Contributions" subforum for now, and it'll make the next update.

One thing I don't really understand though. All of FS's strings accessible and usable through the FSUIPC interface, and all of the paths and other string fields, are normal single byte ASCII. so how does that work?

Regards

Pete

Link to comment
Share on other sites

Ok just posted it in user contribution forum.

One thing I don't really understand though. All of FS's strings accessible and usable through the FSUIPC interface, and all of the paths and other string fields, are normal single byte ASCII. so how does that work?

I'm not too sure as those new types (widestring, widechar) are still a bit new to me, but the SendMessageTimeout call in FSUIPC_process function returned a dwerror of 0, when all parameters "looked OK" (meaning the handle to mapped file, message id, atom, etc, were non null). My guess, FSUIPC didn't like the atom naming convention. Since the strings convention changed, the windows API calls from Delphi changed too (or the compiler do not adapt the convention any more?)...

Anyway, now it should work!

Jean Luc

Link to comment
Share on other sites

Ok just posted it in user contribution forum.

Thanks!

I'm not too sure as those new types (widestring, widechar) are still a bit new to me, but the SendMessageTimeout call in FSUIPC_process function returned a dwerror of 0, when all parameters "looked OK" (meaning the handle to mapped file, message id, atom, etc, were non null). My guess, FSUIPC didn't like the atom naming convention.

If the atom is created with a Wide character string it would be using the Wide character version of the specific atom creating API. Pretty much all Windows API functions which take character strings have both ASCII ("A") and wide ("W") versions. The compiler chooses the correct one according to your default character choice. FSUIPC and FS use ASCII, but I think an atom correctly named in either would be the same atom unless wide characters which weren't simply wide ASCII (i.e top 8 bits = 0) were being used in the name.

Since the strings convention changed, the windows API calls from Delphi changed too (or the compiler do not adapt the convention any more?)...

I don't know about Delphi, but with C/C++ you can choose whether to use ASCII or wide characters (Unicode). FSUIPC uses ASCII for compatibility with FS.

Anyway, now it should work!

Good. Thank again!

Pete

Link to comment
Share on other sites

Ok just browsed the two help files:

Old version (P)char was equivalent to (P)AnsiChar, whereas new (P)char is equivalent to (P)Widechar.

The szname variable was previously declared as AnsiString, so the old code in the new compiler probably lost a byte by transtyping szname to a widechar? (and now I guess that only this szname declaration change was required, but for code cleanliness sake, using the full Pwidechar name is better I suppose)

Thanks for your interest,

JL

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.