Jump to content
The simFlight Network Forums

737SimGuy

Members
  • Posts

    40
  • Joined

  • Last visited

Everything posted by 737SimGuy

  1. Pete, >>>you have to post-pend another & to stop sign extension: Yes, of course, that did the trick... Thank you, James
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. Hi Pete! It's working like a charm! FSUIPC is worth much more than $20, IMO... Thanks again, James
  9. 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
  10. 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
  11. 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...
  12. Ok Pete, thank you. I may experiment a bit but most likely will leave as is... James
  13. 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
  14. 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
  15. 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,
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.