Pete Dowson

All the process of updating is: simply copy FSUIPC.DLL into the modules folder. There is nothing else to do. Do NOT remove or change any other FSUIPC file like the INI or KEY file. If, when you do install 3.22 correctly, you only have the main "About" page and the "Logging" page, what does it say on the About page please? Show me the Log files with 3.129 and 3.22 so I have a chance to see what is going on. Regards, Pete

Great! Glad you got it sussed! Pete

Possibly this is part of why I have problems with it. I've never liked higher level languages at all in any case. C is about as far away from the machine as I ever want to be -- C++ is too far! :) I grew up from the machine code (hardware & bits) end of things and have always programmed bottom-up, not top-down. I hate not knowing what my programs are really doing with the machine. Windows is enough of a barrier for me without adding more artificial ones. It all depends on your viewpoint, I guess. :wink: I'll have to take your word for that :D :D Regards, Pete

Ouch! When FS is running minimised most of the information which it would normally provide for panel gauges and so on is not supplied very often -- the calls it makes into FSUIPC notifying of these are completely diminished and FSUIPC switches over to timer based operation and maintains an effectively low update rate. Really? That's odd as FSUIPC won't be running at more than about 5 fps ("frames" here in terms of values being updated) whilst FS is minimised. Regards, Pete

FSUIPC is reading and setting the value of the pitch and bank for the attitude indicator on every single frame. It sounds like not so much FSUIPC not keeping up, but your program not getting enough processing time to see all the values in such busy periods. And if you are alllowing FS itself to get up to 64 fps, I am not surprised! If you are using a Pentium 4 with hyperthreading you can try assigning FS to one of the virtual processors and your program to the other. That can work. But otherwise, if you want both FS and your program to run smoothly I can only suggest that you force FS to share resources by limiting its frame rate -- Options-Settings-Display-Hardware. Set the Frame Rate Limiter to something acceptable but far more reasonable, like 20, 25 or possibly 30 fps, depending on your processor. The general method of obtaining fluid and consistent performance with FS is to set the Limiter to unlimited initially, and try to assess the average frame rate you get. Then set the limiter to something below that. This advice is from Microsoft themselves, and is for FS running alone. With other programs needing time I'd reduce the limit further. Regards, Pete

Hey, good catch! The AXIS_controls for separate engines were recent additions to FS (i.e. mean in FS2002 probably). When I first added joystick facilities the only one for Prop2 was "PROP_PITCH2_SET" (65924), so that's what FSUIPC actually processes on the 4-props page. To save re-programming lots of things when the new AXIS commands were added, I simply converted all the new ones to the equivalent old ones. Of course, my mistake, when adding the code to look for things like reverser assignments, was to place this code AFTER the conversion to old numbers, not before. I will rectify this in the very next release of FSUIPC. In the mean time there are two possible work-arounds: 1. Declare the reverser axis in the FSUIPC.INI file as number 65924 instead of 66424. You don't have to also change the FS assignment to PROP_PITCH2_SET, but if you don't you will need to remember to change back to 66424 on the next version of FSUIPC (not 3.22 which is out at present). or 2. If you aren't in need of the propeller axes in any case, simply go to the main single controls page and check the "map to 4 props" option. When the single Prop Pitch axis is mapped to the other 4 there is no conversion of the new codes to old in any case, so the problem doesn't arise. Sorry about the hassle. It's on my list, but as no one has actually asked for it until now it keeps getting pushed down. I'll get to it one day. Regards, Pete

WideServer can load programs for you, but it is probably better done with FSUIPC. It's a matter of editing the INI file -- for FSUIPC it is described in the Advanced User's Guide, or made simpler by Jose Oliveira's nice utility "FSUIPC Run Options" available from http://www.schiratti.com/dowson. On a Client PC, you add entries to the WideClient.ini file to get it to load programs. See WIDEFS.DOC. You can use "Run" or "RunReady" parameters to load immediately or load when FS is ready. But in either case there are no facilities for moving windows about. This sounds like some sort of mouse and key sequence. I'm afraid there's nothing in WideFS or FSUIPC which will do that. Doesn't the program remember where it should be and do this itself? If this is Project Magenta's PFD it certainly should do -- I have three copies running on one Client PC using three screens on a Parhelia, and each one (Captain's PFD/ND, Eicas and First Officer's ND/PFD) come up on their correct screen in the correct size, each time WideClient loads them. Regards, Pete

Do you mean you had included "PostKeys=Yes", and now you've taken it out, or the other way round? Here Notepad, for instance, doesn't work with 'PostKeys=Yes'. No problem, glad it is solved. Regards, Pete

FSUIPC can detect joystick buttons being pressed on Clients. This was part of the additional facilities in recent updates to WideFS and FSUIPC. Please peruse the release notes at the top of this Forum. If you are not using buttons (which would be preferable) then the answer is yes, provided the WideClient window on the client PC has the focus when you are pressing the keys, or, if you are sending them from a program, that you send them to the WideClient window. To make this operate you simply set "SendKeyPresses=Yes" in the client INI file, as documented in the WideFS DOC. If you are writing an interface program to do this, not actually using a keyboard as such, then you would be much better off using the "virtual buttons" facility provided in FSUIPC. See offsets 3340-3363 in the FSUIPC Programmers Guide. If you do this you can program the buttons in FSUIPC "Buttons" page to send keystrokes or controls. Regards, Pete

It works fine. Provided your aircraft is ADF2 equipped, AND it is tuned to a frequency which is being received okay, both the ID and the name are readable. You cannot read details of NDBs which aren't being received, nor can you use ADF2 on aircraft not so equipped. Note that ADF2 is only a capability with FS2004. there isn't one before FS2004. Also, none of the default aircraft have a second ADF. You have to add it. Do you have an aircraft with a second ADF? If you think everything is correct, please let me see what you have in locations 02D4, 02D6 and where in the world you are, and I'll test that specific NDB for you -- my local test area is the vicinity of EGCC and ADF2 works fine with WHI (368.5), as an example. Try there. Pete

So, basically, you are buzzing round trying to hog the processor with FS only getting a look in when you call FSUIPC_Process so that Windows can change processes? (Yes, I know it should change at timeslice intervals too, but it doesn't quite work as well as that often). Since you certain shouldn't be trying to set LLAPBH values more often than once per frame, you should match FS's frame rate -- 20 fps means one loop per 50 mSecs, so you sleep for 50 mSecs less whatever time it takes to do whatever you do. This would only be appropriate if your "loop" doing this is in a separate thread from your main Windows program. Otherwise it would be better to drive your code from something like a Windows timer (SetTimer API) so that your other duties as a Windows program are carried out properly -- stuff like processing paint messages, mouse messages etc etc. Well I don't really understand that. Most programs do reads most of the time, and very few of them involve any processing in FS or FSUIPC, unlike most writes. I don't know of any other program having such a dramatic affect on performance. Erare you using an FS module for this? If so you MUST use the module interface, the other way is very inefficient from within the same process. Regards, Pete

Further to my last (rather technical) message, once you have got things working with NotePad (for without it working there I really don't see how it will work with anything else), if your ND still has difficulties with the Shifted characters, please try the attached interim version of WideClient (6.223). All I've done is made that Client thread sleep for a millisecond before returning each step of the key sequence. This actually works out usually to 5-15 milliseconds because other threads and programs in the system grab what they can. There are facilities in the Journal Playback feature in Windows to impose delays in the playback, but it seems these actually stop the whole system for the period specified, which seems a bit daft to me! I don't see why this slowing down of the sequences will help, but let's hope so. If not then I'm afraid there's nothing else I can really do. You'd need to get in touch with the author and see why his program does what it is doing. Please let me know how you get on, Regards, Pete WideClient6223.zip

You must have something wrong, then. I've run it with these parameters in the [user] section of WideClient.ini: [user] Run1=Notepad.exe Close1=Yes ActionKeys=Yes KeySend1=65,8,Run1 KeySend2=65,9,Run1 This makes WideClient load up Notepad, just as it should be loading up your ND program. The assigned KeySend1 button on FS then consistently types an 'a' in Notepad, and KeySend2 types an 'A'. I've tested this with Windows XP and Windows 98SE. If your Notepad is not seing the keypresses you have something wrong for sure. Get that working first, then retry your ND. Checking the keyboard message sequences produced using Microsoft's Spy++ program, I see: 001003B2 P WM_KEYDOWN nVirtKey:'A' 001003B2 P WM_CHAR chCharCode:'a' (97) 001003B2 P WM_KEYUP nVirtKey:'A' for the lower case 'a', which is correct, and: 001003B2 P WM_KEYDOWN nVirtKey:VK_SHIFT 001003B2 P WM_KEYDOWN nVirtKey:'A' 001003B2 P WM_CHAR chCharCode:'A' (65) 001003B2 P WM_KEYUP nVirtKey:'A' 001003B2 P WM_KEYUP nVirtKey:VK_SHIFT for the upper case. The order is always 100% consistent in these, and you'll note that Windows has correctly generated the CHAR messages with the 'a' ASCII code and 'A' ASCII codes, respectively. I really don't know how that might happen. The message sequences being generated by WideClient are done by the Windows Journal Playback facilities. If you set "Log=DebugAll" in the INI file you'll get the messages saying what it is doing. For example, for my KeySend1 above I get: (Note, this is probably more for Bob's benefit that yours. It is a bit technical). 4532 Action request for "Run1", KeySend0 - looking for Window<1:1> 4532Okay, found, sending 0 request <1:1> 4532 Setting hook for KeyHook action 1 <1:1> 4547 Hook set okay <1:1> 4547 Checked KeySend[5]=1, DoneOne=-1 <1:1> 4547 Actioncall for HC_GETNEXT<0:1> 4547 [wnd=140690, msg=256, paramL=0041, paramH=001E]done <0:1> 4547 Actioncall for HC_GETNEXT<0:0> 4547 [wnd=140690, msg=256, paramL=0041, paramH=001E]done <0:0> 4547 Actioncall for HC_SKIP<0:0> 4547done HC_SKIP <0:0> 4547 Actioncall for HC_GETNEXT<0:0> 4547 [wnd=140690, msg=257, paramL=0041, paramH=001E]done <0:0> 4547 Actioncall for HC_SKIP<0:0> 4547done HC_SKIP <0:0> 4547 Unhooking now <0:0> The "HC_GETNEXT's are where Windows is asking for the next action. Message 256 is the "KEYDOWN", 257 is "KEYUP", and, in this case, the Key is hex 41 (65 decimal). For the KeySend2 there are more steps: 16282 Action request for "Run1", KeySend1 - looking for Window<1:1> 16282Okay, found, sending 1 request <1:1> 16282 Setting hook for KeyHook action 2 <1:1> 16282 Hook set okay <1:1> 16282 Checked KeySend[6]=2, DoneOne=-1 <1:1> 16282 Actioncall for HC_GETNEXT<0:1> 16282 [wnd=140690, msg=256, paramL=0010, paramH=002A]done <0:1> 16282 Actioncall for HC_GETNEXT<0:1> 16282 [wnd=140690, msg=256, paramL=0010, paramH=002A]done <0:1> 16282 Actioncall for HC_SKIP<0:1> 16282done HC_SKIP <0:1> 16282 Actioncall for HC_GETNEXT<0:1> 16282 [wnd=140690, msg=256, paramL=0041, paramH=001E]done <0:1> 16282 Actioncall for HC_SKIP<0:1> 16282done HC_SKIP <0:1> 16282 Actioncall for HC_GETNEXT<0:1> 16282 [wnd=140690, msg=257, paramL=0041, paramH=001E]done <0:1> 16282 Actioncall for HC_SKIP<0:1> 16282done HC_SKIP <0:1> 16282 Actioncall for HC_GETNEXT<0:1> 16282 [wnd=140690, msg=257, paramL=0010, paramH=002A]done <0:1> 16282 Actioncall for HC_SKIP<0:1> 16282done HC_SKIP <0:1> 16282 Unhooking now <0:1> This shows the extra steps for the Shift being pressed before the 'a' and being released again at the end. The number of the left in each line is the elapsed time since WideClient started, in milliseconds. The fact that it doesn't change throughout each example does mean that the whole sequence is over and done with within a millisecond. Maybe this is a factor, though I don't know how -- if the ND program is processing the individual KEYDOWN/KEYUP messages then is should still see them in the order they are generated -- they don't overtake each other in Windows' queues. If the program interprets the WM_CHAR values instead, you can see these are being generated correctly by Windows too. One other thing: you aren't setting "PostKeys=Yes" in WideClient.ini are you? Don't do that if you are using "Run" or "RunReady" to load the program. You need class names for reliable posting. Regards Pete

Don't read it into an array of characters. The 4 byte length is simply the length of the number -- it is 32 bits (4 x 8 = 32), i.e. a standard Integer. Just read it into an integer. The you can copy it into a double or whatever afterwards and perform the conversion to degrees. Pete

I think mouse movement tends to make Windows give more time to the process which should be processing it, same as when you use the keyboard. So what is probably happening is that your program is stealing too much processor time. You don't say how you are controlling the loop -- is it on a Timer, or do you use "Sleep()" to release the processor occasionally? As to why this is specifically related to the read of 088C I've no idea -- there's no particular action taken on that, the throttle values are provided even if no one reads them. If anything takes any time at all it is going to be the Write, not the Read -- you look to be changing the aircraft pitch forcibly, on every loop? Why? Normally pitch is controlled by elevator or elevator trim. You are effectively slewing the aircraft, against aerodynamic forces, on every loop. I wouldn't be surprised if that did slow things down a bit. Regards, Pete

During a flight?! :shock: This message is only in part of FSUIPC initialisation code, code which is called when FS is first loaded and never ever seen again. It is a complete disaster if that code is being re-run. For the message to appear during a flight, something is getting badly corrupted inside FS. Is WidevieW the only other additional module or internal add-on you are using? Is it possible, as part of a process of elimination, to see if you don't get this problem when WidevieW is removed? Alternatively, possibly add-on aircraft? Try a default aircraft with default panel, just as a test? Of course. If there were really a duplicate you would get this message during FS loading, not part way through a flight. Something is going wild inside FS and jumping into initialisation code. The problem now is to determine what component could be doing this. One other thing you could try is removing both FSUIPC.DLL and the WidevieW DLL from the Modules folder, then copying them back in a different order. Since you don't know what order they are in now, try this twice, with different orders. The order in which the modules occur in the directory file affects the order in which FS loads them. No, not at all. I think FSUI stands for "FS User Interface". It is a standard part of Microsoft Flight Simulator. Regards, Pete

Sorry, I don't know why that should be. The keys are passed on separately to Windows as 'shift' KeyDown, 'a' KeyDown, 'a' KeyUp, 'Shift' KeyUp". Such a sequence of messages through Windows also generates a "WM_CHAR" message which would derive the captital 'A'. There is no Windows keycode for capitals, only the separate operations for shift and so on. Maybe it is the way the program is written, something to do with the way it is processing the messages. But I really can't see how it could get it wrong. Can you try, temporarily, substituting, say, Notepad.exe for the program so you can see the characters actually being typed on screen? Another idea would be to see if you can re-assign the key usage in the target program so that it doesn't need to differentiate between A and a in the first place. Or are the assignments fixed? Finally, is the author still active? Maybe he could give some advice on this? Regards, Pete

Just an afterthought. Is this possibly the same Dash 8 as discussed in the thread "FSUIPC 3.22 won't allow Fanda Dash 8"? If so, please check that thread -- the answer may well be there already. Regards, Pete

This explains it all. The Dash8All.GAU has an error in its code. In order to gain access to FSUIPC it is correctly writing the correct Key details to 8001 as shown here. And they are correct, I have checked them. However, unfortunately, it is actually doing a pile of data reads BEFORE it supplies the Key -- it is those which fail, and it is those which give rise to the message. AFTER it has provided the Key it is working fine, so in fact you can continue. But the error will recurr each time you freshly run this Gauge. This problem may not have been so noticeable before FSUIPC 3.22 because its reporting of Key errors was not so good before. Please write to the author and tell him this -- by all means copy this message if you like. It needs correcting. However, in the meantime you could register the Gauge manually. To do so, click on the "Register an Application Program" button in the first FSUIPC options page, and enter the name and key, thus: Dash8All.gau ZUHR AX41 CHY5 Take care to get these details correct -- cut and paste from here is best. Regards, Pete

By "latest" it probably meant whatever version was current at that time. "Latest" is a very unfortinate choice of words as it is completely relative. It may want any version after some specific number, 3.xxx. This would be the case, for example, it is was using some item which was added in that specific version. "Error-9"? What's that please? I don't have any "error 9" messages in FSUIPC. An unregistered program won't stop FS from working "fine" in any case. The unregistered component will simply not function correctly, and its attempts to do so will slow FS down a little whilst FSUIPC continually tried to check its credentials. The difference between FSUIPC 3.22 and earlier versions is that 3.22 is better at reporting the problem so that you are alert to it. Before that the component which was failing to get correct FSUIPC access would simply not work, and, worse, would certainly slow FS down somewhat. I received many queries about this sort of thing, so much so that I improved the reporting in 3.22 with the result you see. In other words, the difference is only that you know about it with 3.22. Nothing is stopped, you can continue, but at least you know something isn't right. That depends upon what you are trying to do. Have you purchased a user key from SimMarket or someplace? If so all the instructions are in the email from them. If you are trying to just register a gauge or module or program instead, you need the program, gauge or module name and the Key to go with it. At least with FSUIPC 3.22 you can get the name from the Log file. If it is a freeware gauge or module with a Key listed in the Freeware Keys thread (near the top of this Forum), then you are all set. If not then you will need to either ask the author for a Key, or, if you can definitely confirm it is freeware, and the author is unlikely to object, you can apply for a Key -- giving all the details you can. Please see the freeware keys thread. Regards, Pete

It evidently was Jeppesen (surprise), though PFC was involved as Mr. "flypfc" confirms (and he should know! :wink: ) Standard 15-pin joystick connections (on motherboards or sound cards) only support 4 on/off switches and 4 analogue inputs , but with a specific impedence range (around 50 kOhm I think). Me thinks this wouldn't be sufficient? For it to be recognised as a USB device some additional circuitry would undoubtedly be needed. Sorry, I cannot advise on that. Hardware, especially USB, is not an area I am an authority on, far from it. You should seek advice from one of the hardware or cockpit builder's forums. Well if you do, and you know how to do it, you seem to be in a good position. Personally, being a programmer not an engineer, I'd tackle it from the software end. I'd connect it up to a COM port, link it to something like the Windows hyperterminal application, then use it or the free program "portmon" (intercepts and logs port data) to see what happens for each switch pressed or turned, and so on. (portmon is from http://www.systeminternals.com). Then it's 'merely' a matter of writing a matching driver, interfacing to FSUIPC (for which you'll need the FSUIPC SDK, available from http://www.schiratti.com/dowson). Of course, the implementers may just possibly have 'protected' their protocol by having the thing not respond until sent some initialisation sequence. If this is the case, then my way is not so easy. :wink: Anyway, if you aren't a programmer then the hardware solution you suggest may be a lot easier. Regards, Pete

Two things here. First there is no complaint necessarily that I can see about Active Radar. The line which I think you are interpreting this way may just be a result of another illegal attempt by "Dash8All.GAU". The order in which things are happening is most likely rather confusing. Second, the reason 3.22 logs and reports these is because the logging and reporting is a lot better in 3.22. Previously many such illegal access attempts may have gone unreported, and you'd have simply had a non-working module or gauge wasting quite a lot of FS resources. Both of the two modules involved here have certainly had valid Keys issued for them, but whether they are automatically using them, or you are entering the Keys manually I don't know, and it is not possible to tell from this log whether they are correct. If you would show me the [Programs] section (only) of the FSUIPC.KEY file, and also run the log again but with IPC Write logging enabled, I could try to work out what is actually wrong. Regards, Pete

If it comes with a driver for FS, whether using FSUIPC or not, then, yes. But otherwise it sounds very doubtful. Do you know who actually makes the device? It won't be Jeppesen. It may be PFC but via Elite, in which case it will use the proprietary Elite protocol -- Elite may have a suitable driver. If you can find the maker, you can either see if they do have a driver, or at least get hold of the protocol used and either program the driver yourself or get someone else to do it (and please don't look my way on the latter! :) ). Regards, Pete

Yes i too use FSI, but it is for reading, i need writing :( It will do both! How do you think I have managed all these years! :wink: Have you not investigated it more thoroughly? Pelle did document it quite well, did you not check? Just load it up, and try pressing the button marked "..." at the right end of each field name. Select the Buffers tab, then see how you can read and write in any of the supported sizes and formats, in hex or decimal. Regards, Pete

I don't know of such a small one -- I use FSInterrogate, which is great for anything except character strings and 32-bit floats. Everything else it handles well. Pelle was going to add extra data types long ago, but I fear he got caught up with earning a living instead, and never managed to get back to it. Of course, I added the reverse -- simply reading and displaying data, given address and data type -- this is the Monitor facility in FSUIPC's Logging page. Writing data is possible using FSUIPC's "Offset ..." series of controls, of course, but the parameter (data) in each can has to be specified in the parameter field of the assigned control, which isn't as flexible as perhaps you want -- though I've found it useful to test out facilities with a number of "sample" values, and assignments to lots of TAB+x key combinations. Regards, Pete