Paul Henty

Hi Pete, One of my users is having problems with restoring focus to P3D (V4.4) from my DLL. I don't have P3D so I can't test it myself. My DLL makes use of control 1125 (Key Focus Restore) which works fine for FSX. The user experiences a flashing P3D icon in the task bar, but the P3D window doesn't actually get focus or jump to the foreground. The P3D window is not minimised. Can you please check this in FSUIPC5 and see if it works okay? My user has solved the problem using Win32 calls to ShowWindow and SetForegroundWIndow but I'd rather stick to issuing the FSUIPC control if possible. Thanks, Paul

I'm glad you got it working. It seems like the focus feature in FSUIPC isn't working properly for P3D. I'll discuss it with Pete. Thanks for the DLL import code. Paul

It's not clear to me if you've tried the new version of the dll (3.1.9). Does it not work? If not, then it's possible there's something different about P3D when switching focus. I don't have P3D so I can't test it here. It works fine on FSX. Your video shows that P3D isn't getting focus properly. It should come the foreground above your application. I don't know why it's just flashing. Here is the code to switch focus to the flight sim: SendControlToFS(FSUIPCControl.Key_focus_restore, 0); You can try this on its own and see if P3D gets proper focus or not. If this also gives you a flashing icon without proper focus then we'll have to ask Pete about this. Paul

It sounds like the focus is taking longer than the dll expects. I've increased the wait time from 150 to 300 ms and released 3.1.9-beta. Please upgrade via Nuget and let me know if it fixes the problem. (To get beta versions you need tick the box called 'include pre-release' in the nuget manager). Paul

Yes that's what the DLL does. It first gives focus to the flight sim. Then it sends the key you requested. It will then restore the focus to your own application window. But only if you ask it to (third parameter). When you call FSUIPCConnection.Open() it will thrown an exception if a flight sim or WideClient.exe is not running. You should catch these exceptions to know that FS is not running. When you call other functions that talk to FSUIPC e.g. Process() or SendKeyToFS(), these will also throw exceptions if the connection has been lost. You can examine the FSUIPC Application Templates to see the recommended way to handle the connection management. http://fsuipc.paulhenty.com/#downloads Paul

Thanks Matthias, Yes, FS must have the focus. That's just how Windows works. The DLL handles this for you though and can give the focus back to your form if you need to. Paul

Hi Matthias, There is now a function in the DLL to send key presses to the sim. Sending Tab+1 would be this: FSUIPCConnection.SendKeyToFS(Keys.D1, SendModifierKeys.Tab); This also takes care of setting focus to the sim first. If you want to return focus to your own application, include a reference to this form as the last parameter. For example if the code is part of the form class: FSUIPCConnection.SendKeyToFS(Keys.D1, SendModifierKeys.Tab, this); The modifiers in the .net "Keys" enum are not the same as the modifier codes used by FSUIPC. I had to make my own enum for the DLL (SendModifierKeys). For future questions, please make a new thread in my sub forum. Kind Regards, Paul

The current version of my FSUIPCClient.dll (3.1.5) is mixed mode. meaning you can use it in 64 or 32 bit applications. This version is only available on NuGet. Instructions for installing and upgrading from earlier versions can be found here: http://fsuipc.paulhenty.com Paul

It's just a standard .NET class library dll. If you installed it via NuGet then it has been automatically added as a reference. Check the references for your project and you'll see it. The actual dll file will be copied to your build folder (debug/release) as normal. I think the official SDK has a very old version of the dll (maybe 2.0). A lot of new stuff went into 3.0 including the LVar read/write. I moved to NuGet as it's much easier to publish new versions and keep everyone alerted to new builds. Paul

My .NET library for talking to FSUIPC from .NET languages. That's what this subforum is for. Details about the DLL are here: http://fsuipc.paulhenty.com If you're not using a .NET language then let me know and I'll give you the steps you need for talking directly to FSUIPC. Paul

Yes. If you are using the latest version of my DLL (3.1.5 or above) you can now use: FSUIPCConnection.ReadLVar(Name) and FSUIPCConnection.WriteLVar(Name, NewValue) Paul

Hi Mattias, 0x3380 is only for writing your own messages to the sim. It doesn't read text from the sim. As far as I know, there is no way of intercepting messages generated by the sim with FSUIPC. Paul

Hi Vince, Generally, to achieve what you want, you need to be checking the altitude regularly in a timer. If the altitude is 10000 AND the checkbox is checked then you need to pause. However, the altitude may never be exactly 10000, it might go from 9999 to 10001 so you need to test a range. Something like this (Not real code): TimerEvent: FSUIPCConnection.Process() alt = getCurrentAltitudeInFeet() if alt < 10100 AND alt > 9900 AND pauseAt10000 is checked pauseSim() pauseAt10000.checked = false end if Paul

Hi Machado, FSUIPC4 only supplies 2 decimals. I think that's all that's supported in FSX. If you know the spacing between the frequencies in real life you can infer the third decimal. For example, 118.720 may not be a valid frequency, so you can assume it's actually 118.725. I think that's what these planes are doing. If not, they are handling the third decimal internally. You may be able to access it using the plane's SDK if it has one. I don't know if this is different in FSUIPC5 (P3D). You might want to ask Pete about this when he's back. Paul

Hi Jesús If you log into your SimMarket account you can see all of the products you have purchased. Use the 'Your Account' menu and select 'Purchase History'. Find FSUIPC4 and click on the order. This will show you your key, and the name and email address you used. When you register FSUIPC these must be exactly as they appear in the order. Copy and Paste is recommended. Paul

That's the same log as you attached in your first post. The logging options aren't enabled. I think the best thing to do would be to delete all the .log files in the modules folder, then try again. Start FSX Open the FSUIPC interface Enable the logging options Recreate the problem with the landing gear/hud Close FSX Paul

Hi, That's not the correct log file. Can you try again, or find the one that's just called FSUIPC4.log. If you can't upload it just open it in notepad and copy and paste the text directly into your reply. (You can use the <> icon on the editor menu bar to make it easier to read). Thanks, Paul

Hi Steve, I'm not familiar with CCP at all. Are the original devs are not around any more? They would be the best people to ask. If you can't contact them, you can send me an FSUIPC log with these options enabled (only these): IPC Writes Button and Key Operations Events (non axis-controls) (See the logging tab in the FSUIPC dialog). I'll be able to tell you if CCP is intercepting any buttons or key presses. With the logging enabled, run FSX/CCP and reproduce the error. Then close FSX and show me the contents of the FSUIPC4.log from the modules folder. Please start a new thread in this sub-forum if you do. Paul

Hi Michael, Unfortunately that FSUIPC facility only works with user-added menus, not the built-in ones. FSUIPC can tell you if the user is using the menus or a resulting dialog (see 0x3365) but not which one. If you just want to detect the reload then try offset 0x3F02 (ushort). This is a counter that increments each time a flight is loaded or reloaded. The reset might just re-load the same flight and increment this counter. Another idea is that your application could offset a reset-flight option that just sends the appropriate control to P3D (try SITUATION RESET 65591). But at least you know when it happened. It might also be worth asking Pete (in the main forum) if he has any ideas. Paul

I understood this to mean that you can use the same process call to read the value: and doing that seems to work fine locally. I get the idea for the loop, but that would be too slow for monitoring many LVARs in real time. I'll make a note in the DLL documentation that the LVAR feature doesn't work over WideFS. Thanks, Paul

I've just seen that Pete's away until Friday. I've posted my question in the main forum, so we'll have to wait until he gets back to see if anything can be done. Paul

Hi Pete, One of my DLL users has a problem with reading LVARs over WideFS. It's fine locally. I've tested this myself and I get the same problem here. For best performance my DLL writes the LVAR request and reads the result in one process, as described in the documentation. 1. Write user address to 0D6C 2. Write LVAR name to 0D70 3. Read result from user address However over WideFS this really isn't working as expected. The value returned is from the previous LVAR request (if a long enough gap is left between reads)... Read LVAR1 Sleep Read LVAR2 Sleep Read LVAR3 etc.. This gets the previous LVAR value. If there is no gap... Read LVAR1 Read LVAR2 Read LVAR3 They all get the same value. I'm guessing this is because the process() on WideClient is not synchronous with the network updates so it's not waiting around for the correct result to come back. It's just supplying the cached value it already has in the user offset. The only solution I can see is to get the result a short time after requesting the data (i.e. in two process() calls). This is not great because it'll be much slower and I can't be sure of how long to wait. If I find a delay that works on my network, it may not work on another developer's, or end user's network. Do you think there is anything that can be done in your code to help with this? Or do you have any other suggestions for a solution? Thanks, Paul

Understood. Thanks. I think I know what the problem is. I'll need to speak to Pete about it and get back to you. Paul

Okay, that rules out threading problems. So it's something to do with WideFS. Can you clarify a few things... How are you operating the lights? Directly in the sim? Writing to offsets/controls? When you say all the lights turn OFF, do you mean in the sim, or just that your program is reading them as OFF but they are really still ON. Paul

The async call looks okay from what you've posted. That's probably the best way to proceed with these kind of issues. If you just make a single-thread program that read/writes the lights LVARS and see if there's any difference when you run over WideFS. That will at least tell you if the problem is with LVARS over WideFS or if it's more to do with the way you're calling the DLL (probably some kind of threading problem). Paul