FSUIPC and VB.Net

[PSchrenk]

Hi,

in VB.Net the return value after calling the FSUIPC_GET Function is (by SDK Design) an Integer Value.

Going through the FSUIPC for Programmers Manual i saw that the calculations are all based on Long Values.

Is there any way to access them as Long value in VB.Net ?

I tried to display the bank and pitch angle in degrees, but to no avail.

With the flaps i could help myself and take portions of 255 (the value i get for full flaps), but with bank and angle it does not seem to work.

I hope i didn't write it totally confusing.

Thanks in advance, Peter Schrenk

[Pete Dowson]

in VB.Net the return value after calling the FSUIPC_GET Function is (by SDK Design) an Integer Value.

I don't know VB, but normally the result is merely an indication of success or failure. The FSUIPC_Read operation reads a block of memory, it isn't specifically an integer or anything else. It could be a whole batch of integers, or a string of characters, et cetera et cetera.

What you then treat the data as will vary according to what you are reading and how you want to use it.

Going through the FSUIPC for Programmers Manual i saw that the calculations are all based on Long Values. Is there any way to access them as Long value in VB.Net ?

In C/C++ "long" is the same as "int". Do you mean unsigned as opposed to signed? If VB cannot handle unsigned numbers then, I'm sorry, I don't know what to advise you.

I tried to display the bank and pitch angle in degrees, but to no avail. With the flaps i could help myself and take portions of 255 (the value i get for full flaps), but with bank and angle it does not seem to work.

I've no idea how you get 255's for full flaps -- the Integer value is 16383, or hex 3FFF. If you only read one byte (character) you'll get 255 (the FF in the first byte), but that could equally refer to 63 other flap positions (00FF to 3EFF, hex 3F = 63 decimal).

The pitch and bank values are easy, because they are simple signed 32-bit integers, which I'm sure is the default Integer value type in VB. But it is 4 bytes you need to tell the Read routine -- if you are getting 255 for full flaps it sounds very much like you are reading only 1 byte (8-bits) and so only getting a quaerter of the total data needed for a 32-bit integer.

Regards,

Pete

[PSchrenk]

Hello Pete,

here is the code where i get the 255 for the flaps:

Dim Flaps As Integer

Dim MyResult As Byte

Dim Currentflap As Long

mod_FSUIPC.FSUIPC_Read(3036, 2, Flaps, dwResult)

mod_FSUIPC.FSUIPC_Process(dwResult)

mod_FSUIPC.FSUIPC_Get(Flaps, MyResult)

Currentflap = MyResult.ToString

MsgBox("Current Flap: " & MyResult.ToString)

I would not understand thou why the .ToString would give me only the first byte.

Unfortunatly there is no example in the .Net SDK, so i am pretty much in the dark right now.

greetings, Peter

[PSchrenk]

Hi again, and a BIG "Thank You" to you Pete !!!!!

I used "Byte" for the declaration since the Function showed it as "ByRef Result as Byte".

But actually i needed an Integer.

So i corrected the Dim MyResult as Byte to Dim MyResult as Integer.

And got the Flap values listed in the manual.

Tomorrow i'll look at the bank and such.

Thanks again for pointing me into the right direction.

Best wishes to you from vienna, Peter

[Pete Dowson]

mod_FSUIPC.FSUIPC_Read(3036, 2, Flaps, dwResult)

mod_FSUIPC.FSUIPC_Process(dwResult)

mod_FSUIPC.FSUIPC_Get(Flaps, MyResult)

What does "FSUIPC_Get" do? Surely after the Process call the Integer "Flaps" already contains the value, which should certainly be 16383 for full flaps.

I would not understand thou why the .ToString would give me only the first byte.

I don't know what "ToString" does either, but it's why you need a "Get" which is really puzzling me.

I'm afraid you'll need to talk to someone who know something about VB or VB.NET (if they are different?).

Incidentally, it is odd seeing "3036" for the flaps offset of 0BDC. Doesn't VB.NET have the hex facility either (&H0BDC I think?).

Also, note that 0BDC is defined as 4 bytes (i.e. a full 32-bit integer) even though the value never exceeds the 2-byte capacity. However, you've defined "Flaps" as "Integer" which I assume is 32 bits (4 bytes). I don't know if VB clears the values to zero for you -- C/C++ certainly doesn't for dynamic (stack-based) variables -- so to be safe you should either read 4 bytes or set Flaps = 0 first.

Regards,

Pete

[Pete Dowson]

So i corrected the Dim MyResult as Byte to Dim MyResult as Integer.

And got the Flap values listed in the manual.

Ah, right. Yes, I didn't notice that. Looks like the 32-bit result was being written to an 8-bit location and so spilling over into another value. Since it would normally be zero that would clear part of that value. You were lucky (or unlucky) that it didn't overwrite something more important and crash the program! :wink:

I still think that you should either read all 4 bytes of Flaps or set your Flaps = 0 before reading, in case there's rubbish in the high part.

Don't forget, when you start reading more stuff, it is much more efficient to do a list of "FSUIPC_Reads" and then one "FSUIPC_Process" for the lot. Only the "Process" call actually goes into FSUIPC.

I still don't understand why there's that "FSUIPC_Get", though.

Regards,

Pete

[PSchrenk]

Hello Pete,

to "FSUIPC_Get":

in the SDK Mr. Scott wrote it like that:

' FUNCTION LIBRARY FOR FSUIPC

' based on C code supplied by Pete Dowson

'

' BASIC USAGE GOES LIKE THIS:

' - call FSUIPC_Initialization() to initialize important vars at beginning

' of program.

' - call FSUIPC_Open() to connect with FSUIPC if it's available.

' - call a series of FSUIPC_Read and/or FSUIPC_Write and/or FSUIPC_WriteS (be careful when

' combining these in the one transaction, for your own sanity).

' - call FSUIPC_Process() to actually get/set the data from/to FS.

' - For reads, call FSUIPC_Get to retrieve data read from FSUIPC (New for VB .Net)

' - repeat steps 3, 4, and 5 as necessary

' - at program termination, call FSUIPC_Close().

I think the Get actually converts the Byte Values into an Integer, and that is why i get the correct value now.

I just tried to follow the instructions to do all properly.

About the Offset and Size:

' Function FSUIPC_Get(ByRef Token As Integer, ByVal dwSize As Integer, ByRef Result As Byte) as Boolean

It is declared as integer, so i converted it to decimal.

The size was set to 2 since it is written like that in the FSUIP for Programmers document.

About crashing the program (and prolly FS2004)....

you can believe me that i am amazed myself, this is the first time i try anything like this.

(At work i have predefined and documented API's for programming aka put parts together no-brainers.)

Thank you for taking the time here, as experienced C programmer it must be really cruel the way i handle this code so far. :oops:

with best regards, Peter

[Pete Dowson]

I think the Get actually converts the Byte Values into an Integer, and that is why i get the correct value now.

Oh, right. Not sure why, but then I don't know VB, lrt along VB.NET.

The size was set to 2 since it is written like that in the FSUIP for Programmers document.

Er .. it isn't in my copy, it's declared as 4. Maybe it was in an old version of the SDK? I don't have one so I can't check I'm afraid.

Thank you for taking the time here, as experienced C programmer it must be really cruel the way i handle this code so far. :oops:

Well, from the sorts of questions I get on VB problems I think most are due to the language, not the user. I think it is ambiguous and imprecise, and the more I know about it the more I think it's a bad choice for beginners (or for anyone, for that matter). But maybe I'm just a little prejudiced! :D

Regards,

Pete

[PSchrenk]

Hi Pete,

you are right with the value of 4, i guess i should get new glasses.

(or drink more cawfee :idea: )

About Visual Basic....

well, it depends on the needs, at work i use VB 6.0 and VB.Net, so of course i use it at home too.

Beside that, for me C is REALLY confusing since i am used to VB.

I guess its what you "grow up with", i did with the C-64 and later AmigaBasic.

best wishes from me and my cawfee-machine, Peter

[petdocvmd]

Well, from the sorts of questions I get on VB problems I think most are due to the language, not the user. I think it is ambiguous and imprecise, and the more I know about it the more I think it's a bad choice for beginners (or for anyone, for that matter). But maybe I'm just a little prejudiced! :D

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

[Pete Dowson]

Hey Pete, I can't just let ya bash VB like that

Ah, wellI did say I was prejudiced, didn't I? :)

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.

I take all your points on board, and will probably henceforth recommend all VB programmer's who ask me questions to upgrade to VB.NETbut tell me this, does it still change

&H00008000

into

&HFFFF8000

i.e. sign extend even though the zeroes are explicit? That alone makes me shiver! :?

Regards,

Pete

[PSchrenk]

Hello Scott....

could you send me some VB.NET code samples for FSUIPC to p.schrenk@mynetwork.at ?

I still have some problems with getting the proper values.

Some parts, like FS Time and Flaps are no problem, others like IAS keep me puzzled, it just starts with 32 and then keeps increasing it by 8.

It really would get me started with my FS Project (turning 50 percent of my living room into a cockpit which uses 5 computers running widefs for displaying the cockpit elements), and since i see what problems a less experienced programmer ( :oops: like me) steps into with VB.Net and FSUIPC i'd publish the examples and such on my webserver for future "starters".

I'd really appreciate the help.

Best wishes from vienna, Peter

[airforce2]

The pesky FSUIPC_Get was written to allow VB.Net to place the results of FSUIPC_Read operations into a managed data structure which is compatible with the .net memory management system. The basic approach is to pass the FSUIPC_Read a reference to a table offset token, and the function returns the offset into the local, .net-managed buffer which will contain the result after the FSUIPC_Process call. The FSUIPC_Get function retrieves the value at the specified offset from the local r/w buffer.

This was necessary because just passing FSUIPC_Read a pointer to a variable as in previous versions will not work with the .Net heap manager moving things around. The referenced variable may be moved by the heap manager in the interval between when the FSUIPC_Read and the FSUIPC_Process calls are made, leaving one with a nasty dangling pointer problem.

In any event, some of the previously posted difficulties came from trying to read the offset token as data...the first param in the FSUIPC_Get call is the integer offset token returned by FSUIPC_Read, the second param is a reference to the var where the actual result will be passed. The overloaded function defs will pass the correct size/type of data based on the type of the second param used in the call, except for passing of arrays where number of bytes to return must be explicitly coded.

Clear as mud?

Regards

[petdocvmd]

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

The pesky FSUIPC_Get was written to allow VB.Net to place the results of FSUIPC_Read operations into a managed data structure which is compatible with the .net memory management system. The basic approach is to pass the FSUIPC_Read a reference to a table offset token, and the function returns the offset into the local, .net-managed buffer which will contain the result after the FSUIPC_Process call. The FSUIPC_Get function retrieves the value at the specified offset from the local r/w buffer.

This was necessary because just passing FSUIPC_Read a pointer to a variable as in previous versions will not work with the .Net heap manager moving things around. The referenced variable may be moved by the heap manager in the interval between when the FSUIPC_Read and the FSUIPC_Process calls are made, leaving one with a nasty dangling pointer problem.

In any event, some of the previously posted difficulties came from trying to read the offset token as data...the first param in the FSUIPC_Get call is the integer offset token returned by FSUIPC_Read, the second param is a reference to the var where the actual result will be passed. The overloaded function defs will pass the correct size/type of data based on the type of the second param used in the call, except for passing of arrays where number of bytes to return must be explicitly coded.

Clear as mud?

Regards

[airforce2]

Scott;

I tried mightily to make variable pinning work prior to going to the local managed buffer scheme. It was extremely frustrating, and I never got it to work right.

Cheers