737-SimGuy

According to the Aug 20th development update Asobo released last night there won't even be an announcement of the patch date until their next video on the 27th. Oy vey. https://www.flightsimulator.com/august-20th-2020-development-update/

Any response at all from MS/Asobo about this Simconnect issue??? James

This has been updated to reflect the correct data in the latest FSUIPC Client DLL available via Nuget... James

John and Pete, Just an update: Ian at BFF has re-factored his connection technique and now his control loader application is connecting without issue. Thank you for the info needed to correct this. James

Hi Trevor, long time no chat. Hope all is well. I'm not sure you qualify for the "old age" excuse yet 😉 hehehehehe James

Right yes. It appears the issue with the BFF application is that he is using the presence of FS98MAIN as indication of FS running, and some other way to determine FSUIPC was running. He has all the info now and at some point I hope to hear back from him. Thank you, James

I must be blind as a bat for I am not able to find the new betas. I looked in Updated Modules and I also tried the versions here: http://fsuipc.simflight.com/beta/FSUIPC7.zip http://www.fsuipc.com/download/FSUIPC7.zip But they still seem to require the SimConnect.dll in the FSUIPC7 folder. James (EDIT) DISREGARD, it was a browser cache issue.

Ok, more to the story. When I checked that all applications were run at the same Admin level I only checked using the BFF application and it didn't fix the issue, however when I just did that with MY applications that use FSUIPC Client DLL it worked! So John and Pete you were of course both correct and it is a separate issue with the BFF loader application! Any application using FSUIPC7 on the MSFS computer require the same privileges, confirmed! Apologies for the distraction. I did not troubleshoot effectively. James

Hi Paul, Well this was apparently the problem for my apps! Wow. I checked that both were admin for the BFF app but not my own. Oops. Didn't work for the control loader app from BFF so maybe there is more going on there. Thank you, James

Paul, I am experiencing the problem of connecting to FSUIPC7 as well only when my apps are run on the MSFS machine. I also have an application for control loading from BFF that uses FindWindowEx api call to find the FSUIPC7 window class but it cannot connect either. If you discover why this is happening please post. This from John Dowson: ""The main window in FSUIPC7 is now FS98MAIN, and, as Pete says, it also creates UIPCMAIN (and UIPCINTERNAL) for messages. The window/class name for MSFS is now AceApp (in P3D/FSX was FS98MAIN).”" Thank you, James

Yes, both as Admin. Am I the only one who runs anything requiring FSUIPC on the MSFS machine?? "All existing FSUIPC applications should be able to connect in exactly the same way as before. Pete" This is not the case, sorry to say. I have forwarded the info to BFF folks and I will await Pauls new DLL for my applications... James

Ok thank you, working on it... James

Ok, so it HAS changed. I will forward this on... Thank you, James

Well, that is the issue, these programs have NOT been changed, but they do not find FSUIPC7 when run on the same machine. So I am not sure what details you would need. My apps use Paul's FSUIPC Client DLL and the BFF control loader uses FindWindowEx unchanged from his previous working versions. James

John, BFF doesn't use the client DLL, has the window name changed? James

Ahhh, ok. Thank you. I'll keep an eye out... James

This from Ian at BFF: "If I recall correctly my software looks first for "UIPCMAIN" with a FindWindowEx call as this is what usually exists with a local FSUIPC active. If it doesn't find it it then looks for "FS98MAIN" which is what is present when WideFS is active" It is returning 0x0 James

Hi John, I am the developer in this case, but my BFF control loading software does not connect either. I am using Pauls FSUIPC_Client DLL and have changed nothing. It connects via wide client no problem. Is there something specific that needs to be changed here? I don't recall anything in the release notes about this. James

Hi John, From what I can tell so far apps will not connect to FSUIPC when run on the same machine as FSUIPC7. They do connect fine to WideFS on remote computers.I tried running WideClient on the MFS machine but of course it says "The same program or class is already running [FS98MAIN]", as expected. This is a critical feature for me as my control loading software depends on it and I have no way to fly without it... James

Thanks.... Tried every trick I know of and couldn't copy it either 😞 James

Where did you find the one dated 8/8/2020? I'll give it a go. A search doesn't find it. James

Paul, Is there much overhead in the RefreshData method? Is it a problem calling it say every 50 or 100 ms? I have been doing all this manually until just now seeing this thread, thought I might give it a try. With my code I am simply checking the status of B000 every 100ms, is that what refresh data is doing? Thank you, James

Hi, You could try running the Windows system file checker command DISM. Maybe the DLL is corrupt somehow. https://support.microsoft.com/en-us/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system James

Hi, I don't know if it will help but worth a try: I set both the Makerwys.exe and the Lorby exe to run as ADMIN. If I don't then I get different results each time I run Makerwys. Right click the exe in Explorer and select Compatability tab then tick Run As Administrator. Hope it helps. James

Ok thanks Pete. I'll keep an eye out for it... James