Pete Dowson

You can only have one "Sentences" parameter. AV400 or the NMEA stuff. You need to delete the one you don't need. Something doesn't make sense there. If you have GPSout connecting to your LapTop via COM5 which is a USB/Serial adapter, then why run MixW? You don't want that. Where is the GPS connected? Where is FS + GPSout? Pete

That's the GoFlight module for the GF MCP. I'm pretty sure that none of the GF modules use FSUIPC, so that's strange. Maybe it's a later one, possibly to support the new 737-type MCP which GF have released? If GF have added FSUIPC access they certainly haven't asked for any access keys, and, in fact, an access key cannot work for a DLL using the external program entry methods. Please report this to GF support. If you have the older MCP (the double height one) then you should be okay with the older DLL. If you cannot find it I may be able to find one here. Regards, Pete

Something (a Gauge or add-in DLL) is using FSUIPC incorrectly (it is actually programmed like an external application, which will cause problems when used inside FS), and your FSUIPC is not user registered. Unfortunately, because it is accessing FSUIPC as if it is a separate process, to FSUIPC it looks like FS9 itself (as that is its process). This makes it impossible for anyone to deduce what GAU or DLL file it is from the Log. The only way you can find it is backtrack on what you've installed recently until you locate what it is causing the problem. When you find it I suggest you remove it and don't use it again. The fact that it happens within the first couple of seconds, possibly even before the default aircraft stuff has been loaded, suggests that it is a DLL. Check your FS Modules folder for recently added non-FS DLLs. That tends to reinforce my deduction that it is a DLL. Regards, Pete

I shouldn't think so -- WideFS is only useful on Networks and multiple PCs in any case, and only panel projects like Project Magenta really need multiple PCs. FS's own aircraft panels cannot be split from the FS PC in any case. In order to just use those aircraft you don't need "all the features FSUIPC can offer". I recommend you download FSUIPC.ZIP from http://www.schiratti.com/dowson first, and browse through the User Documentation you'll find inside to make sure you have a use for things first. Most user facilities in FSUIPC are totally unrelated to specific panels. You don't want to spend money then regret it. Neither. You can download it from the place I just mentioned, or even here (see the Interim Versions announcement near the top). Products that actually need FSUIPC, like the PMDG aircraft, ship with a version too, but it is invariably out of date. ;-) Regards, Pete

Most of the stuff on your KeySend lines is now completely redundant. The RunReady parameter is INSTEAD of the Class and Window name. You don't use both, and the last two will be ignored in any case. They should read, simply: KeySend1=34,8,RunReady2 ;Page Down KeySend2=33,8,RunReady2 ;Page Up KeySend10=9,8,RunReady3 ;Tab Regards, Pete

Further to my last reply, it occurs to me that you may have actually missed the easiest way to direct key strokes from WideClient to selected programs. Just get WideClient to actually run the programs for you (with RunN or, usually better, RunReadyN parameters), and close them too (CloseN and CloseReadyN), and then use the "RunN" or "RunReadyN" parameters on the ends of the usual KeySend lines. This facility is actually the first to be described in the Directing Keystrokes more precisely section, before CLASS names. Pete

Project Magenta? But you don't have any use for WideFS on a single PC. WideFS works across a Network, only. Do you mean you are now using 2 PCs whereas previously 3? I'll have to assume that ... What changes do you want to make to the display with key strokes? If they are all standard cockpit things like those operated by switches on the EFIC panel (range, mode, traffic, WX, Arc mode, etc) then you are better off using the internal FSUIPC-driven commands in any case, just like real hardware EFIS panels would. Well, that's really a question for PM support, for sure, but I don't know if Enrico still allows the Class names to be set. However, it is no problem as you can use the Window title to select it as well, and there is certainly still a "WindowName" parameter in the INI file. Didn't you look? Can you let me know if you find out from PM support that the class names are no longer changeable? That would be a shame, and I will need to amend the WideFS documentation. Regards, Pete

No, it won't be FSUIPC. I know that is always the first thing to be blamed for everything :roll: , but it really doesn't know anything about panel parts, and that's all the kneeboard is, and it doesn't deal in graphics at all. Sounds like you have something else going on there, maybe a corrupted gauge bitmap. The only option in FSUIPC even looking at FS windows as such is the one on the Technical (or Miscellaneous) page to stop you moving or resizing them accidentally. Even that has nothing to do with their appearance or disappearance. Regards, Pete

It's just a label. If you cannot use labels can you refer to the places to jump to or call by relative position, eg $ = here or * = here? If the assembler part of Delphi can't support labels or relative address then it is useless it acccepting the call in the first place. See if you can do call $ or similar, but make sure it calls the next instruction, e.g. *+2 or whatever. There are other ways of doing what I'm doing here, but I suspect not without needing changes to FSUIPC itself to make it check things differently. Since WM_USER is 0x0400, which is 1024 in decimal, you can either define WM_IPCTHREADACCESS to be 1154 (i.e. 1024 + 130) or simply use 1154 directly. Where does any of that come from? There is no RegisterWindowMessage needs in the module users access. -- you have the code, you should know that already! None of that registered message, atoms, mapped memory file stuff is used at all in FS DLLs and Gauges. Why are you still messing with the external library code? Regards Pete

PFC DLL Version 1.996 works a bit better than 1.921 -- you can get it from the "interim versions" announcement at the top of this forum. There are extensive facilities in PFC.DLL for using both COM1 and COM2 interchangeably. These were first in place in the days when FS only supported COM1. They were kept for use with programs like Radar Contact and on-line services such as AVSIM which use COM1 exclusively -- it allows 4 frequencies all to be preset and switchable to the active COM1 radio. The same facilities are used on the Jetliner console, which only sports a single COM radio, to allow use of both COM1 and COM2 in FS. It sounds like you have enabled these facilities, and possibly inadvertently activated a swap. I'm not sure why you've not found the details, but they are the first to be extensively described in the Avionics Options section of the manual, under the sub-heading COM radios Please check the section in the document and come back if you still can't sort it out. Regards Pete

Please cast your eye back one paragraph from the one you mention here and actually got working. The facility to which that is "similar to" is the one described just above it, which is precisely what you want. How did you miss it? Even if you scan the paragraphs in some random order, didn't the words "a similar facility" strike you as possibly referring to something just mentioned at all? ;-) Even looking at the screen itself, didn't the legend "Map 1->12, 2->34" seem relevant to your needs at all? Try it. Pete Hmmm.... :D

I don't know, sorry. Really methods like credit card or PayPal are quicker and easier. But I will forward your message here to the Manager of SimFlight and I expect he will get in touch with you. Regards, Pete

Don't you have the documentation? Please go to http://www.schiratti.com/dowson and download FSUIPC.ZIP. Inside you will find all the information you could possibly need. Please come back here if you still don't understand what to do, but I am sure you will find it easier with some explanation before you! ;-) Regards Pete

All that is in there are a thing called "test.cpp" and my own header files. I can see that the "cpp" file has DLL things added, but what "TOTAL MESS" have you made? Am I supposed to compare the code line-by-line? I'm not sure what you need me to check? I assume you mean "intra-process"? Inter-process is what you want with separate processes. ;-) Does this mean you don't agree with me adding the exports into FSUIPC? Regards, Pete

Not knowing anything really about scenery design, I'm not sure what you could or want to do with it, I suppose that's up to the imagination. As far as actually communicating between them, all I know about are the few variables which you can access (read and write I assume) in scenery files which are mapped to FSUIPC offsets for aplications also to access. See the FSUIPC SDK for more details. (Get this from http://www.schiratti.com/dowson). Regards, Pete

Okay. I'll make a note and will probably get to look at it next week. I'm a bit tied up this weekend. Regards, Pete

Isn't this the sort of response parameter which can and should be attended to in the Aircraft's CFG file? It seems to be that this is the correct and proper place for it, not artificially "slackening the wire". I've had a quick look in the Bell CFG, and there's not much there (not to say it can't be added), but the Moments of Inertia are one area for experimentation. In most sophisitcated CFGs there are many Scalar parameters which control responsiveness -- I see in the Robinson one there are several in the [Helicopter] section. Haven't you tried to get the model to your liking first, before trying rather strange external means? I think it would be better, really. Having a delay in supplied values can be done. It is messy, and I think it would tend to emulate the same effect as being slowed to a very low frame rate in FS -- i.e. you'd overcontrol. I always overcontrol the helos in any case, you must be a top notch pilot if you need it harder than it is already at full realism! Let me know, either way. I can have a look. But even if I did it I'd probably relegate it to an INI file parameter only -- it's getting far too crowded in the options and User Interfaces are not my forte as you can see! Regards, Pete

Actually, I don't like that for several reasons: 1. It cannot be named a DLL, or else must go elsewhere than in the FS Modules folder 2. It means more packaging for the software author and more to install / uninstall for the user 3. It is actually a lot more work for me to produce a new DLL in any case. 4. It would be yet another module for me to maintain and support. 5. The code is so small (miniscule), it would fit into FSUIPC without even noticing. Additionally, if it forces more folks to update to the latest supported version of FSUIPC I like it better. A lot of my support time is wasted trying to help folks using older versions before I find out they are! ;-) Okay, Regards, Pete

Pelle has confirmed that he knows no way to bind Delphi to C/C++ LIB files. He does, however, specifically say that should be no problem linking to DLLs. He says "there shouldn’t be any problem using functions from other DLL’s from within a Delphi program/DLL. I admit I haven’t done much programming using DLL’s (I normally place all my code in the EXE, making it easier to “distribute” the application), however I don’t think Delphi will have any issues with DLL’s that are not called DLL (for instance formally ActiveX are DLL’s with the extension OCX and these can be used in Delphi without any problem)." Okay. All you should need is the equivalent of LoadLibrary() and GetProcAddress(). These allow you to link at run time, without a disastrous failure (FS crash) should the DLL not be available or not have the procs you need exported. Here's an example in C (this is how it would be if I build the library into FSUIPC.DLL):: HMODULE hInstFSUIPC; BOOL (WINAPI *pFSUIPC_Open2)(DWORD, DWORD *, BYTE *, DWORD) = 0; BOOL (WINAPI *pFSUIPC_Process)(DWORD *) = 0; BOOL (WINAPI *pFSUIPC_Read)(DWORD, DWORD, void *, DWORD *) = 0; BOOL (WINAPI *pFSUIPC_Write)(DWORD, DWORD, void *, DWORD *) = 0; BOOL (WINAPI *pFSUIPC_Close)(void) = 0; ... hInstFSUIPC = LoadLibrary("FSUIPC.DLL"); (DWORD) pFSUIPC_Open2 = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Open2"); (DWORD) pFSUIPC_Process = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Process"); (DWORD) pFSUIPC_Read = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Read"); (DWORD) pFSUIPC_Write = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Write"); (DWORD) pFSUIPC_Close = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Close"); Then you should check that all five of these results are non-zero. This confirms that you have the addresses of the routines you need. At the end of the program use FreeLibrary(hInstFSUIPC); When you want to actually use any of these FSUIPC routines, you call them via the pointers. For example, again, in C: (*pFSUIPC_Close)(); The * dereferences the pointer so the call actually does go to the address contained in the variable called pFSUIPC_Close. I am sending this to Pelle too, in case you need help understanding how to do this is Delphi. It would be much easier to link to the DLL unconditionally, as you would to you own DLLs or Windows, but then you crash FS if the wrong version of FSUIPC is there, or no FSUIPC is there at all. You can check these things easily with the above code. Let me know when you decide what to do. I don't think I would have any problem adding these exports to FSUIPC, but of course I'd need to check that first, and also make sure there was no adverse affect on FS itself. I don't think it checks for other exports, but you never know! ;-) Regards, Pete

I have C source provided with SDK Ah, yes, so you do. I forgot that I provided everything for that too. Well, of course most if not all of Windows itself is written in C or C++ and all the APIs your program is using come from Windows DLLs like USER32.DLL, GDI32.DLL, KERNEL32.DLL etc. I wrote a PrivateMessage same day you told me about him, but no answers yet...I cannot find his email...could you provide it to me via PM or email (escape@cg.yu) so I can contact him... I've written to him already and asked him to look at this thread. He is pursuing investigations into what can be done at present, like you. ;-) Regards Pete

That would certainly be the best way, if it is possible. That is a little more problematic. If the DLL resides in the FS Modules folder it will have to be named other than a DLL -- I know C programs can link to any DLL even by a different name, but can Delphi? I think, if it is resolved this way then you might need to place the C DLL you are using into a separate folder of your own creation, and explicitly point your code at it at run time. There are two further alternatives which could be considered: 1. I could supply the C source for the Module User's library, for conversion to Delphi, and thence presumably building into your module in place of whatever you have now. Most of the code is similar, it is mainly the "Process" call which is different, abd of course the Open2 call in that you provide the memory, whereas for an external program the memory is a "memory-mapped file" opened with Windows. There are two small problems with this approach -- the first is finding someone who knows both C and Delphi to do the work, and the second is that the calling sequence into FSUIPC, in the Process routine, does involve a very small amount of Assembly Code which is designed to provide essential information in the call. I don't know if what it needs to do is possible in Delphi. 2. I could have a look to see if I can (or should) build the interface C procedures (Open2, Read, Write, Process and Close) into FSUIPC.DLL as exports which you can link to directly from your DLL. In other words, rather than attempt to make a separate DLL with the ensuing problems I describe above, expand FSUIPC itself to BE that DLL. I don't mind doing this last change, though I am only prepared to do it if it is indeed possible for Delphi to actually link to and use such procedures. I'm afraid my knowledge of Delphi is so poor I do not know. Perhaps you could investigate this and advise? There is another problem arising with this last alternative in any case -- obviously I have to find time to build in the code (possibly within a week or so, but I'll not know till Monday), and you would need to stipulate to your Module users that they must have version x of FSUIPC or later. Let me know your thoughts and we'll proceed from there. Did you contact Pelle, by the way? Regards, Pete

It's the commercially built one, by PFC, using my software and Project Magenta. I'm adding other bits too, but the hardware is almost all PFC and is an ongoing development. See details of their 737NG cockpit at http://www.flypfc.com, though the illustrations there are becoming quite a bit out of date I think. There are still plenty of things to do in it but for hardware I am in PFC's hands -- and I suppose they in mine for much of the software needs. Well, I did try for several years to make my own cockpit, way back in FS4-FS5-FSW95 days. Yes, I was using EPIC (two ISA EPIC cards and loads of attached expansions). I also had some FlightLink stuff which I "butchered" and re-programmed for use in it. But, whilst I could manage electrical wiring, and some electronics, I was and still am absolutely hopeless with other practical things like metalwork, woodwork, painting and so on. Nothing I did ever really looked anything much more than a ramshackle collection of computers and other boxes. So I gave up with the practical building side and concentrated only on software. ;-) Thank you for your offer! We'll see how things go in the long term. I am 63 this year and would like to see myself gradually easing out of such heavy commitments in a few years time. Don't worry though, I have ideas on this and I have high hopes for the future. ;-) Regards Pete

If you were running with IPX/SPX protocol (i.e. had "UseTCPIP=No" in the INI file of the Client), then, yes, the ServerNode is unique to the specific hardware network hardware on the Server. It would, of course, also matter if you had given the ServerName or ServerIPaddr in the INI, for TCP/IP protocol. This is not needed with WideFS 6.5x provided everything is running WinXP, because it can find out for itself. WideServer does try to send out the ServerNode data, for IPX/SPX clients, but I have no way at present of determining the correct one on WinXP -- there always seems to be several. That part was actually better on Win98. Regards Pete

Strange. The ServerNode is only needed with IPX/SPX protocol. By default WideFS would use TCP/IP. Regards Pete

Wow! I wonder what that is doing? blocking messages is one thing, but changing them? That's very naughty! The sumchecking I'm doing is only of the data parts of whatever protocol you are using. Possibly if you switched to IPX/SPX it would get through unmolested? Certainly I am not using "RAW" mode on the connections and have no access to any of the TCP/IP red tape which, possibly, they may legitimately tamper with! Thanks for letting me know. Regards Pete