Capt_Geoff

Well, I guess we both learned something then from all this work. I really do thank you for all the effort you've put into this. At least we can have a joystick ejection button and maybe a joystick rubber raft deployment button. I tend to agree with you about the timing as I can see no difference at my end either. But we sure have beat a dead horse eh? :shock: :roll: :wink: If I ever get over to Jolly 'ol England I'll buy you a beer or two. Same if you make it over to this side of the pond.

Wow! Interesting. The only thing that occurs after the message is a debug statement. I'll try taking that out, but I seriously doubt that is causing a problem. After that, it's pure FS magic. Actually the eject routine is probably one of the smallest callbacks I have.... EDIT: Nope no change. Oh well, button or keypress it is then. Edit 2: mmm I wonder about that "runs in a separate thread" statement...

Whew! good. I'll put the source back in then. I'll get you the gauge as soon as I can. EDIT; On it's way. Get to it when you can - I'm moving on in the development process to other gauges I need to build...

I need to make sure I understand something : Do I need to link in the ModuleUser.lib? I've never done this in my three years of programming with FSUIPC. I do however, have ModuleUser.c (well, actually it was IPCUser.c until just today) included as source code. I took ModuleUser.c out and put in the .lib - and my compiler (VC++ studio express 2008 version 9) is complaining about libc.lib which is not available to this version - although I tried to use libcmt.lib (which is recommended) but then the compiler complains "MSVCRT.lib(MSVCR90.dll) : error LNK2005: _atoi already defined in libcmt.lib(atox.obj)" I do not link to MSVCR90.dll, so I believe that may be in the ModuleUser.lib. I think the ModuleUser.lib is not compatible with my compiler - and maybe there in lies problem? I will send you the output of the two runs without ModuleUser.lib but with ModuleUser.c . They sure look darn near the same to me. Btw thanks for your help on this vexing problem.

Hi Pete - OK, I am now using the ModuleUser.c with the FSUIPC_Open2() function. Here are the snippets of the log - I put a couple of blank lines in to distinguish between the first part which is code generated and the second which is a joystick button initiated set of keypresses. The Lua works perfectly. the code/3110 still refuses to work. I put a set of stars around the 173000 area where there seems to be extra keypresses? taking place. But I also note that the Lua sequence doesn't actually load the aircraft until the joystick button is registered as having been released. At least that's what I make of the log file - in the for what it's worth department. Oh, and yes, I am using the fsuipc you made for me .852 172641 FSUIPC Control Action: Ctrl=1070, Param=4161 172641 SendKeyToFS(00010041=[alt+A], KEYDOWN) ctr=0 172641 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2 172688 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 172719 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 172766 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1 172766 FSUIPC Control Action: Ctrl=1070, Param=65 172766 SendKeyToFS(00000041=[A], KEYDOWN) ctr=0 172797 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 172844 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 172844 FSUIPC Control Action: Ctrl=1070, Param=80 172844 SendKeyToFS(00000050=[P], KEYDOWN) ctr=0 172891 Sending WM_KEYDOWN, Key=80 (Scan code 25), Ctr=1 172922 Sending WM_KEYUP, Key=80 (Scan code 25), Ctr=1 172922 FSUIPC Control Action: Ctrl=1070, Param=13 172922 SendKeyToFS(0000000D=[Rtn], KEYDOWN) ctr=0 172969 Sending WM_KEYDOWN, Key=13 (Scan code 28), Ctr=1 173000 Sending WM_KEYUP, Key=13 (Scan code 28), Ctr=1 173000 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4 173000 .. Key not programmed -- passed on to FS *********************************************************************** These next 173000 keys seem to be extra??? which the Lua does not generate 173000 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=4 173000 .. Key not programmed -- passed on to FS 173000 KEYUP: VK=65, Waiting=0 173000 KEYDOWN: VK=80, Waiting=0, Repeat=N, Shifts=0 173000 .. Key not programmed -- passed on to FS 173000 KEYUP: VK=80, Waiting=0 173000 KEYDOWN: VK=13, Waiting=0, Repeat=N, Shifts=0 173000 .. Key not programmed -- passed on to FS 173000 KEYUP: VK=13, Waiting=0 **************************************************************************************** 178438 Button changed: bRef=0, Joy=1, Btn=10, Pressed 178438 [Buttons] 1=P1,10,CL1:R,0 178438 LUA: beginning "E:\Program Files\Microsoft Games\Flight Simulator 9\MODULES\testmenu.lua" 178454 FSUIPC Control Action: Ctrl=1070, Param=4161 178454 SendKeyToFS(00010041=[alt+A], KEYDOWN) ctr=0 178454 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2 178454 LUA: ended "E:\Program Files\Microsoft Games\Flight Simulator 9\MODULES\testmenu.lua" 178485 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 178532 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 178579 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1 178579 FSUIPC Control Action: Ctrl=1070, Param=65 178579 SendKeyToFS(00000041=[A], KEYDOWN) ctr=0 178610 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 178657 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 178657 FSUIPC Control Action: Ctrl=1070, Param=80 178657 SendKeyToFS(00000050=[P], KEYDOWN) ctr=0 178688 Sending WM_KEYDOWN, Key=80 (Scan code 25), Ctr=1 178735 Sending WM_KEYUP, Key=80 (Scan code 25), Ctr=1 178735 FSUIPC Control Action: Ctrl=1070, Param=13 178735 SendKeyToFS(0000000D=[Rtn], KEYDOWN) ctr=0 178782 Sending WM_KEYDOWN, Key=13 (Scan code 28), Ctr=1 178813 Sending WM_KEYUP, Key=13 (Scan code 28), Ctr=1 178813 Button changed: bRef=0, Joy=1, Btn=10, Released 178813 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4 178813 .. Key not programmed -- passed on to FS 178813 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=4 178813 .. Key not programmed -- passed on to FS 182829 AIRCRAFT\ParaFoil\ParaFoil.air 182922 Aircraft="ParaFoil" 184063 KEYUP: VK=13, Waiting=0

Hi Pete - I'll answer first, as I just got back - and then implement the Open2.... which obviously I had not changed - I'm still using FSUIPC_Open(). Maybe that's the problem. Yeah, I'm still working on the old stand-alone version of my software, though I jumped to a gauge, oh, about 2 weeks ago. I made *really* good progress, and so I'm not doing any more work on the old program. I hadn't realized that I needed a new Open... For the parachute what we did was take a parachute we have used and changed the manufacturer to "p" (I think it was "parafoil" but I'm not sure). While you can't select a particular aircraft - your can get the first aircraft of a manufacturer, so by using "p" it is guaranteed to be the first "p" manufacturer. It's a trick one of our pilots found using the keyboard. And yeah, I added the 13 or 0x0D. Sorry about the confusion wrt to gauge and external program. And yes the gauge is opened first. Before the eject button can be used the switch which makes a connection to my server must be set ON - which also guarantees the gauge is fully loaded. So that works out very well. And I only close it when the user disconnects from my server. This also is required because my server saves the state of the player's aircraft for when he/she restarts Underway!. Now onto the Open2....

OK, the Luamenu test works as advertised! :D AFA the restart of FS is concerned - Could it be because I am modifying my gauge and I am doing this: start FS check my gauge functionality load a different aircraft modify my gauge code/recompile reload the original aircraft and during the reloading of the aircraft something gets hosed up in fs? The lua test works fine after reloads, the 3110 code does not and I am executing the code (I've got print statement verifying that I'm actually in the code). Note that I load a different airframe because the compiler complains that it can't write the gauge file as FS9 has it "locked".

Hi Pete - OK, I'm going to try and catch up with your requests: I'm using version 3.85 Dated 14 NOV 2008 here's a log I just compiled: ********* FSUIPC, Version 3.85 by Pete Dowson ********* Running inside FS2004(original release) User Name="Geoffrey McLean" User Addr="geoff@mcleanresearch.com" FSUIPC Key is provided WIDEFS not user registered, or expired [Continuation log requested by user] Module base=61000000 ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E WeatherOptions(Orig)=40003605[40003605] InitDelay: 0 seconds WeatherReadInterval=4 LogOptions=00000001 158391 System time = 09:23:47, FS2004 time = 19:48:36 (02:48Z) 158391 WeatherOptions set, now 40003605 (timer=0) 162641 FSUIPC Control Action: Ctrl=1070, Param=4161 162641 SendKeyToFS(00010041=[alt+A], KEYDOWN) ctr=0 162641 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2 162688 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 162719 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 162766 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1 162766 FSUIPC Control Action: Ctrl=1070, Param=65 162766 SendKeyToFS(00000041=[A], KEYDOWN) ctr=0 162813 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 162844 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 162844 FSUIPC Control Action: Ctrl=1070, Param=80 162844 SendKeyToFS(00000050=[P], KEYDOWN) ctr=0 162891 Sending WM_KEYDOWN, Key=80 (Scan code 25), Ctr=1 162922 Sending WM_KEYUP, Key=80 (Scan code 25), Ctr=1 162922 FSUIPC Control Action: Ctrl=1070, Param=13 162922 SendKeyToFS(0000000D=[Rtn], KEYDOWN) ctr=0 162969 Sending WM_KEYDOWN, Key=13 (Scan code 28), Ctr=1 163016 Sending WM_KEYUP, Key=13 (Scan code 28), Ctr=1 163016 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4 163016 .. Key not programmed -- passed on to FS 163016 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=4 163016 .. Key not programmed -- passed on to FS 163016 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=0 163016 .. Key not programmed -- passed on to FS 163016 KEYUP: VK=65, Waiting=0 163016 KEYDOWN: VK=80, Waiting=0, Repeat=N, Shifts=0 163016 .. Key not programmed -- passed on to FS 163016 KEYUP: VK=80, Waiting=0 163016 KEYDOWN: VK=13, Waiting=0, Repeat=N, Shifts=0 163016 .. Key not programmed -- passed on to FS 163016 KEYUP: VK=13, Waiting=0 163031 Monitor IPC:3110 (U16) = 0x42E 163031 Monitor IPC:3110 (U8) = 46 Note that the outcome of this is to put the sim in "Pause" mode. Next I'll work on the Lua....

Hi Pete - after tearing my hair out for a couple of hours I began to get suspicious of the logging functionality of FSUIPC. No matter what I did I could not get anything indicating 3110 was being accessed. I decided to shutdown FS and restart it. Lo and behold I got tons of logging information. AND - the sim was put into PAUSE. Note that the last keystroke is a . So I thought I'd strip down the commands to just - - again the log showed nothing and and nothing happened in FS. Again suspicious, I shut down FS9 and restarted it, set the logger and voila' I not only got the logging information - but I can see FS selecting the aircraft menu - momentarily. Not sure what is happening with the logger, but I gather that I need to shutdown FS9 after the first logging session. It's a pain, but now that I know I can live with it. I haven't (yet) tried your other suggestions as I'm running out of time for today. But I know now that 3110 is working - at least partially. So, if 3110 does not accept any but the last keystroke then I gather your advice it to set up a keystroke that will "execute" the alt a a p combination and then put that keystroke into 3110.

Yes, the whole combination works on the keyboard. selects the menu system the aircraft list (Note ALT-A goes directly to the aircraft list) again the "aircraft select..." menu item. select aircraft manufacturer "P" and selects the parachute. this is where I ran my code: 95625 WRITE0 3110, 8 bytes: 41 10 00 00 2E 04 00 00 95625 WRITE0 3110, 8 bytes: 41 00 00 00 2E 04 00 00 95625 WRITE0 3110, 8 bytes: 50 00 00 00 2E 04 00 00 95625 WRITE0 3110, 8 bytes: 0D 00 00 00 2E 04 00 00 95625 FSUIPC Control Action: Ctrl=4161, Param=1070 95625 FSUIPC Control Action: Ctrl=65, Param=1070 95625 FSUIPC Control Action: Ctrl=80, Param=1070 95625 FSUIPC Control Action: Ctrl=13, Param=1070 this is when I presume I pressed the keys: 97469 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4 97469 .. Key not programmed -- passed on to FS 97563 KEYUP: VK=18, Waiting=0 Although this shows (maybe?) one key event I actually went through ALT-a a p to which the simulator responded as I would expect in the menu system.

8985109 WRITE0 3110, 8 bytes: 2E 04 00 00 41 10 00 00 8985109 WRITE0 3110, 8 bytes: 2E 04 00 00 41 00 00 00 8985109 WRITE0 3110, 8 bytes: 2E 04 00 00 50 00 00 00 8985109 WRITE0 3110, 8 bytes: 2E 04 00 00 0D 00 00 00 this is what the log shows. Now I'm not certain - but it looks to me like the bytes might not be in correct order. If the printed order is reversed then it would be correct.... ie the first line 00 00 04 2E = 1070 decimal and 00 00 10 41 = 4161 decimal ALT-A. Is the log showing the data correctly?

DWORD pcresult; BOOL FSAPI eject_switch_mcb( PPIXPOINT relative_point, FLAGS32 mouse_flags ){ int code[2]; code[0] = 1070; code[1] = 4161; //- FSUIPC_Write(0x3110, 8, code, &pcresult); code[0] = 1070; code[1] = 65; // FSUIPC_Write(0x3110, 8, code, &pcresult); code[0] = 1070; code[1] = 80;// FSUIPC_Write(0x3110, 8, code, &pcresult); code[0] = 1070; code[1] = 13;// FSUIPC_Write(0x3110, 8, code, &pcresult); FSUIPC_Process(&pcresult); return FALSE; } Hi Pete - This is the code that I'm using in my gauge to trigger the menu system. Unfortunately nothing happens. I even tried substituting the key presses for bringing up the FSUIPC menu - but no luck there either. I deliberately left the code[0]=1070 in place as a test to see if, perhaps, the code array might be corrupted by the FSUIPC_Write. It's not , but just trying to be thorough in figuring out why the 3110 isn't working. Is the ALT-A formula correct - (256*16) + 65 ?

Well, actually, I am using wxWidgets and mingw which pretty much insulates me from windows. I had so many problems using the Borland commercial compiler I finally tossed it and found wxWidgets which is cross platform compatible and is rock solid. So, no; there are no Windows API calls whatsoever in my code - though in the underlying code I'm sure they tie in somehow with windows. While this is sufficient for proof of concept and got me up and running with a demonstrable program, it has it's drawbacks when working with MSFS - namely loss of audio by switching apps between FS and my program, and as we've learned the keyboard focus. The silence is deafening in the wxWidget world about my query regarding getting the focus of a non-wxWidget window. I carefully have read everything I can find and there is nothing to indicate that wxWidgets can tell me what window had the focus or will get it - except one of their own wxWdget windows. Indeed they are very consistent about saying that the call to determine who had the focus may return NULL. Hence, I conclude that it cannot be done. Well, this is all fine and good, because I've made some great strides in getting my gauge working, and the final big hurdle - the radar is coming along very nicely. So after that's done I'll put the eject button in the gauge - and since focus won't be an issue all your help here will be utilized. Kind of hated to waste the time trying to do the impossible - but sometimes that's the price we pay for stepping over the edge. Most of the code I used in wxWidgets is easily transportable to the gauge, only the low level drawing calls will change - and there aren't many of them. So, I suppose that I am a windows programmer - though I consider myself a real noobie wrt to windows. But even an old *nix/Linux programmer can learn new things!

Yeah, they could, however, we are trying to implement an "ejection system" whereby the user hits the eject button and whamo - he's in a parachute. Also, once the chute lands on water, we want to instantly put him into a life raft (without pushing a button). So, yes, the fallback is a five keystoke event versus a button. Not too painful, but you know programmers, we want to push the envelope :wink: I presume by SetFocus API you mean something in Windows? I'm not a Windows programmer. I've been able to finally get a gauge (dll) going and it's getting pretty sophisticated and that would obviate the focus problem, but I was kind of hoping for an immediate solution while I continue work on the gauge. I do have queries out in the wxWidget world to try and see if there isn't some method - after all my app does know when it has and doesn't have the focus. It's just trying to figure out how to set the focus back to the FS window that's the problem. Preliminary tests indicate that only wxWidget windows are known - although somewhere in the depths of the operating system it (obviously) knows which window (whether a windows XP window or a wxWidget window) has the focus. Google is my friend - and searching more I must do.

My application has the focus because the user is pressing a button in it. Unfortunately, I have no idea how to switch the focus back to FS. Currently my app is standalone, although I am also working on making it into a gauge for a new version - but it's completion date is still far far away. I'm using wxWidgets in this version of my app, so I will have to peruse the docs to see if there is some means of focus switching. And yeah, you are right about the sound. It is most annoying that FS cuts off the sound when switching to another app. I wonder what made them decide to do that? If not for that, there would be no need for me to make a gauge - and what a pain that is! M$ breaks every GUI and developer rule in the book. But they are the 800 pound gorilla in the room. :shock: