petdocvmd

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

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 applications. That's a personal decision you must make after weighing the pros and cons of the improvements vs. the reduction in client scope. Another large factor is the learning curve - much of VB.net (especially OOP) is very different than VB and it's a steep climb. Well worth it IMHO. -Scott

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 for elements 8-11 and Bytes 0-3 of lParam (0 unless you are looking to send repeats i.e. "acceleration"). 5. Write the byte array to fsuipc: FSUIPC_Write(&H3200, 12, KeyData, t_keyData, _intError) where KeyData is the resultant byte array. 6. Process when appropriate. Seems obvious once it's figured out but then I suppose most things do ! -Scott

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 should be able to write a 12 element Byte array to 3200 by using the Byte() overload of FSUIPC_Write and setting size to 12. You can also see how queuing reads for a group process becomes more complex when one has to retrieve all data with unique tokens in individual "Get" functions after a Process call. Makes shared helper functions much more difficult to code. Theoretically one can "pin" managed memory and protect it from the system's "shuffles" but Bob reported he tried valiantly but unsuccessfully to make that work correctly before resorting to the buffered table. Well, time to put this to the test. I'll keep you posted. Regards, Scott

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 because the data is dependent upon what is read (such as functions that toggle one bit in a Word or branch depending upon the data read). Thus you must process the read or reads before writing otherwise you don't know what to write. I could potentially code a static boolean flag into each function that postpones writes such that only every other time the dispatcher calls the function it performs the writes. Each cycle would have its own group process. One issue is that many functions share a common helper function which currently (re)creates a token that would lead to conflicts if the function executed more than once in a process cycle. However I could have the parent function pass in token and result parameters to keep them unique. Ok, I see a lot of debugging and testing ahead but yes I would love to eliminate single read/write processing from my code altogether! Yes, sorry - was referring to a data type, not a structure. Poor choice of words but it was getting a bit into the wee hours when I wrote that! Actually, the vb.net implementation of structures is very robust - they are basically classes without some of the bells & whistles. Much improved from VB6 User defined types. However I don't know that I could pass such a structure to the fsuipc.write function - I don't see an overload for it in Bob's SDK code. That's what prompted my concern about a 12 byte value - the sdk write function appears to only accept 1-, 2-, 4- and 8-byte values plus byte arrays. My thought was passing a 12 element array of single bytes - would that fit your definition of "cobble together" ? It's no problem to create a 3 element arrray of 32 bit unsigned values (Long in vb.net - and yes, it does support unsigned values) - I just don't know if the SDK fsuipc.write function can accept such an array of Long Integers. I have passed structures to the API in my programs via a C++ function library in order to interact with another developer's USB input board. The difference is that I wrote the wrapper function signature so as to solicit a structure as a parameter whereas the fsuipc vb.net sdk does not appear to have a write function with a structure as the data parameter. I'll have to check with Bob Scott about passing structures to fsuipc from vb.net. If this cannot be done via a byte array then I will work on coding a function that will accept structures and adding it to the sdk. Thanks, Scott

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 double word e.g. lparam = 0 if there are to be no repeats (and assuming not an extended key as set in bit 24)? Question 2: Is it correct to say that to transmit a "shift-K" I would send a WM_KEYDOWN + &H10 + 0 followed by WM_KEYDOWN + &H48 + 0 and then the corresponding KEYUPs to simulate holding the while "K" is depressed (&H10 is VKC for shift and &H48 is vkc for K)? Question 3: The FSUIPC guide indicates that all 12 Bytes must be written in "one IPC write." In the fsuipc VB.net sdk writing an offset is done via a Write followed by a Process. Can I write to 3200, write to 3204, write to 3208 and then process? Or are you saying I have to write 12 Bytes to 3200 in one function call - is that even possible given the largest data structure (Long or Double) is 8 bytes? Or do I use a 12 element byte array? Sorry - I know my lack of familiarity with C and the Windows API are making this stuff murkier to me than it should be though I think I've just about got it. Thanks for your help, Scott

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 development tools only. The intermediate language that results is "lean and mean" and dotnet programs are far from "bloated." I dabbled a bit in 8086 assembler way back when and still program PICs in assembler so I know how you feel - kind of like digging in the garden vs. picking out veggies at the market . Nonetheless with high level RAD languages like vb.net I can cut my development time enormously. And I do indeed know what is really happening - it's still full of Do and For loops and function calls, etc. What's improved is the standardization - namespaces, classes, etc. It is now very easy to look up the hierarchy of an object or method and figure out how to use it. Yes - simply called "Constants" in VB like so: Public CONST ESC_KEY = 27 But it's unnecessary as these are already defined in a dotnet enumeration (keyChar) for me: labelKey.text = e.KeyChar (displays actual key e.g. "K" in label) where e is the argument passed to my function automatically if this function handles the keypress event. I can also obtain e.KeyValue integer representation of the key (i.e. keycode). That's an example of the opposite of "code bloat" - I do not need to add a keycode/value constant map to my code as you would in C - it's already embedded in the framework (within the forms namespace) Anyway, I still haven't had a chance to review the API to see how 3200 wants those parameters formatted. Hope to get to it tonight. Thanks for the lively discussion ! Regards, Scott

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 Windows API (in fact it will probably become legacy in next release - 'Longhorn'). I'm sure I can find them now that I know they are WIndows API terms. I'm not quite sure about what you mean by defining keycodes here. VB.net has no header file. Won't my program just need to "know" (e.g. via constant definitions) that keycode 112 = F1, etc? I have copies of the sections you mention but the application will capture the keycode information in the section that accepts user input for the key(s) to be mapped to a particular switch i.e. "recording mode" Well, that's cause I let dotnet do all that dirty work for me . I guess it might be considered "cheating" by some but it sure saves me time to foucs on other programming issues ! Where I run into issues is in trying to interface with COM code conventions - as in this case. That's a great idea and I will probably offer both. My application handles a fair amount of stuff not modeled in FS or PM but some folks might just want basic interface stuff. That would essentially let me model my inputs as joystick buttons for functions I may not yet have coded. Thanks! Scott

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 unfamiliar with the nomenclature and unsure of which is which (Don't use APIs much in vb.net ). I could not find details in the documentation nor via a search of this forum. Perhaps you could indicate the value to be written to 3200 for a simple "G" and say "Ctl-K" for me? Thanks! Scott L. Fausel, VMD

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 declaration back in. Prior bug is still with me... Address: 1252 Data: 262384 262384 Error# 1925 Address: 1252 Data: 262384 262384 Error# 1926 Address: 1252 Data: 240 Address: 1252 Data: 240 Translates into 1,926 iterations where I got back "262384" from fsuipc instead of the "240" I should have (and which FSInterrogate displayed constantly). I'm sure hoping that this is an error code of some sort... -Scott

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 function from other functions that are called from a timing loop every 90ms. It's used to obtain values from Project Magenta to be displayed on the autopilot: Private Function ReadPMAPDigits(ByVal _Address As Integer) As Integer 'This function reads appropriate Digits from MCP or FCU and returns in _Data 'Declare Vars Dim blnStatus As Boolean Dim t_PMAP, _intError As Integer Dim _Data As Integer blnStatus = myFSUIPC.FSUIPC_Read(_Address, 2, t_PMAP, _intError) 'Obtain value If blnStatus Then 'Read Successful blnStatus = myFSUIPC.FSUIPC_Process(_intError) If blnStatus Then 'Process Successful blnStatus = myFSUIPC.FSUIPC_Get(t_PMAP, _Data) If blnStatus Then 'Get Successful Console.WriteLine("Address: " & _Address.ToString & " Data: " & _Data.ToString) Return _Data End If End If End If End Function The debug output to the console produces a steady stream of the offset address & data for about 5 minutes and then - anywhere from 127 to multitudes of iterations of nonsense values (correct address, nonsense value). FSInterrogate verifies that PM is not to blame - it's buffer value never wavers. Here's my trace: Address: 1252 Data: 240 Address: 1252 Data: 240 Address: 1252 Data: 240 Address: 1252 Data: -86114064 86114064 Error# 1 Address: 1252 Data: 262384 262384 Error# 2 Address: 1252 Data: 262384 262384 Error# 3 Address: 1252 Data: 262384 and so on 127 times before reverting back to the correct value (240, which is multiplied by 100 to get current ALT setting of FL240 in this example). Are these "nonsense" values error codes? If so, is there an xref table or some way I can trap them cleanly? "MyFSUIPC" is just an instance of a class I created with the fsuipc vb.net functionality. I'm utilizing the procedures as written in the (original) SDK. I'm going to rework the new sdk into a class but was wondering if anyone had heard of this behavior and if it might relate to a known bug. I seemed to remember a post here about some errors in the original code but I couldnt turn it up in a search (I think it was archived from the server). Thanks for any advice! Scott

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

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 runtime construction of function delegates - as long as one is willing to put in some time and learn them! Yes, direct memory manipulation requires a bit more stealth than C++ but one really only needs it when interfacing with C++ functions that "play" in unmanaged memory...and risk memory leaks - mostly a thing of the past in dotnet managed memory where circular references are killed and garbage collected automatically. Your earlier surprise that writing an Integer to a Byte did not cause a crash? Not an issue in VB as it would either be flagged in compilation if 'Option Strict' is (as it should always be) set or cause automatic downcasting if not - leading to the aforementioned truncation error but never overwriting a neighbor's memory. Anyway, I've blathered enough already. Suffice to say that imho (and programming experience) VB is a great tool when used correctly - "with power comes responsibility" as the cliche goes . My forthcoming cockpit I/O module's software interface will be written entirely in vb.net and I've had zero problems interacting with fsuipc or the hardware . Thanks, Scott L. Fausel, VMD

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

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! Scott Fausel