Pete Dowson

Which error messages? Please do try to be specific. Normal searches won't find them. You need to change Windows options to avoid hiding files, and also search hidden and system files and folders. Or else just go directly to the right places, which you can find out about be browsing the various hints and FAQs sites. There may also be information about un-installing and re-installing FSX on Micrsoft's own FS website. However, over the two years since FSX was released, the thing NOT to do, except as a last resort, seems to be to uninstall and reinstall FSX. It so often seems to compound problems up to the point you need to reinstall Windows. How do you determine whether it loads or not? The absence of a Menu entry isn't proof of that. You'd need either a debugger/process explorer, or a SimConnect log to see. It is SimConnect which loads it. I'd need to see both the FSUIPC log (if there is one), and the FSUIPC4 Install log ("seemed to" is not quite precise enough -- there's a lot of information in the log). If FSUIPC4 wasn't loading, why remove it? You are making it more difficult to resove doing all thiese things without reason. Regards Pete

I still find your calibration results rather weird. -16384 and +16383 are the very minimum and maximum values possible, which means you've no leeway for slight changes at the extremes, and having the centre so precisely -512 to 0 or similar is so unlikely it just looks wrong, as if the devices are either software (not hardware at all and subject to any physical variations). In other words, they still look uncalibrated, pretty much. As for your axes: Are those ALL of the axes on each device -- i.e. does the Wingman only have one axis (0R)? Are you sure there are no other axes being assigned in FS? What you describe can really only be caused by bad hardware, bad wiring, bad USB port, or multiple assignment. The last could be multiple assignments in FS conflicting with those in FSUIPC. Or maybe from that "driver and phidgets.msi" part. You did say: So why is the throttle taking a different route to the yoke? Are you sure you've not got your setup all wrong there? If it all worked "before" you need to determine what made the "after" different. Maybe you need to talk to Mr. Van den Broeck? Regards Pete

Okay. Fixed that long-standing error with the Error messages on Conditionals, and also retained the names of joysticks when disconnected. I decided not to put the error message for a missing joystick on every affected button line. You'll just need to check the JoyNames section. Versions 3.858 and 4.413, now available above. Happy Christmas! Pete

You are running FS9, which needs FSUIPC3, not FSUIPC4. Discard FSUIPC4329, which is not only out of date and unsupported, but is for FSX in any case. It certainly does. Why didn't you just state the message instead of taking a picture? Surely it would have been easy enough instead of listing all that other stuff which was totally irrelevant! It says you are running Version 9.1 of FS2004 and you are trying to run a VERY VERY old version of FSUIPC3, which doesn't know anything about FS9.1 because that was invented long afterwards. Just download the current, supported version of FSUIPC (3.85) and install that instead. Please NEVER come here asking for support without first making sure you are up to date. If you look in the Announcements above you will see plenty of information to help, including a list of supported versions. Please refer to it! Regards Pete

Since no information was forthcoming about the first error, I don't see how you can identify yours as exactly the same. With no information at all there's no way to know what is going on. Sorry, but I can only suggest you ask Microsoft support, unless you want to wait until after December 29th, when I return. Either way you'll need to be a lot more specific about what your problems are. Just a bit of a hint though. It is extremely difficult to actually do a complete uninstall of FSX. The side-by-side library systems don't uninstall, and reinstall incorrectly when you try, and there are lots of files FSX creates in Document and Settings and My Documents which are usually not erased, and which really need to be. Uninstalling and reinstalling FSX is not something to be taken lightly. You need to make a list of all the things to do and do them methodically or yuou end up in a worse mess than the one you thought you were in before! Whilst I'm away you may find some kind soul over in the FSX Forum who can help. There may also be some threads around which detail exactly what to do to reinstall correctly -- it would be worthwhile also visiting the Microsoft FSX website. Regards Pete

Okay, I need to get this done before I disappear in the morning, so I found a utility which seems to open RAR's okay. You shouldn't call them ZIPs though -- none of my unzippers like them! I must say your reaction was rather over the top. Looking through the "corrupted" INI, the only nasty parts really are (a) it loses the statement about which named joystick is which assigned letter. That's a (new) silly error which I can rectify easily, and (b) it seems to plonk the error message in the wrong place for Conditionals (CP, CR types), thus losing the rest of the line. This affected about 30 or less of your Button lines -- all of the non-conditionals were okay. That second error must have been in there for many years. Strange it's not been discovered before, but I'll fix it now. I'll also clarify the error to say "missing joystick", as in the JoyNames section. I still don't understand your statement "run out of steam". From the files you uploaded it seems that every button line referring to a now removed joystick has the same Error reported against it. Please, can you enlighten me as to what you really mean by that? I should be able to get revised versions uploaded tonight, in the wee hours! ;-) Regards Pete

Runl? Do you mean "Run1" (1 not L)? There's no "Runl" facility. Why are you trying to ask WideClient to run WideClient? In order to do that it has to be running already! It makes no sense! Pete

Not sure what you mean by "runs out of steam". You said that before. But from the little here I see that the Error notifications were never tested on conditionals. Hmmm. Interesting. Thanks. I can't find a ZIP, only a "RAR", whatever that is. I don't have a program which understands "RAR". Can you not ZIP things at all? If so, please send to petedowson@btconnect.com. Pete

That means the FSX user is "Francois", but look: The user trying to install FSUIPC4 is "Administrateur". If FSX is not installed for that user, you cannot successfully install FSUIPC4 for him either. Re-run the FSUIPC4 installer when you are logged on as the user wishing to use FSUIPC4! Regards Pete

were here some 15+ first button lines, replaced with an something like "<>" cant remember which and looked too awfull to save There's no code whatsoever in any part of FSUIPC which REPLACES a line with an error. The whole point of the Error message (together with an error number, which are indexed in the documentation) is to help folks debug their button programming. if the line was replaced that would be futile! This meachanism, to add and remove error messages at the ends of lines, has been working and provided in FSUIPC's Buttons sections for many years, and it have NEVER to my knowledge EVER replaced the parameters about which it is informing you of the error! I've done lots of tests on this. The ERROR message is APPENDED to the end of the line, and it is ignored (erased) next time the file is read if the reason for the error has been fixed. If you have any other result, please do NOT simply delete it and write letters complaining, but show me, because if it is truly occurring then as far as I can see you must have a different version of FSUIPC than one I've ever had! :-( :? :( :? :( :? will do, thx Neither of those will change the business of appending error messages to Button lines. That's a good, working mechanism, and I'm not about to mess with it after it's been working well for years, at least not without any evidence apart from your horrified say so! :-( Pete

I hope I've caught you in time! Please download and try 4.413 from the FSX Downloads Announcement. I couldn't reproduce the issue on WinXP, but decided to look at ways of improving the code in any case. I have moved the key press sending code to a separate thread, away from the main FS thread. This should make it far less susceptible to the vagaries of FS's own actions, and, particularly, those of the add-on which is actually processing the keys being pressed. The timings now of each keystroke DOWN and UP should be more precise and reliableI hope! Please try it and let me know. I could do the same in FSUIPC3, but since you don't get problems with that I'll leave well enough alone! ;-) Regards Pete

Okay, I had a chance, before I go, to do some testing. The ONLY lines it currently erases are those in the [Axes] sections. I've found a way to avert that -- look out for 3.857 or 4.412 later today. The [buttons] section lines with the Error message (this error: << ERROR 16! Line ignored >> are NOT erased, at least they aren't erased here. On the contrary, like all errors in the Buttons section, just the error message is automatically erased for you when the cause of the problem is fixed -- i.e. if it is a syntax error, when it is edited, or, as in this case, when the joystick reference (A, B, C or whatever) is again valid. The main part of each line remains (and in fact, of course, is still valid with the Error Message as that is regarded as a comment). Please tell me if you've found it different from this. It is the way errors in the Buttons section are notified, but no deletions there are EVER made -- at least never intentionally, and I can't make them erase here! Only the Axes assignments in the current version. I am fixing that now. There won't be an error message there -- that's in the JoyNames section -- but the line is ignored and retained. [LATER] Okayplease try 3.857 or 4.412, available now! Regards Pete

It is in the FS Modules folder, next to the FSUIPC.DLL, the FSUIPC.INI, the FSUIPC.KEY. It is called FSUIPC.LOG, strangely enough! You have Windows Explorer set to hide the proper filenames from you so you have to find it some other way or change the Explorer options not to hide fiel types! But before you do that, I'd still like to know what error you are getting. Please can you tell me what happens and what error you are getting? Else it is pointless showing me anything. Also, please tell me why you think it is anything at all to do with FSUIPC and what version of FSUIPC you are using! You seem to want to make me ask the same questions over and over! :-( Pete

That is most certainly a video driver problem, and it is the most common. When it happens it affects all normal Windows GDI superimposed windows, no matter from what add-in program. Regards Pete

Aha! That rings a bell. Older versions of Actigate have been a constant pain. I'm sure it was fixed in a later version. If you do a search in this Forum for "Actigate" I'm sure you'll find more notes of problems it causes in FSUIPC dialogues. I've no idea why or how -- I think it must be subclassing some of the controls. Maybe you can find an updated version of that DLL? Regards Pete

What is the message? Sorry, you seemed to have missed it again! Why is the title "Roaming problem"? What do you mean by that? Why do you think it is anything to do with FSUIPC? If you do think it is FSUIPC, why have you not shown me the FSUIPC log file and not stated the Version number as requested? Pete

But evidently not often? I say this because all the other examples you showed were fine. The only one you've shown with a problem was with an immediate (very fast, in fact) pressing of the space bar. I would, if possible, still like to see a log of an "ordinary" case where this happens, where the space bar is not pressed for, say, at least 15 seconds -- just to be absolutely clear that it could not possibly have anything to do with real keyboard action interfering with Windows playback sequences. I've taken a look at my code, and I must say it is starting to look more and more like a possible Windows bug. So far I cannot see any other way of emulating the keypress sequences than using this one, provided by Windows for that purpose. Okay. Thanks. Yes, but though I do have a Vista 64 installation, it only has FSX on it. It is my cockpit setup and I don't really want to "pollute" it with any software I'm not really using. If I cannot reproduce it with either XP or Vista32 I might try installing Vista64 on another machine, along with FS9, and see if I can reproduce it there. Thanks! And you too! Pete

Could you tell me what these other modules are, please? There have certainly been some rogue modules in the past but I don't know of any up-to-date ones which cause any conflicts. I need to know in case it happens again. I may also recognise one which you should be updating. Regards Pete

Oh dear. You forgot to tell me what message you actually get! And I've really no idea what you mean by the title "Roaming problem". Why do you think it has anything to do with FSUIPC? Just because everyone always blames FSUIPC first? None of the other information you presented is at all useful or relevant to anything FSUIPC does or needs. I'm not sure why you presented it. The only thing useful from FSUIPC is the FSUIPC Log file, from the FS Modules folderand of course the FSUIPC version number, which is ALWAYS needed. If you mean, by "until 68%", that FS is still loading and gets to 68% then crashes or hangs, then it is likely that one or other of the files it needs for that part of its loading is corrupted. What does it say it is loading at that time? That would be a clue. Regards Pete

Actually, it would have done before if it had cause to update the INI file (for instance, because you made some assignment change). All that has happened is that now it needs to match up the letters to the numbers, and automatically writes the stuff back when it sees a change, as it has in fact. Sorry, I don't understand that part? The only ERROR lines I'm creating for this are those mentioning a missing joystick in the new "JoyNames" section. Can you tell me more about what you experienced? There should have been no other changes except that plus the loss of Axis assignments in the [Axes] section((s). I'd like to be able to resolve the latter if I can figure out a way. I'm not sure how I can do it at present. This isn't directly a result of the new facilities, but certainly a possible consequence which exacerbates an existing situation. What happens is that the internal axis tables are constructed using only those entries which are to be scanned. Any producing an error (such as for a missing device) are excluded from the table -- if I don't do this, it causes internal errors when calling Windows and things become inefficient. (I hate inefficiency). Maybe I can mark them rather than eliminate them. I'll see. Anyway, I'll have to think about in when I get back -- I'm away from tonight until 29th December. I've made a note. But I need to know more about this greater problem you seem to describe. I've seen no elimination or errors in the Buttons or Calibration sections. It should only affect the Axes sections, and the errors against the assignments to missing joysticks in the JoyNames section. Regards Pete

Not really. The GAUGE file name which is used is listed in the file. If that isn't loaded then they won't work. If another aircraft uses the same gauge, then they would work (and that would be okay in any case), but it is just possible that another gauge with the same name is used, via the option to have gauge files in the Panels folders instead of in the Gauges folder, or in sub-folders of the Gauges folder. In that case the checking function built into the facility should normally stop anything untoward happening. Regards Pete

I didn't suggest that one. Yes, the Log, this time (for the FIRST time since we exchanged messages!) shows no KEYUPs being sent or received: ... but You pressed the SPACE bar about half a second after pressing that button (or flicking the toggle, whatever). That's real quick! Look: The number on the left is milliseconds. 184690 - 184113 = 577 mSecs, or 0.577 seconds. So, does it seem to you that is this the only way it happens -- when you press the real keyboard whilst the (long) key sequence from the button press is still playing? If so, i wonder if this is a problem of Windows, and possibly only of Windows. FSUIPC uses a single Windows call "SendInput" to ask it to do all this. It is effectively a "playback" facility -- as if the keystrokes were recorded and are now being played back. I'm thinking now that this facility can be interrupted, and effectively halted, by real keyboard action. You are more likely to be able to interrupt a 6 key sequence (Ctrl + Shift + Key DOWN then UP in reverse order) than a 4 key one (Ctrl or Shift, not both). So maybe that's why? Are you often pressing keys on the keyboard very quickly after using a button? Wouldn't it be better to program everything on the buttons and avoid the keyboard? Tomorrow I will see if I can reproduce it on WinXP first, then, if I have time, Vista 32. I may have to leave this till the week after Christmas though. I was worried initially that it was a new bug in the recent interim releases, but now i know if must have always been occurring and it hardly bothered anyone before, it becomes less urgent. Now that you know about it at least you can avoid it or recover from it until we find a fix -- if there is one. If it does turn out to be a Windows problem i don't know if it can be worked-around. Regards Pete

But first can you (a) confirm that, in both the logs you supplied so far you did NOT experience any Ctrl or Shift key "sticking"? Because both logs clearly show all "KEYDOWNs" matched by subsequent "KEYUPs". and (b) try and obtain a log for me which DOES reflect a real occurrence of your problem. If you have to press and release several buttons please note which was the last one before the stickiness. Because the keyboard IS the keyboard and not a long sequence of Windows messages pretending to be a keyboard! It's like the difference between a real aircraft and a simulated one. They aren't the same! ;-) It sounds like somehow, somewhere, for some reason, some of those messages are going astray. That's what I have to track down! Pete

Thanks. The log you sent shows everything worked perfectly. Every press had a coplementary release, and all in correct short times. Look, here is the log split into key presses and releases: PRESS BUTTON 6 [CTRL+SHIFT+1] 154831 Button changed: bRef=0, Joy=0, Btn=6, Pressed 154831 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 154831 SendKeyToFS(00060031=[ctl+shft+1], KEYDOWN) ctr=0 154831 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 154831 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 154831 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 154831 .. Key not programmed -- passed on to FS 154831 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 154831 .. Key not programmed -- passed on to FS 154862 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=1 154893 SendKeyToFS(00060031=[ctl+shft+1], KEYUP) ctr=0 154893 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=1 154893 KEYUP: VK=49, Waiting=0 154925 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 154925 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 154925 KEYUP: VK=17, Waiting=0 154925 KEYUP: VK=16, Waiting=0 154956 Button changed: bRef=0, Joy=0, Btn=6, Released RELEASE BUTTON 6 (not programmed) 154956 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 PRESS BUTTON 6 AGAIN (CTRL+SHIFT+1] 156516 Button changed: bRef=0, Joy=0, Btn=6, Pressed 156516 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 156516 SendKeyToFS(00060031=[ctl+shft+1], KEYDOWN) ctr=0 156516 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 156516 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 156516 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 156516 .. Key not programmed -- passed on to FS 156516 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 156516 .. Key not programmed -- passed on to FS 156563 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=1 156625 SendKeyToFS(00060031=[ctl+shft+1], KEYUP) ctr=0 156625 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=1 156625 KEYUP: VK=49, Waiting=0 156656 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 156656 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 156656 Button changed: bRef=0, Joy=0, Btn=6, Released RELEASE BUTTON 6 (not programmed) 156656 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 156656 KEYUP: VK=17, Waiting=0 156656 KEYUP: VK=16, Waiting=0 PRESS BUTTON 6 AGAIN (CTRL+SHIFT+1] 158107 Button changed: bRef=0, Joy=0, Btn=6, Pressed 158107 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 158107 SendKeyToFS(00060031=[ctl+shft+1], KEYDOWN) ctr=0 158107 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 158107 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 158107 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 158107 .. Key not programmed -- passed on to FS 158107 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 158107 .. Key not programmed -- passed on to FS 158138 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=1 158169 SendKeyToFS(00060031=[ctl+shft+1], KEYUP) ctr=0 158169 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=1 158169 KEYUP: VK=49, Waiting=0 158216 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 158216 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 158216 KEYUP: VK=17, Waiting=0 158216 KEYUP: VK=16, Waiting=0 158279 Button changed: bRef=0, Joy=0, Btn=6, Released RELEASE BUTTON 6 (not programmed) 158279 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 PRESS BUTTON 6 AGAIN (CTRL+SHIFT+1] 159589 Button changed: bRef=0, Joy=0, Btn=6, Pressed 159589 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 159589 SendKeyToFS(00060031=[ctl+shft+1], KEYDOWN) ctr=0 159589 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 159589 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 159589 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 159589 .. Key not programmed -- passed on to FS 159589 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 159589 .. Key not programmed -- passed on to FS 159620 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=1 159651 SendKeyToFS(00060031=[ctl+shft+1], KEYUP) ctr=0 159651 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=1 159651 KEYUP: VK=49, Waiting=0 159683 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 159683 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 159683 KEYUP: VK=17, Waiting=0 159683 KEYUP: VK=16, Waiting=0 159745 Button changed: bRef=0, Joy=0, Btn=6, Released RELEASE BUTTON 6 (not programmed) 159745 [buttons.Embraer 170 Cirrus new] 43=P0,6,K49,11 PRESS BUTTON 1 (CTRL+SHIFT+2] 163068 Button changed: bRef=0, Joy=109, Btn=1, Pressed 163068 [buttons.Embraer 170 Cirrus new] 31=P109,1,K50,11 163068 SendKeyToFS(00060032=[ctl+shft+2], KEYDOWN) ctr=0 163068 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 163068 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 163068 [buttons.Embraer 170 Cirrus new] 42=U109,1,K50,11 163068 JoystickValues joynum=0, dwCount=1, data[2]={0000006d 00000082} 163068 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 163068 .. Key not programmed -- passed on to FS 163068 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 163068 .. Key not programmed -- passed on to FS 163099 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=1 163099 SendKeyToFS(00060032=[ctl+shft+2], KEYUP) ctr=0 163130 Sending WM_KEYUP, Key=50 (Scan code 3), Ctr=3 163130 KEYUP: VK=50, Waiting=0 163162 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 163162 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 163162 KEYUP: VK=17, Waiting=0 163162 KEYUP: VK=16, Waiting=0 RELEASE BUTTON 1 (CTRL+SHIFT+2] 164378 Button changed: bRef=0, Joy=109, Btn=1, Released 164378 [buttons.Embraer 170 Cirrus new] 31=P109,1,K50,11 164378 [buttons.Embraer 170 Cirrus new] 42=U109,1,K50,11 164378 SendKeyToFS(00060032=[ctl+shft+2], KEYDOWN) ctr=0 164378 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 164378 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 164378 JoystickValues joynum=0, dwCount=1, data[2]={0000006d 00000080} 164378 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 164378 .. Key not programmed -- passed on to FS 164378 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 164378 .. Key not programmed -- passed on to FS 164410 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=1 164410 SendKeyToFS(00060032=[ctl+shft+2], KEYUP) ctr=0 164441 Sending WM_KEYUP, Key=50 (Scan code 3), Ctr=3 164441 KEYUP: VK=50, Waiting=0 164472 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 164472 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 164472 KEYUP: VK=17, Waiting=0 164472 KEYUP: VK=16, Waiting=0 PRESS BUTTON 1 (CTRL+SHIFT+2] 165626 Button changed: bRef=0, Joy=109, Btn=1, Pressed 165626 [buttons.Embraer 170 Cirrus new] 31=P109,1,K50,11 165642 SendKeyToFS(00060032=[ctl+shft+2], KEYDOWN) ctr=0 165642 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 165642 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 165642 [buttons.Embraer 170 Cirrus new] 42=U109,1,K50,11 165642 JoystickValues joynum=0, dwCount=1, data[2]={0000006d 00000082} 165642 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 165642 .. Key not programmed -- passed on to FS 165642 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 165642 .. Key not programmed -- passed on to FS 165673 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=1 165673 SendKeyToFS(00060032=[ctl+shft+2], KEYUP) ctr=0 165704 Sending WM_KEYUP, Key=50 (Scan code 3), Ctr=3 165704 KEYUP: VK=50, Waiting=0 165751 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 165751 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 165751 KEYUP: VK=17, Waiting=0 165767 KEYUP: VK=16, Waiting=0 RELEASE BUTTON 1 (CTRL+SHIFT+2] 167124 Button changed: bRef=0, Joy=109, Btn=1, Released 167124 [buttons.Embraer 170 Cirrus new] 31=P109,1,K50,11 167124 [buttons.Embraer 170 Cirrus new] 42=U109,1,K50,11 167124 SendKeyToFS(00060032=[ctl+shft+2], KEYDOWN) ctr=0 167124 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 167124 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 167124 JoystickValues joynum=0, dwCount=1, data[2]={0000006d 00000080} 167124 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 167124 .. Key not programmed -- passed on to FS 167124 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 167124 .. Key not programmed -- passed on to FS 167155 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=1 167155 SendKeyToFS(00060032=[ctl+shft+2], KEYUP) ctr=0 167186 Sending WM_KEYUP, Key=50 (Scan code 3), Ctr=3 167186 KEYUP: VK=50, Waiting=0 167218 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 167218 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 167218 KEYUP: VK=17, Waiting=0 167218 KEYUP: VK=16, Waiting=0 You'll see, every part is fully complete and self-contained. Surely you did not experience any Control or Shift sticking in this sequence? Have you ANY log which shows the problem actually occurring? I saw in your previous example where there was a 2-3 second delay, but apart from that everything has worked. Delays could occur because FS is busy accessing disc and so on, and normally the wanted key release does no harm. You said it also happens with 4.40, which means it probably would ALWAYS happen on your system, right back to day one. If I cannot reproduce it even once here we might be looking at some process of elimination, or checking the other add-ons on your system. BTW, I remember you said "I use FSUIPC 3.85 in FS9 in the same manner without problems". The implementation in this area in identical in 4.40 and 3.85, so it is pointing either to some weird timing difference or some sort of interference with an add-on. The code is also some 10 years old and this is the first report, so I'm worried that it is going to be a tough one to crack. I do need to be able to reproduce it, and it would be very useful to see a log which actually demonstrated the problem. Regards Pete

Doesn't the aircraft you are using obey the FS NAV light switch? I'm not sure why you have this strangekey combination. Why not assign the button to the NAV light control provided for this? ("TOGGLE NAV LIGHTS"). It is also possible, using FSUIPC Offset controls, to have a separate operation for turning them On and Off, so always ensuring the switch is synchronised. I'm afraid i've accidentally deleted your post about 4.411. I just need the Log file itself, please. Can you send it to me (Zipped) at petedowson@btconnect.com? Thanks. Can you then try 4.40 please? Pete