Hey guys,

Wonder if you could help.

I need a simple guide how to "pack" and "unpack" LFS packets. I dont want to use a pre-written lib before someone suggest it .

Hey,

If you're starting off with a new language, I'd go straight to VB .NET, or even better, C#

Why would you pick a UF1 when you can have a XRR?

Because ive got prior knowledge with VB6 - I just dont know how to decode/encode the packets - as ive never had to do that before with VB6

I'm not sure how to help you with your question but I advise you to run far and fast from VB6, or anything with VB in its name for that matter. The sooner you make the switch, the better. If you've already got some coding experience, learning a .NET language or Java is merely a matter of understanding OOP ideas and learning a new syntax. Sure, the former may take some time but in a few days you'd have a good enough grasp of the idea (I recommend Bruce Eckel's Thinking in C++/Thinking in Java as they make you understand the concept well in no time - they're free and downloadable books) to match your old coding pace and the latter is just a matter of getting used to it, not really learning anything.

Quote from Krammeh :

Because ive got prior knowledge with VB6 - I just dont know how to decode/encode the packets - as ive never had to do that before with VB6

You will need to call windows API calls to send and receive data that far below what VB can see.

This is where things get down and dirty with VB. You will need find the API's you need to interact ith the network stack, what DLL's they live in. Then you need to declare the function wrappers to call the API functions. You will need callback functions for async operation and will need to pack/unpack data from C like data structures. None of which are fun in VB.

I have not looked at VB.NET but the learning curce will be faster than C# and will open far more to you. There is also a .NET object lib kocking about here somewhere with code I believe.

looks like I wil have to take a look at C again. I hate that language. haha.

I love PHP, but its not the best for making GUI applications

I also don't like using the libraries because that means there is a part of the code which I did not write and therefore don't fully understand. To this end, I stripped one library (edit: remembered, it was this one) down and I now manually decode and encode my packets. I know it is not the best programming practice, but I understand the code and, imho, it is easy to understand.

Here is how I encode a simple packet (this is a IS_REO packet that I send to LFS. akgrid is a 3rd party list control):


The main issue with decoding the packets is in converting the bytes to VB6 types. I don't have them all yet, because I don't use some, but is there anything inparticular you are after. I could post the code I use.

Otherwise, do like I did and get a library and work out how it works so you can do it yourself without the library.

Tim

akgrid2 a public type?

Aww, c'mon axus and Woz. VB6 isn't that bad. The main reason people think this is that it's relatively easy and was a lot of peoples beginning language back-in-the-day. This lead to a ton of crappy code from the noobs and you get the bad reputation as a result. VB6 can be a good language if you know what you are doing, and yes it usually involves API calls, which is nicely documented. Check out AllAPI (get the API-Guide if you plan to continue with VB6), VBCorLib, Planet Source Code and of course MSDN. And for a recommended VB6 IDE add-in, I suggest CodeHelp 2.2 and MZ-Tools. (I have an installer for CodeHelp if you have problems)

With that said, if you are new and want to make a big program, don't use VB6. It is a dying language and will not be supported in the future. If you are going to stick with M$, learn .NET and/or C# (yes, I know about mono) but my recommendation is C/C++ or Java. They are powerful, will be around for a while and with something like WxWidgets for C/C++, cross-platform is a little easier.

So anyway, for the VB6 pack and unpack.. you can see my method in that VB6_ISE t1ger linked to. I might update that for InSim 4 btw but the un/pack method will mostly be the same. Check that out for ideas and if you continue on with VB6 and need help, well hopefully I can answer.

FYI, the VB language is not dying. It is fully supported is VisualStudio.NET.

The Java/.NET platforms are pretty much identical in terms of what they bring to the table, except the Java platform is more cross-platform, but there are options such for doing .NET cross-platform such as using Mono, and if a GUI is needed WxWidgets .NET wrapper, etc. Both are just as powerful as the other. Besides those two there are other virtual machine paradigm platforms available depending on your needs.

There is absolutely zero need for doing C/C++ anymore unless you are writing drivers or performance oriented (such as low-level APIs, databases, graphics engines, etc.) software and even then in many cases its not always a cut-n-dry advantage over virtual machine based paradigms.

Gotta pick and choose based on you (or your project/team/etc.) needs and what best fits those needs, not just accept that X is bad because someone said so.

But yes, the InSim structs only state what part of the byte array make up what data values. So what you need to do is take the byte array and pull out the relavent parts, such as bytes 5-12 of the IS_VER packet and convert that into a string. There might be a method in VB that does this for you, or you may need to do it yourself. Word, etc. types are a bit tricker. Seems, from a quick glance, Stuff's VB code has working examples of this.

In LFSLib (as far as using VB in VB.NET), sd plays some games with unmanaged code to basically take a byte array and copy it into a structure. See the GetBytesSequentially() method of the PacketFactory class.

As far as *not* using libraries; there are pluses and minuses to this.

A minus is you are re-inventing the wheel so are putting a lot of
time and effort into something that if you put your time and effort into your codebase that furthers your goals.

Sometimes re-inventing the wheel is good if you feel you can do a better job than someone else. Which is why there are so many dang 3D engines, or as an example in open source world so many logging libraries, etc. for any number of languages. Most programmers frankly have a "if not invented here" syndrome.

Plus in not using them is then you pretty much have written everything you are going to need from the ground up so you should have a great knowledge of whatever you are attempting to accomplish.

But really the bottom line is that just about everything is a library of some sort. All the languages, they are really *just* a library for spitting out machine code.

Quote from Hollywood :

FYI, the VB language is not dying. It is fully supported is VisualStudio.NET.

What I meant (and said?) was VB6/Classic is dying, not anything .NET. Both VB language but very different in terms of operation.

Everything else I agree with. Overall, depends on what you want to do and are most comfortable with.

hmm. I can encode a packet now, and it sends just loverly.

Its just receiving a packet, I've got NO idea how to decode it.

the data I get is: ôý
and: ôý

Quote from Stuff :

Aww, c'mon axus and Woz. VB6 isn't that bad.

I have used VB from version 3 onwards. It is a great language when you use it for the task it was intended. I even spent a lot of time working with system hooks and message pumps and other real low level stuff in VB terms. Yes you can do it but you know you are pushing when mistakes need system reboots.

Thing is, MS never designed it for "low level" stuff. By that I mean below the stuff covered by VB. That is why many Controls are written in C++ and similar languages but wrapped in COM to allow VB to talk with them. When you need to get dirty with the windows API then other languages are better suited.

VB.NET really is better suited to modern development requirments but while it shares the VB name and has similar looking syntax to VB6 its relationship to VB6 is the same as C# to Java in my eyes.

Quote from Krammeh :

akgrid2 a public type?

Its just a list control that I use instead of a ListBox, however recently I have been favouring the ListView anyway. Just imagine it is a list.

Quote from Krammeh :

hmm. I can encode a packet now, and it sends just loverly.

Its just receiving a packet, I've got NO idea how to decode it.

the data I get is: ôý
and: ôý

OK, start at the beginning then, this is how I decode the response to the InSim ISP_VER:

Firstly, I assume you have the packet recieved and fully checked to ensure you have a full "LFS packet". So you will have an array of bytes with a length of 20 bytes. So byte 0 = 20, byte 1 = 2.

To get LFS version and product use this


Tim

okay, this is what ive got.

Dim T as String

socket.Getdata T

txtlog.txtlog = txtlog.txtlog & T


work from that, so I can work it out?

Is that in your _DataArrival sub?

If it is, then I don't think you are best working with the bytes in a string like that. This is my DataArrival routine:


The checkdatain routine checks to make sure the right number of bytes has been received and if not splits it up into "LFS packets" or saves it and waits for more to be recieved. That last bit of code I posted is part of a "processpacket" routine which is called by checkdatain when it gets a full and complete LFS packet. The "processpacket" routine is just basically a big CASE statement which checks the second byte to see which LFS packet it is.

Tim

okay, so I need to make a buffer, im guessing.

InSim packets are not all one length though, so how you can possible split it into correct packet sizes?

Does the InSim send the same peice of data at the end of every packet (ie vbcrlf or something silly)

No, the very first byte is the length of the LFS packet and the second is the LFS packet type.

So if you receive (physically) 20 bytes, and byte(0) = 20, then you know you have the full packet. Then you check byte(1) to see what type of LFS packet it is. In this case it should be 2 as that equals ISP_VER.

Edit: also remember LFS is sending you (and expecting from you) bytes, so an integer is broken down into 4 bytes which you have to convert to a type that VB knows how to deal with. Characters are easy because they are just 1 byte anyway and that corresponds to their ASCII value. ie 97 = a. This is why working with a string is not the best way, but it does work in places.

Tim

ah yes, never thought of it that way.

Okay, going to take a crack out of it.

Do you have MSN or something?

Also remember, that LFS can send more than 1 LFS packet in an actual packet. For example, you may receive 40 bytes, but byte(0) = 20. This means the rest of the packet is another (or more) seperate LFS packet (or packets), so byte(20) could = 4 and those 4 bytes are and IS_TINY for something else.

There is also the really horrid version where you don't get enough data in the actual packet. I have had this 3 times in all the time I have been playing with InSim v4 and I have yet to write the code to deal with it.

Basically, you would get 13 bytes actual, and byte(0) = 20. This means you have to wait for the next receive event to fire and add the first 7 bytes onto the end of the last set of bytes, and then deal with the next lot.

I haven't worked out yet where I want to save the first lot and I haven't yet worked out how to test it. As I say, it has happened to me 3 times now so I know it is possible, but I program by trial and error and with it only happening every so often, debugging and getting it working would take ages. So I haven't bothered yet. But I will..... soon...

Tim

Re-using this thread as google isn't being very helpful today:

I want to create a type that contains dynamic arrays. Is this possible? I can set the array as dynamic but then get a "not array" error when trying to redim it?

From what I remember with VB (from a good number of years ago, I will point out), I believe you need to do something like this:


If I'm teaching you to suck eggs, hit me In which case, is the variable in scope, etc.? The simplest explanation is often the correct one..

If not, would a dictionary object not suffice / be easier to use? (Or are they not available outside of VBScript?)

I see I've not explained myself clearly. I won't hit you though.

I'm trying to use a dynamic array within a type (aka structures in most languages)

e.g.:

The following code does not work:

I seem to have found a solution (although I've yet to test it) using the Variant type, although I try to avoid using variants wherever possible, seeing as no other language supports them.

Edit: Variant method looks less hopeful now I've read more...

Quote from Bob Smith :

...


Public Type Something
A As Long
B As Long
C() As Long
D() As Long
E As Long
F As Long
End Type


The following code does not work:


Dim Example As Something
ReDim Example.C(5)


...

How bizarre, this code works for me (except I had to declare the type as PRIVATE). Other than that I have done the following:


and get two message boxes, one which says "5" and one which says "7".

Edit: just re-read your post! It works for me, allows me to redim it OK.

Tim

Actually, I was being stupid. Using my example above I was trying to ReDim B, not C. :doh: In my defense, B and C have more similar names in the real program.