Pete Dowson

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

One other thing to try, please. Assuming you've not tested this yet with the official user release at present (4.40), do you think you could try that and let me know? I need to know if this problem might be due to recent changes (4.401-4.409) or whether they existed before. In order to get the 4.40 installer to install 4.40 you'll need to remove the FSUIPC4.DLL from the FSX modules folder, as it refuses to replace a later version. After that, could you also try 4.411 (now in the FSX Downloads Announcement above), as there are some other changes in that. Thanks. If I cannot resolve this tomorrow (Thursday) it is going to have to await my return on the 29th. Regards Pete

I assumed it was related to the CoPilot DLL problem, which was known, as the originator didn't come back after that was mentioned. I'm going to have to think about how to narrow this down more when I return on the 29th. Sorry. Regards Pete

I thought you said you were using a P8, push buttons, not a T8 with toggle switches? You have the same key combination sent when the button is pressed AND when it released. Why is that? It is most unusual to do that with a button and keypresses. It would make sense with a toggle switch. The sequence sent when it was pressed is this: Everything there is fine, except that the KEYDOWN for key 49, though it was sent, was not received by FSUIPC. I assume it's been detected earlier in the chain by the add-on you intended it for. On the release: which is fine, as far as it goesbut there appears to be a delay then before the button releases are sent. In fact, just after the next button is pressed: The emboldened entries are those for the key releases from the previous press. Then we get the releases from the second pressed button: which are fine, then the release action on the same button: and that looks perfect. So, in this example at least, there appear to be no "stuck keys" except in the few seconds between releasing the first button and pressing the second, when it rectified itself. I'm really not sure how that delay arises. Would the key releases have occurred if you had not pressed another GoFlight button? I'm afraid your log, whilst showing that there might be a problem, doesn't seem to show THE problem. It is really a shame you pressed the second button. Now I have a better idea of what you are doing I will try to reproduce this here. Meanwhile, could you try actually reproducing the stuck keys case with them actually stuck, not apparently cleared by another button press. And could you clarify whether you are using buttons (as on a P8) or toggles (as on a T8)? Regards Pete

Well FSUIPC's log did confirm that it added its entry. It can do no more than that. The rest is up to SimConnect. Perhaps you've discovered a new SimConnect bug? A SimConnect log may prove useful -- see the FSX Help announcement above for instructions on how to produce one of those. I'm also wondering whether something Squawkbox is doing is getting the menu entry removed, somehow. It is installing / running before FSUIPC. Maybe it's causing SimConnect to reach some menu limit, or other. Could you try temporarily disabling the Squawkbox items in the DLL.XML file -- change their False entries to True. If that works, then try getting FSUIPC loaded first -- cut the FSUIPC block from the end of the DLL.XML file and place it at the beginning. The FSUIPC block is this: FSUIPC 4 False Modules\FSUIPC4.dll Just move that section to just before the first line in the file. Best make a safe copy of the DLL.XML file first. Neither FSUIPC nor the Installer ever delete any files. So did you? Haven't you run version 4.411 yet? If you have then there will be a LOG file, and the timestamp on the INI file will have been updated. If FSUIPC is now not being run then it will not be able to create or update either. Regards Pete

Okay. A few points there: That version is no longer supported. The current version is 4.40. There is an interim update in the Announcements here, too - 4.411, but you need to install 4.40 first. If you already purchased it, why didn't you registered when prompted to during installation? You will have to re-run the installer in any case when you get around to registering. There is nothing wrong here. It has connected to Simconnect and it has added "FSUIPC" to the AddOns menu. Where are you looking? The AddOns menu entry occurs in the Menu bar, obtained when you press and hold the ALT key. It is in the menu, not in any dialogues or anything. SimConnect is part of FSX and it is the part responsible for creating that entry, and the log certainly confirms it has done so. Regards Pete

It's actually "Dowson", not "Dawson", but you can call me Pete. I never understand why folks don't download and install first, THEN purchase? ;-) FSUIPC should install and produce a menu whether or not it is registered -- for many purposes registration isn't necessary. I see you have Squawkbox 4 installed. Doesn't that need any Add-Ons menu entries? You included the FSX.CFG and FSUIPC4.INI files, which aren't relevant. I don't need those. The FSUIPC4 install log is good, and the fact that the FSUIPC4.INI file is produced means that SimConnect is actually running it. So, the answer is most likely to be within the FSUIPC4.LOG file, which is the only thing needed which you omitted. Regards Pete