Access to FSUIPC via VB

[Skittles]

Hate to bother you again,

I got this code from the UIPC_SDK_VisualBasic.

I'm experimenting with "reading" data. I can read the clock, and in the first code block, I can read numbers... Like the "aircraft on the ground flag".

Private Sub Form_Load()
Dim dwResult As Long
Dim acName As integer
Main.Height = 11310: Main.Width = 15600
'Main.Left = (Screen.Width / Main.Width) / 2
'Main.Top = (Screen.Height / Main.Height) / 2
CenterForm Main
FSUIPC_Connect
  If FSUIPC_Read(&H366, 2, VarPtr(acName), dwResult) Then
    ' "Read" proceeded without any problems
    If FSUIPC_Process(dwResult) Then
      ' "Process" proceeded without any problems
      StatusBar1.Panels(5).Text = acName
    Else
      ' Unable to "Process"
      MsgBox ("Processing: " & dwResult)
    End If
  Else
    ' Unable to "Read"
    MsgBox ("Reading: " & dwResult)
  End If
End Sub

But when I tried to get a string "Aircraft Name" my program crashes.

Private Sub Form_Load()
Dim dwResult As Long
Dim acName As String
Main.Height = 11310: Main.Width = 15600
'Main.Left = (Screen.Width / Main.Width) / 2
'Main.Top = (Screen.Height / Main.Height) / 2
CenterForm Main
FSUIPC_Connect
  If FSUIPC_Read(&H3D00, 256, VarPtr(acName), dwResult) Then
    ' "Read" proceeded without any problems
    If FSUIPC_Process(dwResult) Then
      ' "Process" proceeded without any problems
      StatusBar1.Panels(5).Text = acName
    Else
      ' Unable to "Process"
      MsgBox ("Processing: " & dwResult)
    End If
  Else
    ' Unable to "Read"
    MsgBox ("Reading: " & dwResult)
  End If
End Sub

I didn't find any examples on reading strings. I could only assume a string size of 256 characters would be 256 bytes.

The crash actually occurs in the "FSUIPC_Process" function.

Any Ideas?

[Pete Dowson]

I didn't find any examples on reading strings. I could only assume a string size of 256 characters would be 256 bytes.

The crash actually occurs in the "FSUIPC_Process" function.

I don't know Basic enough to help very much I'm afraid, but the most likely problem is the way VB handles strings. I see you declared the reception area for the 256 bytes just as a "string", but how does VB know how much memory to provide? The Process call will write 256 bytes to whatever place in memory you specify, but if that isn't already obtained and sized it will almost certainly cause an Access Violation (crash).

I suspect you have to declare the input area as a byte array of 256 elements, then, after the Process call, build your string byte-by-byte using concatenation.

I also have the suspicion that VB uses unicode or some other 16-bit character format, not the ASCII single byte characters used in C, FS, and Windows.

Have you thought of using Paul Henty's interface for VB instead? I think he sorted all this stuff out quite neatly. See "FSUIPC Client DLL for .NET - Version 2.0" in the Download Links subforum.

Regards

Pete

[Skittles]

I see you declared the reception area for the 256 bytes just as a "string", but how does VB know how much memory to provide?

Yep, I needed to specify the size.

Have you thought of using Paul Henty's interface for VB instead? I think he sorted all this stuff out quite neatly. See "FSUIPC Client DLL for .NET - Version 2.0" in the Download Links subforum.

I'll take a look!

Thank you so much!!!

[Skittles]

I found this in the UIPC_SDK_VisualBasic readme...

    'Convert String to Byte
    For intCount = 1 To Len(strMessage)
        strMessageB = strMessageB & ChrB(Asc(Mid(strMessage, intCount, 1)))
    Next intCount

    strMessageB = strMessageB & Chr(0)

I figure it's taking a "character", turning it into an ASCII value and then returning the character as a byte.

So I thought the reverse would be a byte, to ASCII to character.

Function Convert_Byte2Str(byteMessage As String)
Dim intCount As Integer
Dim byteMessageB As String * 256

    For intCount = 1 To Len(byteMessage)
        byteMessageB = byteMessageB & Chr(Asc(Mid(byteMessage, intCount, 1)))
    Next intCount

    Convert_Byte2Str = byteMessageB
End Function

Since I added the string size to the declaration, it's no longer crashing in the process routine. It's crashing when I tried to put the string into a "text" property. Or, in the code below, when the function Convert_Byte2Str(acName) puts the result into acName.

Dim dwResult As Long
Dim acName As String * 256
If FSUIPC_Read(&H3D00, 256, VarPtr(acName), dwResult) Then
' "Read" proceeded without any problems
  If FSUIPC_Process(dwResult) Then
    ' "Process" proceeded without any problems
    acName = Convert_Byte2Str(acName)  <-------------------- CRASHES HERE
    StatusBar1.Panels(5).Text = acName
  Else
    ' Unable to "Process"
    MsgBox ("Processing: " & ResultText(dwResult))
  End If
Else
  ' Unable to "Read"
  MsgBox ("Reading: " & ResultText(dwResult))
End If

I suppose it's a byte conversion problem? I've read I have to use a Byte Array?

I'm still looking into if my VB uses ASCII or Unicode. I really don't want to tell you what version of VB I'm using... it's will probably raise your blood pressure... VB4.

I did find STRConv which will convert from 2-byte Unicode to 1-byte ASCII, but it didn't seem to work. Assuming everything else I'm doing is correct.

I think this is just over my head.

[Pete Dowson]

I found this in the UIPC_SDK_VisualBasic readme...

    'Convert String to Byte
    For intCount = 1 To Len(strMessage)
        strMessageB = strMessageB & ChrB(Asc(Mid(strMessage, intCount, 1)))
    Next intCount

    strMessageB = strMessageB & Chr(0)

I figure it's taking a "character", turning it into an ASCII value and then returning the character as a byte.

No, I remember this much from Commodore Pet Basic days (1978-80): The Basic "chr" function takes an ascii byte and turns it into a Basic character.

That code is exactly what I said you might need to convert C strings, read from FS, into VBasic strings. It is concatenating each ASCII byte to build up a Basic string.

I suppose it's a byte conversion problem? I've read I have to use a Byte Array?

Yes, you read that from my previous reply!

I think this is just over my head.

I don't like Basic at all, but then I'm a programmer. It is intended for non-programmers., but I think that only applies if you don't want to use it for anything real, where it has to talk to other things. Then it gets more complicated that C, in my opinion.

Why not look at Paul Henty's DLL? Most folks seem to find it much easier.

Pete

[genebuckle]

Skittles: You're going to have problems no matter what if you're using VB4. The minimum you should be using is VB6 with Service Pack 6. You would be _best_ served by download Visual Basic 2010 Express (it's a free download) from MS - assuming of course you'd like to continue to use VB/VB.Net. If you need help, PM me and I'd be happy to help out what whatever you're working on.

Pete: Instead of denigrating the guy's choice of development language, you could have just said, "I don't know how to help you, but I'm sure there are others here that could. Can someone with more VB experience than myself give Skittles a hand?" I know that doesn't give you the opportunity to slag on a programming language you know nothing about, but it's the right choice regardless.

g.

[Pete Dowson]

Pete: Instead of denigrating the guy's choice of development language

You are not reading properly, it was not commenting on his choice, just me being honest that I don't like Basic (I did also actually say Basic, not VB, though they are of a family)..

I know that doesn't give you the opportunity to slag on a programming language you know nothing about

That's where you are wrong. I actually wrote my own Basic interpreter long ago, in the early days of PCs. And although I also said it was my opinion it is a fact that it was designed to try to let non-programmers construct programs. Even the name reflects this, deliberately. It isn't a put-down or denigration. Many folks are experts in fields other than programming, they don't wish to be known primarily as a programmer (like me).

Please do try to read what is written not your wild interpretations.

Pete

[genebuckle]

Your knowledge of BASIC is decades out of date. As far as I'm concerned, so is your opinion of it.

Your statement:

"I don't like Basic at all, but then I'm a programmer. It is intended for non-programmers."

Doesn't sound like an opinion to me, it reads like a slap in the face to people like me, who are professional programmers that use any one of the modern implementations of BASIC in their day jobs.

30+ years ago BASIC was intended as an introductory programming language, much like early dialects of Pascal. It's evolved WAY past that over the intervening years.

FYI, here's a great example of a "real" program - http://www.shopbottools.com - They make what is probably the world's most popular CNC routers. The control software is world class and written in *gasp* VB6.

Professionals have the option of picking the "right" tool for the job. I'd use C for device drivers, Delphi for GUI apps that don't need to rely on heavy DB access and VB.Net or C# if I'm writing a data-heavy customer facing application. Hobbyists will reach for the tool they know best or can afford to buy. It may not be the perfect choice for the task at hand, but if it meets their needs in the end, who cares?

g.

[Pete Dowson]

Your knowledge of BASIC is decades out of date. As far as I'm concerned, so is your opinion of it.

You have your opinions and I have mine. I'm sorry about my phraseology, but the underlying meaning expresses my opinion. It cannot be a slap in the face as there is nothing insulting in it -- unless you care to deliberately treat it that way. How can believing that the intention of VB was to make it easy for non-programmers to construct programs be a slap in anyone's face? Just because some expert programmers choose it for some purposes doesn't make that untrue!

I suggest this thread is terminated as it is totally unproductive and really a waste of both our times.

Pete