FS2004, WideFS, Visual Basic and Landing Gear.

[fokker70]

I'm a registered user of FSUIPC and WideFS. I'm taking my first crack at using Wide Client and writing a VB program to interface some hardware to FS2004.

Wide Client connects to FS2004 with no problems. The VB program seemingly connects to Wide Client fine as I can read altitude and FS Time just fine. The problems I am having at the moment seem to be related to writing to FS2004.

I have a few issues/questions... Thanks.

1) In the code below for Landing Gear Down works fine. The code for Landing Gear up does not bring the gear up. Does anyone see anthing wrong with the way I am doing this?

2) Im not certain I understand when to use FSUIPC_WriteS and when to use FSUIPC_Write.

Private Sub cmdLandingGearDown_Click()
    Dim temp As Long

    Dim doGear(4) As Long

    doGear(1) = &HFF
    doGear(2) = &H3F
    doGear(3) = &H0
    doGear(4) = &H0

    temp = FSUIPC_WriteS(&HBE8, 4, doGear(1), dwResult)
    temp = FSUIPC_Process(dwResult)
End Sub

Private Sub cmdLandingGearUp_Click()
    Dim temp As Long

    Dim doGear(4) As Long

    doGear(1) = &H0
    doGear(2) = &H0
    doGear(3) = &H0
    doGear(4) = &H0

    temp = FSUIPC_WriteS(&HBE8, 4, doGear(1), dwResult)
    temp = FSUIPC_Process(dwResult)
End Sub

[fokker70]

I figured out why cmdLandingGearUp_Click function was not working. I was using FSUIPC_WriteS and not using the VarPtr function when passing the sencond parameter. Now I'm puzzled why the cmddLandingGearDown_Click function was working without these corrections! Oh well.

The code below works: :D

Private Sub cmdLandingGearDown_Click()
    Dim temp As Long

    Dim doGear(4) As Long

    doGear(1) = &HFF
    doGear(2) = &H3F
    doGear(3) = &H0
    doGear(4) = &H0

    Call FSUIPC_Write(&HBE8, 4, VarPtr(doGear(1)), dwResult)
    Call FSUIPC_Process(dwResult)
End Sub

Private Sub cmdLandingGearUp_Click()
    Dim temp As Long

    Dim doGear(4) As Long

    doGear(1) = &H0
    doGear(2) = &H0
    doGear(3) = &H0
    doGear(4) = &H0


    temp = FSUIPC_Write(&HBE8, 4, VarPtr(doGear(1)), dwResult)
    Call FSUIPC_Process((dwResult))
End Sub

[Pete Dowson]

The code below works: :D

It does? That amazes me, and shows how little I know about VB. I would have thought that:

Dim doGear(4) As Long

would define an array of 4 longs (i.e. 4 32-bit or 4-byte integers). Does it not?

If it does, then

Call FSUIPC_Write(&HBE8, 4, VarPtr(doGear(1)), dwResult)

would only write the first one, which contains hexadecimal FF -- or does it?

To write all 4 parts of the array you'd need a length here of 16, which would then overwrite the actual gear position values (but not for long as I think Fs would quickly replenish those).

I am thinking here that what is really happening is that your

doGear(1) = &HFF

is actually setting "doGear(1) to &HFFFFFFFF. This would be that strange invisible extension which VB seems to do secretly and which keeps cropping up here in the Forum. If you set it as &HFF& to stop it doing that, then I expect you'd only write hex FF to the gear, not enough to operate it.

If I am right, then your other declarations:

doGear(2) = &H3F

doGear(3) = &H0

doGear(4) = &H0

are a waste of time and space.

Why not just declare "doGear" as an integer, not an array, and set it to &H3FFF? Or even more in keeping with the documentation, set it to 16383, as defined?

On your other question, I think (but I am not 100%) that the WriteS variant was added because of the way VB treats strings -- apparently strings are passed by value in VB not by pointer as in C/C++. The different declaration of the WriteS variant helps sort the VB compiler out.

I hope someone who knows more than me about VB will jump in and correct anything stupid I've said here.

Regards,

Pete

[fokker70]

Thanks Peter.

I was thinking that each byte needed to be passed to FSUIPC_Write seperately, probably because the VB example show reading the time into an array:

Dim auiTime() As Byte
ReDim auiTime(3)
   If FSUIPC_Read(&H238, 3, VarPtr(auiTime(1)), dwResult) Then
      If FSUIPC_Process(dwResult) Then
      ' "Process" proceeded without any problems
      lblClock.Caption = Format(auiTime(1), "00") & ":" & _
                         Format(auiTime(2), "00") & ":" & _
                         Format(auiTime(3), "00")

Just a oversite on my part. I was making this more complicated that it needs to be.

I used your suggestions and streamlined the code below and it works great (there is no error handling yet). Can you comment on if this is the proper way to use the SDK. Not the VB code, just the process of calling the Write function and them the Process function. Thanks Pete.

Private Sub cmdLandingGearDown_Click()
    Dim gearDown As Integer

    gearDown = 16383
    Call FSUIPC_Write(&HBE8, 4, VarPtr(gearDown), dwResult)
    Call FSUIPC_Process(dwResult)
End Sub

Private Sub cmdLandingGearUp_Click()
    Dim gearUp As Integer

    gearUp = 0
    Call FSUIPC_Write(&HBE8, 4, VarPtr(gearUp), dwResult)
    Call FSUIPC_Process((dwResult))
End Sub

[jd]

the only thing i see is the extra set of parentheses in the next to the last line of code. everything else looks dandy

[Pete Dowson]

Can you comment on if this is the proper way to use the SDK. Not the VB code, just the process of calling the Write function and them the Process function.

Just to note that you should do all the reads and writes you want to do in each "cycle" of your program, whatver, then one Process call. The FSUIPC_Read and Write calls take no time at all and do not invoke FS or FSUIPC, but every FSUIPC_Process call means a process switch into FS and activity in FSUIPC to heed your requests.

If you are simply responding to humans pressing buttons and so on, then the single Write/Process sets as you have there will be okay -- with each being instigated manually there is no performance hit to notice. But group them when you do have several things to read/write.

Regards,

Pete