FSUIPC read error 'Call cannot execute, link not Open'

[KWB]

Question: What is the scope of an FSUIPC_Open?
Hint: Using the C version of FSUIPC SDK with FSX:  FSUIPC 4.9.7.3 (FSX) 32 bit, my full code is attached as file.

I have a small class wrapping my FSUIPC functionality. The FSUIPC_Open itself works (returns true, DWORD result is 0)
I can also FSUIPC_READ in the same function, so far so good.

bool CFsuipc::connect(bool force) { .... DWORD result; ... if (FSUIPC_Open(SIM_ANY, &result)) ...

Now in another function (read) I rely on that opened FSUIPC connection. Still the same object in memory.

bool CFsuipc::read(CSimulatedAircraft &aircraft, bool cockpit, bool situation, bool aircraftParts) {  if (  FSUIPC_Read(0x0238, 3, localFsTimeRaw, &dwResult) &&

Now the read fails with "FSUIPC read error 'Call cannot execute, link not Open'` So somehow my open connection got lost. I can say for sure, the object is still the same. So where is the  info of the open connection stored?

Of course I could always open in the same step as I read, but I wonder why the state of the connection does not persist?

fsuipcimpl.cpp

[Pete Dowson]

7 hours ago, KWB said:

Now the read fails with "FSUIPC read error 'Call cannot execute, link not Open'` So somehow my open connection got lost. I can say for sure, the object is still the same. So where is the  info of the open connection stored?

I assume you are linking with the supplied static LIB?  The source for the library is included in the package, because most folks prefer to build-in the source itself as part of their program -- makes it easier to debug and therefore see what is going on. In the source you will see it is all done in local storage in the library., thus:

/******************************************************************************
            START of FSUIPC_User
******************************************************************************/

static HWND    m_hWnd  = 0;     // FS6 window handle
static UINT    m_msg   = 0;     // id of registered window message
static ATOM    m_atom  = 0;     // global atom containing name of file-mapping object
static HANDLE  m_hMap  = 0;     // handle of file-mapping object
static BYTE*   m_pView = 0;     // pointer to view of file-mapping object
static BYTE*   m_pNext = 0;     // ...

Note that the FSUIPC_Read action merely transfers information already in the shared menory. It is the FSUIPC_Peocess call that interacts with FSUIPC, sending the accumulated writes and reads. Which makes this line in your code look rather odd:

 if (FSUIPC_Read(0x0238, 3, localFsTimeRaw, &dwResult) && FSUIPC_Process(&dwResult))

and this pair:

FSUIPC_Read(0xC824, sizeof(timeStamp), &timeStamp, &dwResult);
FSUIPC_Process(&dwResult);

Why are you doing the read/write interaction with FSUIPC after you do the reads?

Anyway, to help you debug the problem, the error you are getting ("NOTOPEN") is returned when you try to do a Process, Read or Write when that m_pView is zero. It is that which points to the shared memory, and should remain non-zero (it is an address in memory) from the time you Open till the time you Close. You will see from the source of FSUIPC_User.cpp that those two places are the only times it is being set, so either your code is Closing the link somewhere, or it is being overwritten somehow.

Pete

 

[KWB]

First of all thanks for the hints.

Just to make sure, for my test I use a connection via "WideFS Client", for the code I use the SDK from here: http://www.schiratti.com/dowson.html 
The info is just to avoid that I use some wrong version or code base

Here is where it fails in read, I have just placed a single line for test purposes in my read function. I open in my object's connect function, then I call my read function:
 

FSUIPC_Read(0x0238, 3, localFsTimeRaw, &dwResult); ==> calls

if (!m_pView)
{    *pdwResult = FSUIPC_ERR_NOTOPEN; <-- returns this value
       return FALSE;
}

Now I did a second test and try to open just before, then failing with FSUIPC_ERR_MAP, so this means m_pView is 0, but the connection still exists. No idea how I can get into that status. 
 

FSUIPC_Open(SIM_ANY, &dwResult); <== fails with ERR_MAP
FSUIPC_Read(0x0238, 3, localFsTimeRaw, &dwResult);

if ((m_hMap == 0) || (GetLastError() == ERROR_ALREADY_EXISTS))
    {    *pdwResult = FSUIPC_ERR_MAP;
        FSUIPC_Close();

3rd version, I just close before I reopen and read. Everything works, even with my 

FSUIPC_Close();
FSUIPC_Open(SIM_ANY, &dwResult);
FSUIPC_Read(0x0238, 3, localFsTimeRaw, &dwResult);

Now my naive conclusion, my connection seems to get broken somewhere. If it was closed somewhere, example 2 would work. So somehow m_piew is 0, but still something is open. I am using an "all compiled" version, no libs. Compiling with VS2017, in this very case 32bit.

Maybe there is any hint, but however expect this is some odd detail. 

[Pete Dowson]

8 hours ago, KWB said:

Now my naive conclusion, my connection seems to get broken somewhere

"Connections" in such an interface aren't like communication connections which can "get broken".  The interface uses SHARED MEMEORY -- a block of real memory which is accessible to both processes.  As I pointed out before, everything to do with this is help in these fixed postion values:

static HWND    m_hWnd  = 0;     // FS6 window handle
static UINT    m_msg   = 0;     // id of registered window message
static ATOM    m_atom  = 0;     // global atom containing name of file-mapping object
static HANDLE  m_hMap  = 0;     // handle of file-mapping object
static BYTE*   m_pView = 0;     // pointer to view of file-mapping object
static BYTE*   m_pNext = 0;     // ...

Your code is corrupting some of these. You can see m_hMap an m_pview are next to each other, so you have something tramplying on both.

To find where just use the Debugger facility to set a breakpoint on one of the values, AFTER you've opened the interface.

m_atom is a 16-bit handle.
m_pView is a 32-bit memory pointer (64-bit in a 64-bit program).

The close Close and Open and immediate check works because you haven't executed any of your code, including the part which is going wrong.

Sorry, I don't see how I can help any further. You need to do the debugging.

Pete