Pete Dowson

Possibly it's using the handle from the ext.run, because that may be getting the initial Window handle, not the eventual one. Though I'm not sure about that. might be worth using GetHandle after your delay instead. That's very odd as the code in Wideclient is identical to that in FSUIPC. All of the Lua stuff is, except where parts are only applicable to one or the other. Oh, you don't mean the Lua then!? The KeySend for keypresses has a variety of methods applicable, according to parameters. Please see the WideFS technical document. Pete

The current one, of ocurse. 5.124. Please refer to the Download Links subforum for information about latest versions and interim updates on all my software. Pete

Assuming you installed the "most current" FSUIPC, the only one currently supported, then the "most current" documentation is, as the Installation instructions acually told you, in the FSUIPC Documents subfolder in your P3D Modules folder, where FSUIPC itslef is installed. Sorry, no. I don't have that aircraft. Perhaps their own forum is a good place to ask? Pete

The only one in the "np" file is: ext.state(myHandle,EXT_MAX) ---- does NOT work Maybe it needs the focus BEFORE it accepts the "Maximise" message, though it shouldn't. Anyway, does it "not work" in both cases -- when Notepad is already running as well as when you just loaded it a few lines earlier? Maybe you need that sleep beforehand too, to give it time to be established first. In the other one you found that the sendkeys isn't working either. This may be a result of the program, FS-FlightControl, not processing keys in the way that the Lua functions send them. Quite a few programs process keyboards directly rather than use the standard Window messages. However, the main reason looks to be this: ext.focus(myHandle) -- not working If it doesn't have the focus it probably won't process the keypresses in any case. I use FS-FlightControl, and when started it takes a long time before it is actually ready. Assuming there is no update it takes over 10 seconds here even on a fast system. There's a couple of seconds before it loads its starting window, which isn't one which will accept any messages in any case. Then another 8 seconds at least before it reaches its normal screen. BTW why are you using "ext.run" in the one case but "ext.shell" in the other? Note the description of the ext.state function: "This does its level best to make the identified program the current foreground program, receiving keystrokes and mouse clicks. The program must be one started by ext.run or ext.runif." I don't think it can get the proper Window handle for Shelled programs -- shell also does things like run batch files and execute other system functions. it isn't specifically program oriented. Pete

Have you looked at the FSUIPC User Guide? Best to just disable controllers in P3D. No need to remove assignments. If you don't then there's a possibility of them all being re-assigned automatically if P3D should ever think the device is "new" (i.e. re-connected). And the button assignments will conflict. Sorry, this is rather confused. YOU don't "load profiles". They are automatically loaded when you load the relevant aircraft. That's rather the main point. And what do yuo mean by "get this set"? The user guide is the reference for all the standard things, especially button and axis assignment, and calibration. anbd there ARE actually numbered steps for proper calibration. But what didi you say? You had an already prepared profile? How did you make that, then? Most toe brake pedals need reversing. There's a REV checkbox on the calibration section, and this needs doing before calibration. Please do use the documentation provided which tells you these things. They are n properly calibrated then. Unless you set a slope they move from minimum to maximum over the range you actually calibrate for those input values. That is the main point after all. You can then select a slope for less effect in the centre, but you still need to reach the maximum with full deflection of the axes. If they aren't smooth then, assuming your device isn't jittering, you've not actually disabled controllers in P3D and its settings are conflicting. Pete

Yes. The problem will probably be in the Gauge code, which is probably written and compiled in 32-bit mode. You cannot run 32-bit code in a 64-bit process. Pete

If you mean the List of FSX and P3D controls, then you won't find it there. It is one of the many FSUIPC added on controls, not an FS control. Those still occur in the drop-down assignments list, which is the easiest to use (those are in alhpabetic order too). FSUIPC controls are listed in numerical order only in the Advanced Users guide, in the section listed in the contents as "Additional "FS" Controls added by FSUIPC4". There you'll find a pair of them very early on, both starting with the word "Traffic". There are also three more, to change the FS sliders for traffic (Airline, GA, Shipping), later. Just search for "traffic", and two ZAP controls. Pete

FSUIPC assignments are all stored in the FSUIPC4.INI, only with Profile assignments separate in the "Profiles" subfolder IF "UseProfiles=Files" is set (not usually worth doing unless you have many and large profiles making the INI file rather unwieldy to check and manage). They cannot be "lost" except by the file getting corrupted or deleted. Your recognition of this states "doesn't report this axis as assigned .. " or "FSUIPC GUI doesn't report this button as assigned ...". Both "suddenly" -- like in mid-flight, or when? And by "doesn't report" do you mean it detects it/them in the Assignments tabs, but lists nothing as assigned, or doesn't register them? There's a world of difference! Version 4.961 is over a year old and has been superseded many times. I cannot support old versions! Please ALWAYS check you are using the only supported version, the current one, before asking for support. The current version is 4.974. If you still get problems with 4.974, try without EZDOK. Some old versions are known to create other problems in FS, not just many crashes like the example you give. I think you should keep that program up to date as well. The author does correct bugs and it works well for most users. Pete

FSUIPC has no influence on those. They should really be saved by P3D in the Flights (Scenario) files. There is a facility to save and restore their positions in FSUIPC. This was defaulted "on" but is now defaulted "off," because folks were losing these windows when switching between Windowed and full screen mode or vice versa. The facility only suits those always running with the same screen state and size. With a registered install of FSUIPC you can enable this facility by changing the RestoreSimcWindows parameter to Yes, or just use the option on the left side of the "Miscellaneous" options tab. Pete

Don't forget the wxstationlist.bin file. The log is different this time. Looks like it ran in flight mode for 20 seconds before you went to the menus. You said you had no other add-ons. Which 767 is that you are loading? Isn't that an add-on? Is it fully P3D4 compatible? Otherwise I think there's something else corrupted in your P3D4 installation. Run the Windows "Event Viewer", see what crash reports are listed for P3D4. You need the information from those, particularly the module name and offset within it. Also please rename your FSUIPC5.INI file (in the Modules folder) so that a new default one is generated, and try again. Pete

I think there's either a corrupt .wx file (in your P3D4 Documents folder) or your wxstationlist.bin file is corrupted. You can delete the latter (it's in your user AppData\Roaming P3D4 folder) -- P3D will make another. You can also dispense with the .WX files if you use a weather add-on program. Else try just moving them all out of that folder as a test. Pete

Thanks for the fast feedback. I shall release this version now. Pete

I found and fixed the problem in WideClient. Your test program works okay now. Download WideClient7140.zip Please confirm. I won't release it generally yet. Pete

I've moved all the colour initialisations to a separate function first called as soon as the Window is created, but without waiting to process any Windows messages. Before it was only performed on the Windows "Size" message, which is always actually received when the window is created but I suspect there's something else going on there as well. It now seems to work 100% of the time here. Please do try it: WideClient7140.zip I've also added a new parameter for the [ButtonScreen] section of the INI. It will remain undocumneted for now, because it really isn't wanted usually. It is ShowAlways=Yes This makes the button screen draw as soon as you start WideClient, rather than wait for the connection to the Sim as it usually does. Please let me know how you get on. Pete

After many experiments, Ive come to the conclusion that the bad drawing is somehow a result of the user colour settings. I can't get it to go wrong if I leave them all to default (it then just doesn't look how i want it to look). So, just as a test could you try with these lines removed (or commented out by a ; in front): Colour0=170,170,170 // Gris (Couleur boutons par défaut) Colour1=0,166,255 // Bleu ciel Colour2=0,255,72 // Vert pour bouton Toggle OFF Colour3=255,217,0 // Jaune pour bouton Toggle ON Colour4=221,250,182 Colour5=235,250,160 Colour6=238,183,172 Colour7=0,211,253 // Couleur des titres Colour8=255,15,15 // Rouge Colour9=0,0,0 // Noir

Okay, so do that. In the example you sent me you were getting another handle in the 2nd plug-in, using ext.gethandle. Why do that? Just use the one in the global. The name you save a global variable as is not relevant to anything. You can call it "elephant" or, more sensibly, "myhandle". Where is your thinking that the name is important? It is only a label. An examples? There's nothing to it! In one plug-in, ipc.set("elephant", handle) in the other, started later or from within the first, handle = ipc.get("elephant") Pete

I'll test it here. It works okay with all my own tests. Pete

Sorry, I don't quite know what you mean. Do you want to log these to your own file, or to a display, or what? Those values are all contained in FSUIPC "Offsets" -- see the Offsets list supplied in your FSUIPC Documents folder. You can use the monitoring facilities in the Logging Tab of FSUIPC to log up to 4 different vslues, to the FSUIPC log file and/or a display on screen. There is a Lua plug-in supplied in the Lua examples ZIP in your FSUIPC Documents folder too. "record to csv.lua". That logs the time, lat, lon, alt(ft), pitch, bank, hdgT, hdgM, vs, ias, tas, gs and mach, all to a "csv" file 20 times per second. It is intended as an example for you to adapt as you need. "csv" files can be displayed as a spreadsheet in Excel and other such programs. You mean the SimConnect names for them? Are you writing your own SimConnect interfacing program then, not using FSUIPC for this? You'll need the P3D SDK reference material, on-line only at the L-M website. Pete

The handle is generated in the thread. It is an index to a table of actual Window handles, it isn't the actual Window handle. The scripts do different things. One gets a handle from ext.run, the other by finding a Window with a given name or title. These aren't compared to see if they are the same thing. Each will use a slot in the handle table, that's all. Looking at your code, you aren't comparing those. And you are using the same name for one of your handles as for the Global Name. That is confusing things for you to start with. But your code contains: FC_window = ext.gethandle("notepad.exe") x2 = FC_window ----------------------------------------------------------------------------- x = ipc.get("FC_window") -- get Global Variable "FC_window" ---------------------------------------------------------------------------- ---- WHY ARE THE HANDLES X and X2 DIFFERENT ??????????????? ------ and the reason for that is ipc.gethandle is getting you a local handle, not the global one obtained by the ext.run in the other thread. Why would you think they'd be the same? If you are going to get a local handle, use that. Why mess with global ones? (BTW there may be more than one copy on Notepad.exe running at the same time. I don't think there's anything stopping it) Pete

A "private message"? Where did you send it to? If it is more than 1 it is working! Are you going to try to fill the memory defined for them, a 1,000 requests or so? (32kb total space)? I don't see the point of that. I already have programs with do many hundreds of reads at a time (FSInterrogate is one). I just didn't have a 64-bit one. I have adapted UIPCHello64 to do several reads and that works fine with this version, so I'm reasonably confident. BTW, I changed WideClient again, to try to deal with a button screen draw problem, so it would be better if you used the current one tomorrow -- WideClient7130.zip Pete

No, not on the RP48. For a picture of the RP48 check the Goflight website. I'm sure they have pictures of all their units there. So may have dual concentric ones, I don't know. The fast/slow decoding will be done in their firmware, not by hardware, much like my method via the Rotaries lua plug-in. Pete

You added your post to a very old thread, you are lucky I saw it! Please, next time, start a new thread of your own rather than append to such an old one. ============================================================ What the the symptoms of this "not operate"? As you see from the log: 787656 Using "C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\GFDEV64.DLL", version 2.2.8.0 787656 GoFlight GFMCPPRO detected: 1 device 787656 GoFlight GFEFIS detected: 1 device they are both detected okay, and so are operating via GFDev64, no problem. The displays on the MCP are not driven this way. You either need to use GoFlight's own software, or program a Lua plug-in to handle the disaplys. FSUIPC natively only handles the buttons, switches and dial inputs, which you'd need to assign as needed. Pete

Okay. Please try WideClient7120.zip Let me know how you get on. Note that if you use ButtonScreen this version will "flicker" (actually minimize and restore) when it first connects. This seems to be needed these days to get all the buttons painted correctly. Pete

I've found the error and I think it is working well now, but I couldn't use your programs to test as you seem to have password protected the ZIPs. I'll upload a revised WideClient.EXE shortly for you to try yourself. If you still have a problem I'll need the password(s). Pete

Okay. It is forgotten ... but now you know where to look for future updates! ;-) Pete