737SimGuy

Pete, >>>you have to post-pend another & to stop sign extension: Yes, of course, that did the trick... Thank you, James

Hi Pete, I've read many books on VB cover to cover, and as reference, and have been aware of the VB style coercing, but have never ever had this problem before with FSUIPC stuff. My appologies for not gleaming it from the hundreds of messages here on the forum. Thanks for the info, I will give it a go... James

Pete, Further to my last... When I attempt to read a NWI offset individually the log shows an "8F" added to the front of the read. Here is the log entry for reading "uDynamics" in Area 0 i.e. C40C: 2128160 READ0 8FC40C, 1 bytes: 00 I am debugging here trying to figure what I may be doing wrong. Other non NWI reads work fine. Any ideas? FSUPIC 3.11 James

Hi Pete, I am trying to access the NWI via Visual Basic. I have registered versions of FSUIPC and WideFS. I can't seem to get any data. Only tried Area 0 and 1 so far. My question: Do I need a special access code, or should it be accessable now? Thanks, James

Pete, After re-reading your response, it dawned on me the probably the best way to accomplish what I want is to simply check for failed reads/writes. What would you consider a resonable threshold for determining Wideclient is not connected to Wideserver, 2 or 3 tries, 10 tries? James

Hi Pete, What I am trying to do is avoid my program appearing to lockup while (I'm assuming) it continues to try to read/write values to WideFS after FS has been closed. I would simply like to be able to stop the interaction of my program and WideFS when FS closes or locks up, then recognise if/when FS starts up again, like Project Magenta seems to do. Wideclient detects when Wideserver is not available, I am assuming because of a Windsock event, and I am interested in doing the same. Regards, James

Hi, I am looking for the best way to determine when FSUIPC is not connected so that my program can stop polling FSUIPC and avoid appearing locked up. I see 0x337E listed as a possible answer for this, but evidently I would need to compensate for the pauses while loading aircraft and such blocks FSUIPC cpu time. Is there a more efficient way? Thanks! James

Hi Pete! It's working like a charm! FSUIPC is worth much more than $20, IMO... Thanks again, James

Thanks Pete! I did manage to get it working in a fashion, still have some things to work out, but at least I get a name on the menu! I will have a look at your sample, maybe it will shed more light on things! James

Hi Pete, No, never tried it before this. I will keep messing with it, as I believe it is a VB to C translation problem, I'll get it... Thank you, James

Hi Pete, Does the "MODULES MENU access for Applications: " work in FS2004? Can't seem to get it to work, but I will dig deeper if you say it should...

Ok Pete, thank you. I may experiment a bit but most likely will leave as is... James

Hi Pete, First off, let me point out that I am not having any real performance issues with FSUIPC. However, I have been doing some snooping, and found something that I am wondering if it could be improved (on my end, not yours). In the FSUIPC VB, (and C), interface code for sending Writes to FSUIPC it is using "SendMessageTimeout" like this: While (i < 10) And ((SendMessageTimeout(m_hWnd, m_msg, m_atom, 0&, SMTO_BLOCK, 2000, dwError)) = 0) dwError)) = 0) do begin // return value i = i + 1 Sleep (100) ' Allow for things to happen So it tries a write and then *blocks* any more processing until it receives a response, with a 2000ms timeout, then tries again (up to 9 times). Do I really need to use SMTO_BLOCK or would it be more efficient to use SMTO_NORMAL which would allow other writes while waiting for responses. Or, maybe this would muck up FSUIPC? Also,would maybe a smaller timeout value be appropriate? With the 2000ms timeout and 9 attempts I would have to wait 18000ms for the next write! Seems high to me. Any thoughts? Regards, James

Hi Pete, I'm not "picking" on any of these, simply stating which versions I am using at the time of the discovery, you usually like to know this. I am involved in re-programming my cockpit using tools other than simple EPIC EPL and had never used the left and right gear positions for anything before now. I had always used the nose gear position and manipulated the other lights via EPL. I wanted to see if other folks had the same results or if it were something in my code that I overlooked. Ok, thanks, I will correct here. Ahh yes, the story of my life! ;-) Bye for now, James

Hello, Can anyone verify or deny that the Gear Position offsets for left and right landing gear are swapped? When I compare my extracted data to the operation of the gear lights on the default FS B737 instrument panel they appear to be swapped. 0BF0 4 Gear position (left): 0=full up, 16383=full down 0BF4 4 Gear position (right): 0=full up, 16383=full down FS2004 & 2002, FSUIPC 3.04 Thank you,