Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About petdocvmd

  • Rank
  • Birthday 01/01/1970

Contact Methods

  • MSN
  • Website URL

Profile Information

  • Location
    Pennsylvania, USA
  • Interests
    Computers, programming, flying, golf
  1. Pete, VB.net has no signed byte data type. You have to use a short which covers -32768 to +32767. VB.net "number" variables are initialized to zero implicitly upon declaration (and booleans to false, strings to 'Nothing', etc)(yeah I know, programmers should be allowed to fall on their own swords ). I've been buried in 8051-variant assembler these days - feels kinda good mucking around in the"down 'n' dirty" stuff :-) Scott Scott L. Fausel, VMD Integrated Flight Systems
  2. Well Richard, we're off topic now but I'll give you my $0.02. Many folks made similar comments regarding the move from DOS to Windows - why write Windows-based code when DOS was faster/better/? VB.net is a quantum leap from VB6. Exception handling, Garbage collection, true OOP, xcopy deployment (no need for the registry), built in base class libraries, structures vs User defined types are all major improvements and there are many more. ADO.net makes data-driven web programming enormously easier and you can cater to all web clients. Yes, you do make a choice to target Win2k+ for non-web ap
  3. Yep, that did it. For the sake of those still following along or searching the forum in the future, here's the summary for programming Offset &H3200 via vb.net: 1. Create a 12 element Byte array. 2. Stuff elements 0-3 with Bytes 0-3 of message (&H100 or CONST WM_KEYDOWN for keydown, &H101 or CONST WM_KEYUP for keyup. I stripped the bytes out of the LONG integer via a for/next loop, the ">>" operator, an &HFF mask and the CByte() function. 3. Likewise stuff elements 4-7 with Bytes 0-3 of the virtual keycode you are sending (e.g. &H47 for the letter "G"). 4. ibid
  4. Yes, that is the crux of the biscuit. Unlike C++, VB.net is based upon a *managed* memory scheme. Except for some little advertised workarounds, dotnet does not use pointers to memory. It is all mapped and managed by the system. A benefit is the elimination of circular reference and other induced memory leaks but the cost is inflexibility in interacting with unmanaged code. The following is an excerpt from a previous Bob Scott Post: So you see the size/type is needed for the dotnet sdk functions - not the "raw" fsuipc Read or write. But re-reading Bob's post made me realize that we sho
  5. Indeed there is but I'll try without it at first. That was just for example - actually I'd just pass the variable that I stuffed the code into when originally captured. Good idea, thanks and yes it is quite horrid! Yes, well that's because no API knowledge is required to do this stuff in dotnet Oops, no sorry - you misunderstand me. The dotnet fsuipc sdk works the same way. However there are frequently times when one cannot queue reads and writes. For example, many functions need the information from a read (or reads from several different offsets) prior to writing some data be
  6. Rick pointed out the VB5/6 way of grabbing key codes and I think we can all agree that each language implements a way of capturing these and enumerating them. OK, I've waded through the API docs and here is where I am at: 1. WM_KEYDOWN is &H100 and WM_KEYUP is &H101 2. wParam specifies virtual keycode of the key to be sent 3. lparam specifies repeat count and several other items. Question 1: bits 16-23 of lparam specify the device dependent scan code...seems not useful as we already have virtual KC. Can we simply use lparam bits 0-15 for repeat count and zero the rest of the dou
  7. No insult taken (in my case I believe it's not a loss of understanding but a divergence of language and syntax) and we could probably fill an entire discussion forum with programming debates . However IMO you are overstating the cost of "code inflation and inefficiency." The dotnet framework is actually equal in efficiency and speed to unmanaged C++. Managed code (be it C++, C# or VB) is all compiled to a common intermediate language that is fed to the JIT (just in time) compiler. The resultant compilation is as fast and efficient as compiled C. All of the "bells and whistles" are rapid
  8. Roger. I wasn't sure that they mimicked the Windows API and a quick Google search was unrewarding. I'll search the API docs. Yes but it is so easy it should be illegal. No API required. I can intercept keyup, keydown and keypress like this: Function DoSomething(ByVal s as Object, ByVal e asKeyEventArgs) Handles MyBase.KeyDown ...Do something with e.keycode and e.Shift, etc - all enumerated for me End Function Sending is just as easy using built in "SendKeys" function - in fact you can use enumeration syntax e.g. {Backspace} and even avoid keycodes. DotNet has obviated 99% of the Wi
  9. Hi Pete, I'm looking to add a generic keypress simulator to my flight deck interface program so that users can assign hardware switches to mimic a keypress in MSFS. These are not joystick buttons so I'll be creating an xref table where the user can save switch-key mappings. The program will use FSUIPC offset 3200 to send the appropriate key to FS where it will (hopefully) do whatever the user has assigned in FS. Can you please define or give an example of "wParam" and "lParam" for me? I assume they represent keycodes and modifiers that are to be parameters of an API function but I am unfa
  10. A few more possible errors found: Public FSUIPC_FS_Version As Short Public FSUIPC_Lib_Version As Short FSUIPC_Open fails unless these are declared as Integers due to truncation when checking FSUIPC FS Version. For those of us who code with Option strict: 643: Dim idx = Token + 4 should be: Dim idx as Integer = Token + 4 --> keeps idx from being created as generic object and then being boxed to Integer. The declaration of t_FSUIPC_Lib_Version was originally done as part of debug code and may have been cut out with that in the latest version. Works fine for me if I just enter the de
  11. This is for the VB.net gurus: I just downloaded the updated vb.net sdk hoping it might solve a nasty bug in my app that seems to come from within the old sdk code I adapted. However there are 2 build errors in the sample: 505: VersionGet = FSUIPC_Get(t_FSUIPC_Lib_Version, FSUIPC_Lib_Version) "t_FSUIPC_Lib_Version" is never declared. Looks like it should be declared as an integer within FSUIPC_Open, correct? 636: Marshal.FreeHGlobal(heapbuf); Perhaps a late night translating C++ code ? Stray semicolon alert. My original issue was this: The following function is called as a helper funct
  12. Hey Bob, I wonder if it would be possible to use the GCHandle class to pin a managed address and then pass it to fsuipc_read as type IntPtr? That would protect it from the heap manager until you chose to free it - after grabbing the info. Anyone tried this? -Scott
  13. Hey Pete, I can't just let ya bash VB like that ! Although I'd be the first to admit that older versions were - shall we say - "less than desirable" VB.net is a bona fide programming language. It's a tool every bit as powerful as C++...in the right hands. What I see on this forum and elsewhere is misunderstanding and misuse by programmers. There's nothing ambiguous or imprecise about the language - it just seems that way if one doesn't know a short from a long or an OR from a XOR ! The class structure of dotnet allows very straightforward implementation of complex functions - for example
  14. Got it. I hadn't tried changing the pressure to check that. Right. Knowing that it is true AMSL is the key. Thanks for the help! Scott
  15. I am finishing up the logic for my reverse thrust mechanism and need to read absolute altitude AGL a la a radio altimeter for one of the conditions (the 737-700 RT can engage if a/c is <10' AGL via radio altimeter). Looking at the offsets in FSInterrogate while on the ground seems to indicate that all of the offsets pertaining to altitude are reading pressure altitude (MSL). Did I miss one that gives AGL? If not, can it be simulated with the info that is available (including maintaining accuracy even if the pilot has the wrong pressure dialed into the altimeter)? Thanks for your help!
  • 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.