3110 and FS commands

[Capt_Geoff]

Hi Pete - I am trying to activate a menu selection in FS9. the key strokes needed are

. Note that alt is by itself - not a combination alt-a

Here's the code I've used with no luck:

eject(){

       static unsigned long result;
	int control =1070,code;

	code = 17;   //
	FSUIPC_Write(0x3110, 4, &control, &result); 		
	FSUIPC_Write(0x3114, 2, &code, &result);	
	FSUIPC_Process(&result);

	code = 28; //

I guess I'm confused as to what keycodes are - are they ASCII (I tried them)? Any help would be greatly appreciated

[Pete Dowson]

I am trying to activate a menu selection in FS9. the key strokes needed are

. Note that alt is by itself - not a combination alt-a

Two things there, to start with:

1. Why separate ALT and the A? It would probably work better if you did combine them. That's the way menus work anyway -- the alt then A method is merely a friendly alternative, because the ALT key brings up the menu.

2. To go further, with subselection in the menu, is actually quite difficult, as it is timing-related. Once the ALT key is actioned and the Menu takes the focus, more keypresses addressed to the normal FS window will not be seen. All the keypresses need to be in the "buffer" at the time the focus changes. Unless you are careful this can be a little bit of "pot luck".

It seems to work reasonably well if all of the keys are pressed from one button operation (i.e. editing the FSUIPC INI file so that several keypresses are assigned in the correct sequence, to one button). A macro to do the same might also work. This is because FSUIPC is holding the processor whilst it is processing these things.

Here's the code I've used with no luck:

Ah, you are trying to do it by program? Hmm. Let's see:

static unsigned long result;

int control =1070,code;

code = 17; //

FSUIPC_Write(0x3110, 4, &control, &result);

FSUIPC_Write(0x3114, 2, &code, &result);

Big error there! Please refer to the documentation for offset 3110. It clearly tells you that you must write all 8 bytes in one Write. But you have split it! It says "FSUIPC will fire the control when you write to 3110". Did you not see that?

You might get away with writing 3114 first then 3110, but really you should declare the 8 bytes as an array of 2 ints or DWORDS, set both values, then write 8 bytes.

FSUIPC_Process(&result);

Ouch. You try to send just the ALT in one process call? So you cause Windows to switch between you and FS and then back to you? By then surely the focus will change and any more keys sent will be wasted (or worse, saved up and used when you exit the menu).

Why are you interspersing each request with a Process call? ALWAYS bunch ALLL read and write requests you want to do in one Process call. it is EXTREMELY inefficient to have lots of little process switches like this.

Finally, where do you get those numbers:

code = 17; //

code = 28;//

code = 77; //

What list are you finding such weird numbers in? In the lists I publish A is 65 (there's no 28 listed), and P is 80. Your 77 would be M.

Please tell me where you are getting your numbers from. Are you simply inventing them yourself? :-(

I guess I'm confused as to what keycodes are - are they ASCII (I tried them)? Any help would be greatly appreciated

Keycodes are the codes Windows uses to identify the keys. For alphanumerics they tend to be partly equivalent to ASCII, but you should certainly not take that for granted. There are no ASCII definitions for many keys in any case. Take a look at your keyboard sometime! F1 to F12 don't figure in ASCII, nor do any of the cursor and editing keys, except maybe Return, Tab and Backspace.

Regards

Pete

[Capt_Geoff]

Big error there! Please refer to the documentation for offset 3110. It clearly tells you that you must write all 8 bytes in one Write. But you have split it! It says "FSUIPC will fire the control when you write to 3110". Did you not see that?

Ah, I see now - I thought you meant FSUIPC_Process.

What list are you finding such weird numbers in? In the lists I publish A is 65 (there's no 28 listed), and P is 80. Your 77 would be M.

Please tell me where you are getting your numbers from. Are you simply inventing them yourself?

Ah HA! The numbers are the literal keyboard keys. Since I had tried the ASCII (ie 65 for A; 80 for P) I thought maybe ascii was the wrong thing to be passing.

I just tried to manually use the keystroke and it seems to work fine, so I will attempt that.

In all my other code I do bunch all the writes into one process - just was confused here in this code. So, if I'm understanding correctly I should be able to do this?

eject(){

       static unsigned long result;
   int code[2];

   code[0] = 1070;
   code[1] = 4161;   //-
   FSUIPC_Write(0x3110, 8, code, &result);       

   code[1] = 65; //
   FSUIPC_Write(0x3110, 8, code, &result);   

   code[1] = 80;//

   FSUIPC_Write(0x3110, 8, code, &result);   
   FSUIPC_Process(&result);

}

But don't the writes write on top of each other?

[Pete Dowson]

Ah, I see now - I thought you meant FSUIPC_Process.

Er, sorry. You've lost me. I think you are still misunderstanding some fundamentals.

NOTHING is sent to FSUIPC until you do the "Process" call. All the Read and Write calls do is queue up your requests inside your own program, ready to be sent.

When the Process call is issued, all of your queued requests are sent to FSUIPC. There they are processed strictly in the order you made them! So, in your program the Write to 3114 gets done BEFORE the write to 3110.

Don't you see it would make a mockery of things if FSUIPC jumbled up everything and wrote stuff in any old order? It has to do it as you ask!

The numbers are the literal keyboard keys.

Oh, you mean the SCAN codes? Why would you use those? Why not simply use the lists I provide in the documentation -- in the very same document you found the "1070" control number, for instance?

Since I had tried the ASCII (ie 65 for A; 80 for P) I thought maybe ascii was the wrong thing to be passing.

It is only coincidence that those are ASCII. Do not rely on it. Always look the codes up in the list provided.

If you are using a Windows compiler for your program, the key codes will all be defined for you with names, in any case. In C/C++ they are defined with "VK_" prefixes, for "Virtual Key".

So, if I'm understanding correctly I should be able to do this?

That looks more likely to work, though I'm still a little worried that the focus will switch to the Menu before the whole sequence is done. You'll just have to try it.

But don't the writes write on top of each other?

Yes, of course. But as I said, and as the documentation clearly says, "FSUIPC will fire the control when you write to 3110". Since it does your Writes strictly in the order you list them, it doesn't matter that the values are then overwritten again, does it?

Regards

Pete

[Capt_Geoff]

Ach! no joy. Thanks for the explanation. I'm wondering if sending them like this is too fast for FS to handle. when you manually use

there is a significant pause at the second

[Pete Dowson]

Ach! no joy. Thanks for the explanation. I'm wondering if sending them like this is too fast for FS to handle. when you manually use

there is a significant pause at the second

I very much doubt that it is "too fast", because all that will happen is that the keypresses will go into the queue. I've certainly had consistent success getting the FSUIPC dialogue displayed by having a button defined with ALT m f (or ALT d f for FSX), but possibly going any deeper than one level from the main menu may be impossible.

What exactly happens with your sequence? Does it get no where at all?

Pete

[Capt_Geoff]

Yes, that's right. Apparently nothing happens.

I tried an experiment from within FS using those keys as fast as I could go and it did queue up the presses. I also added a 13 call for the key as well to the source code, since the aircraft popup-dialog needs that to close itself.

I'm wondering if, since my application has the focus at the time of sending the keypresses, if FS doesn't get them? But That doesn't seem right since all my other FSUIPC calls (with or without focus) work correctly. OTH - this is the only key press /3110 calls I make.

[Pete Dowson]

Yes, that's right. Apparently nothing happens.

You've got something wrong, then if nothing at all happens. It should at least call up the Menu bar.

I'm wondering if, since my application has the focus at the time of sending the keypresses, if FS doesn't get them?

Hmmm. Don't know. Maybe. FSUIPC certainly expects FS to have focus. Why has your application got the focus? Try letting FS have the focus. There's no sound from FS if you take its focus away in any case.

But That doesn't seem right since all my other FSUIPC calls (with or without focus) work correctly. OTH - this is the only key press /3110 calls I make.

Focus only affects keypresses in any case (and sound, but that's only because FS deliberately cuts off the sound on loss of focus).

Pete

[Capt_Geoff]

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:

[Pete Dowson]

My application has the focus because the user is pressing a button in it.

Hm. Using the mouse or keyboard? Couldn't he use the menus then, without your program's assistance?

One way of allowing him to use your program without leaving FS (or its focus) would be to use the FSUIPC application hot key or hot button facility.

Unfortunately, I have no idea how to switch the focus back to FS.

SetFocus API?

Regards

Pete

[Capt_Geoff]

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.

[Pete Dowson]

I presume by SetFocus API you mean something in Windows? I'm not a Windows programmer.

If you write a program which runs under Windows, you are a Windows programmer. Your program must be littered with things that call Windows API's, surely. Even the interface to FSUIPC is solely composed of calls into Windows.

Just type SetFocus in your help or MSDN or whatever, or in Google if necessary. I'm sure it is accessible in any language you might use to write programs under Windows.

Regards

Pete

[Capt_Geoff]

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!

[Pete Dowson]

... 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.

Good. Carry on programming, then! ;-)

Pete

[Capt_Geoff]

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 ?

[Pete Dowson]

This is the code that I'm using in my gauge to trigger the menu system. Unfortunately nothing happens.

I am amazed that nothing happens, but i wouldn't necessarily be surprised if the characters after the ALT+A did anything.

But if ALT+A on the keyboard invokes the menu, then so must the first write you are sending (assuming your code does have an FSUIPC_Process call somewhere afterwards, not shown above). Are you sure?

I even tried substituting the key presses for bringing up the FSUIPC menu - but no luck there either.

I've not written a program, but I tried the same thing by assigning ALT+M keypress to a button, using FSUIPC's options, thus getting this in the INI file:

[buttons]

1=P1,0,K77,24

which deals with the ALT+M, and then I added this in the INI file:

2=P1,0,K70,8

in order to send the F.

In FSUIPC Button options i reloaded the button settings. Pressed the buttonlo and behold, the FSUIPC dialogue came up, fine!

With the Button and Key logging enabled in FSUIPC's logging page you can see what happens:

  1456484 Button changed: bRef=0, Joy=1, Btn=0, Pressed
  1456484 [Buttons] 2=P1,0,K77,24
  1456484 SendKeyToFS(0001004D=[alt+M], KEYDOWN) ctr=0 
  1456484 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2
  1456531 Sending WM_KEYDOWN, Key=77 (Scan code 50), Ctr=1
  1456578 Sending WM_KEYUP, Key=77 (Scan code 50), Ctr=1
  1456609 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1
  1456609 [Buttons] 3=P1,0,K70,8
  1456609 SendKeyToFS(00000046=[F], KEYDOWN) ctr=0 
  1456656 Sending WM_KEYDOWN, Key=70 (Scan code 33), Ctr=1
  1456687 Sending WM_KEYUP, Key=70 (Scan code 33), Ctr=1
  1456687 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4
  1456687 .. Key not programmed -- passed on to FS
  1456703 KEYDOWN: VK=77, Waiting=0, Repeat=N, Shifts=4
  1456703 .. Key not programmed -- passed on to FS
  1466015 Button changed: bRef=0, Joy=1, Btn=0, Released

Encouraged, I edited this in the INI file's [button] section:

3=P1,1,K65,24

4=P1,1,K65,8

5=P1,1,K65,8

This tries to do the whole thing -- ALT+A, then A, then A againthat seems to not only get the Aircraft selection menu up, but also select "Any" in the first field.

... but just trying to be thorough in figuring out why the 3110 isn't working.

Who says it isn't? Have you tried the logging to see what it is doing?

Is the ALT-A formula correct - (256*16) + 65 ?

According to my arithmetic, yes. Of course you could always use "(256*16) + 65" in your program and let the compiler do the work.

Regards

Pete

[Capt_Geoff]

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?

[Pete Dowson]

this is what the log shows.

Why log IPC writes? We want to see what FSUIPC makes of what you are writing. I suggested logging the Key and Button actions, as I did, then you see the actual results, the key combinations being sent to FS!

Now I'm not certain - but it looks to me like the bytes might not be in correct order.

Yes, they are -- Intel processors are "little endian", meaning that the first byte is the least significant. Motorola processors wre the last ones I know that were "bug endian".

Have you tried assigning a button or key as I showed, and which worked? Can you yet confirm, as I asked, that "Alt A" by itself actually does anything, even on the real keyboard? If it does anything on the real keyboard it just has to when the same combination is sent to FS.

Pete

[Capt_Geoff]

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.

[Pete Dowson]

this is where I ran my code:

That's all wrong:

    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

You have the parameter as the control and the control as the parameter. You've reversed it since the last log snippet you showed, so your last tests are worthless. Why have you done that? 3110 holds the control, 3114 the parameter. Put it back the way you had it, THEN show me the log -- without the IPC write logging please!

And are you absolutely sure you are using an up to date version of FSUIPC (3.85)?

Pete

[Pete Dowson]

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.

Okay then. Here's another demonstration which works perfectly here. Save this little Lua program into your FS9's Modules folder as "testmenu.lua".

     ipc.writeStruct(0x3110,"2UD", 1070, 0x104D)
     ipc.writeStruct(0x3110,"2UD", 1070, 0x46)

Then go into FSUIPC's Buttons or Keys options and program any button or keypress (a joystick button would be better to demonstrate complete independence from the keyboard) to use the new control called "Lua testmenu". Okay out of the options.

Now use that button or keypress. The ALT+M then F sequence sent by the Lua program via offset 3110 brings up the FSUIPC menu.

Okay. Cancel and now replace that testmenu.lua program with this one:

     ipc.writeStruct(0x3110,"2UD", 1070, 0x1041)
     ipc.writeStruct(0x3110,"2UD", 1070, 0x41)
     ipc.writeStruct(0x3110,"2UD", 1070, 0x50)

This one sends your Alt+A, then A then P.

Try it, using the same key or button you already programmed.

Here, this manages to do the ALT+A and A, okay, so gets to the Aircraft selection menu, but the P must arrive too late and doesn't get to the FS dialogue at all.

I've got a modification to the Lua plug-in "ipc.writeStruct" facility which should deal with that. I'll tell you about that when I've got it working (it already works fine on FSX).

Regards

Pete

[Capt_Geoff]

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.

[Pete Dowson]

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.

No, no no! Never! the logging facilities have always worked fully, ever since version 1.00 in 1999! They've been an absolute essential part of all the developments I've ever done, and there's never been any need to restart FS, at all.

I'm sorry, I cannot see what you are doing from here, but I'm also not getting the information I ask you for. Like WHAT VERSION OF FSUIPC are you using? Can't you even tell me that please? If you can't work it out please show me a complete Log file so I can read it for myself.

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.

Not at all! The first few keystrokes are the ones which will be picked up before it is too late and Windows' Menu dialogues grab the focus. I've no idea why you only see a fleeting glimpse of the Aircraft menu -- what is dismissing it? How can it be dismissed except by you, on the keyboard, once it is called up? Are you sure you are not using some other key presses? A proper log, as I asked many messages ago, would tell me a lot!

So far you've not shown me a proper log, you've not told me the version of FSUIPC you are using. I've been working my *** off trying to sort things out for you, surely you can cooperate a little more than you are doing? Please?

:-(

Pete

[Pete Dowson]

I've got a modification to the Lua plug-in "ipc.writeStruct" facility which should deal with that. I'll tell you about that when I've got it working (it already works fine on FSX).

Okay. Download this new interim update for FSUIPC3:

http://fsuipc.simflight.com/beta/FSUIPC3852.zip

This contains an enhanced Lua "ipc.writeStruct" facility (readStruct also, but that's not relevant here) which can write to several different (or same) offsets in one Lua instruction. This enables it to get all of the ALT+A, A, P sequence into the keyboard buffer before FS has changed focus to the dialogue.

After placing that FSUIPC.DLL in your FS9 Modules folder, replace the "testmenu.lua" program I gave earlier with this one:

ipc.writeStruct(0x3110,"2UD", 1070, 0x1041,
		0x3110,"2UD", 1070, 0x41,
		0x3110,"2UD", 1070, 0x50)

Then run it as before, using the button (preferably) or keystroke you already programmed for it.

This opens the Aircraft menu and selects the first "P" entry, exactly as you expect when using the keys themselves. Note that this Lua plugin, whilst obviously not subject to the focus problems inherent with running a client program on the same PC as FS, is in effect doing EXACTLY the same as your program should be doing if it were writing the correct values with one FSUIPC_Process call. This is why I am showing you, because it demonstrates that it works!

You can, of course, invoke Lua programs from your own program, just by writing the Lua control name ("Lua testmenu" in this case) to offset 0x0D70. This addition was described in the FSUIPC History document recently -- it hasn't yet made it into the released SDK.

Regards

Pete

[Capt_Geoff]

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....