It looks like we may have forgotten about this after all sorry mate.
I think I was waiting for S.Varjonen or Solar to answer a question, but I am not in front of my PC which will have all the emails and conversations on it. I will have a look tonight and see if I can sort it out once and for all tonight.
FYI, I have now seen this 3 times in total. However, most of the time it does not happen. I can now confirm that VB6 is not "hiding" me from it and it is possible, just nowhere near often enough for me to successfully write the code to handle it.
Hmmm, how odd. Must be to do with the way VB deals with ReDimmed arrays, ie maybe it doesn't actually increase the size of the original, it just creates a new one and points the old one to the new one or something...I don't know.
How about the following:
Private Type something3 'Length = 24 (no matter what redimmed to) a As Long b As Long c() As Byte d() As Byte e As Long f As Long End Type
Dim Example1 as something3
This is 24 because we know that the four LONG variables are each 4 bytes and it must use one four byte space to hold the variable to be redimmed, thus 6 x 4 = 24.
Don't get me wrong, I *want* the Prius to be as green a car as possible, just like I want all cars to be greener than they are. I just think that (like all things that I don't actually fully understand) there will always be arguments.
I am sure there is a document which argues why the responses to the pacinst.org report are wrong and invalid and shouldn't be believed. Unless I know all the facts, and quite frankly I am never going to, I am never going to know which one I should actually believe is right.
oh dear, getting too deep now
ps just noticed that the Washington Post link confirms that I was right in post #198 above! hey hey, first time for everything
Unless the engineering process and destruction process for the Prius is majorly different to that of a "normal" car, then the fact the the Prius gives out a fraction of the emmisions of the "normal" car, then it must gain something. Even though in the bigger picture this is not as much as if you just take the emissions of the car running into account.
Plus, how do we know that something else the Prius is doing (emmitting, causing, anything really) is not damaging something else that we have not measured or even know about yet. If we all moved NOW to a Prius, we may find that all those hybrid cars cause something else to break somewhere in the environment. (I don't know what, but you know what I mean).
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...
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.
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:
Private Sub myWinsock_DataArrival(ByVal bytestotal As Long) ReDim bytFull(bytestotal) As Byte
myWinsock.GetData bytFull Call checkdatain(bytFull) End Sub
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.
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):
Dim bytData(0 To 35) As Byte Dim loopy As Long For loopy = 0 To 35 bytData(loopy) = 0 Next
bytData(0) = 36 bytData(1) = 36 bytData(2) = 0 bytData(3) = akGrid2.Rows For loopy = 1 To akGrid2.Rows bytData(loopy + 3) = Val(akGrid2.TextMatrix(loopy, 4)) Next myWinsock.SendData (bytData)
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.