What to do when a function returns FALSE

[Daniel Delande]

Hello Pete,

2 questions:

1. In order to make the module I develop compatible with old versions of FSUIPC and not to waist performance with the newer versions, I have implemented the following strategy:

- call the new version of Open2(); if it returns TRUE, that is OK, the version is >= 3.40.

- if it returns FALSE, call the old version of Open2(), that should return TRUE.

I have renamed the old functions and global variables, so the 2 versions can be present in the code.

Apparently, it works fine. Is there any pitfall?

2. In some cases, I have to get several data from FSUIPC in one shot. So I first call Read() a number of times, then I call Process(). I check the value returned by every Read(). What should I do if the first Read() returns TRUE and a subsequent Read() returns FALSE? Call Process() so as to clear the buffer and discard the result? Note that my question applies to calls from a module loaded by FS and also to calls from an external application.

Daniel Delande

[Pete Dowson]

1. In order to make the module I develop compatible with old versions of FSUIPC and not to waist performance with the newer versions, I have implemented the following strategy:

- call the new version of Open2(); if it returns TRUE, that is OK, the version is >= 3.40.

- if it returns FALSE, call the old version of Open2(), that should return TRUE.

I have renamed the old functions and global variables, so the 2 versions can be present in the code.

Apparently, it works fine. Is there any pitfall?

No, that should be okay. Although really, of course, I'd prefer that you insist that folks keep their FSUIPC up to date! (Makes support much easier! :wink: ).

2. In some cases, I have to get several data from FSUIPC in one shot. So I first call Read() a number of times, then I call Process(). I check the value returned by every Read(). What should I do if the first Read() returns TRUE and a subsequent Read() returns FALSE?

You could work that out from the code, as you have looked at it in any case to do the above changes. The FSUIPC_Read and _Write calls are entirely dealt with in your program, not in FSUIPC. You'd only get a FALSE return if you hadn't got a correct Open to start with, or you run out of space in the memory you provided for the transfer (or, in the case of the external library, the maximum allowed -- around 30k I think.

Call Process() so as to clear the buffer and discard the result? Note that my question applies to calls from a module loaded by FS and also to calls from an external application.

Yes, you could do -- but the results you do get will be okay for the Reads which worked, of course. Really such errors should be found during testing, and rectified before release. Once the program is working they should not occur. I agree that the program should be bullet-proof though and the cost in extra code is minimal to leave checks in.

Regards,

Pete

[Daniel Delande]

You could work that out from the code, as you have looked at it in any case to do the above changes

Yes, I can understand I could have worked it out. However, I have not, just because there was no real need: I had not to look at what is inside the functions; I simply noticed that the global variable and function names begin with 'FSUIPC_" (they now begin with "FSUIPC_IPCACCESS_" in the old library).

I must admit that I have not tried to understand the IPC protocol and, by extension and laziness, the code of the libraries.

Thank you for answering and being patient,

Daniel Delande