FPCUser with Delphi 2010

[SimStar001]

Hello Pete,

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?

Best Regards!

Marco

[Pete Dowson]

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

[SimStar001]

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...

[Pete Dowson]

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

How are you developing software in Delphi if you don't know it and don't even know if you can debug your code? That doesn't make sense to me. Shouldn't you find a language you can debug?

Regards

Pete

[SimStar001]

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"

[Pete Dowson]

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

[SimStar001]

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!

[Pete Dowson]

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

[jeehell]

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

[Pete Dowson]

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

[jeehell]

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

[Pete Dowson]

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

[jeehell]

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