|
Hello everybody,
I'm new to VB 2008 and need some advice on formatting of different data types in a list box. The result is confusing for me, but still I guess it's easy for someone with more experience.
The retrieved values seem to be positioned well, as I figure when I see that the 100th value - a string - gives me the expected (readable) result. But - trying and studying and trying and searching sources - I can't find out how to format the DWORD and BYTE Types so that they show me correct results in my list box... EDIT: As I just found out, it's important to mention that the file(s) header use BIG-ENDIAN order while I'm working on a PC.
I'm afraid I'm messing up several issues  At least it seems to be the completely wrong way to just "ToString" the resulting variables..
Result examples:
- A file of 8.302.592 bytes shows me a filesize of "11566592" (and maybe that's even the size stamp in the header? I really can't tell..).
- A TimeCode of 06:00:42:11 shows "289538054"
Do I probably miss any transformation issues? Or is something generally wrong wit my code? How can I format these values properly to be a readable format???
Here's what I do:
In a small project class I use a binary reader to read the header of a bitmap file into variables of data types BYTE and DWORD (which is obviously UInt32 in VB?).
</code>
'Variables (excerpt):
Dim hByte As Byte = Nothing
...
Dim hDWORD As UInt32 = Nothing
</code>
The Header is read with statements like:
<code>
'Read the header (excerpts):
hString = br.ReadChars(4)
.pictype = hString
hDWORD = br.ReadUInt32
.fileoffset = hDWORD
'...(etc)
hDWORD = br.ReadUInt32
.TimeCode = hDWORD
</code>
With the resulting variables I fill a listbox:
<code>
With lstBox
.Items.Clear()
.Items.Add("PicType: " & struct.pictype )
.Items.Add("ImageOffset: " & struct.offset) 'DWORD
.Items.Add("File Size: " & struct.fileSize.ToString & " bytes") 'DWORD
.Items.Add("Version: " & struct.version)
.Items.Add("SMPTE TimeCode: " & tv.TimeCode.ToString) 'DWORD
...
End With
</code>
Could someone please help me jump over that hurdle?
Thank you, kind regards
Michael
<div class="ForumMod">modified on Tuesday, September 23, 2008 2:29 AM</div>
|
|
|
|
|
Hi Michael,
So lets see if I get this straight:
Michael Schäuble wrote: hDWORD = br.ReadUInt32
.TimeCode = hDWORD
You read certain bits from the file into a variable of type Int32 and then you assign it to .TimeCode
I am going to have to assume that .TimeCode is a property of a class (tv ?) that you wrote yourself, and that the type of this property is int32.
In the listbox you get the value back from this property with ToString. ToString indeed just returns the string representation of your int32 value.
In other words, you'll have to convert the int32 value you got from the file to a DateTime value first in your tv class, before you use ToString("mmss") to show the string representation of the time value.
Same goes for all other similar conversions.
Hope this helps you,
Johan
My advice is free, and you may get what you paid for.
|
|
|
|
|
Thank you Johan,
you got it straight, and you recognized that I'm struggling with the data types  Perhaps it helps if I explain a bit better, but due to my still lacking capabilities please excuse (or correct) any errors:
I'm trying to read/write the header of a dpx (picture) file which has a fixed structure. Following the SMPTE definition, many values (e.g. "tv.timecode") are stored in a DWORD (which would be UInt32 in VB). And when I examine the timecode-position in a HEX-Editor, I see the Bytes "06-00-42-11" stored for the timecode "06:00:42:11". Btw: Since it's stored big-endian, meanwhile I wrote a function to swap the bytes first (there really doesn't seem to be a VB standard function), so the line now is
hDWORD = SwapDWORD(br.ReadUInt32)
.TimeCode = hDWORD while the "buffer variable" hDWORD is still UInt32 and converted afterwards in a listbox:
.Items.Add("SMPTE TimeCode: " & CDate(tv.TimeCode))Unfortunately VB doesn't let me convert to what I need (and you suggest), so the above line throws an error saying "UInt can't be converted to DateTime" (as far as I read this would need Double / 8 bytes). A "CTime" function doesn't seem to be available. Still I have only 4-bytes...
Where's that big tomato on my eyes???
|
|
|
|
|
In addition, one more formatting question arose:
The definition says that undefined fields (except ASCII) are "to be initialized to their 'all one' values" (then they give the example code for C: 'WORD val = ~0;'). These fields are BYTE, WORD, DWORD and SINGLE types.
Therefore, from these fields I retrieve the highest possible values as decimals (e.g. 4294967295 for the DWORD / UInt32) and would like to show them as "n.def" in the list field. Obviously I can't store a value like "n.def" in the buffer variable (hDWORD = UInt32, hWORD = UInt16 etc.) which is then assigned to the stored variable (e.g. 'tv.framenumber'). So I'm afraid having to write If-statements for hundreds of entries.
Do you know a more elegant way to show "n.def" in such a case in the VB list field?
|
|
|
|
|
|
Sorry, Johan - so you see it's even hard for a beginner to express clear enough Another try ... and still thank you for your patience:
1. The binary reader reads a value from the file header, the Bytes are swapped (due to big-endian) and the result assigned to a re-usable 'buffer variable' of the relevant size (e.g. hDWORD as UInt32 for a DWORD)
hDWORD = SwapDWORD(br.ReadUInt32)
2. This 'buffer variable' is then assigned to one of the specific variables I have to set (e.g. 'data.offset')
.offset = hDWORD
3. Then step 1 is repeated to read the next DWORD, for which hDWORD is assigned to another specific variable (e.g. 'file size')
Problem: Sometimes the fields in the file (e.g. 'file size') are not set for any reason. In that case, due to header specification, they are 'FFFF FFFF' (DWORD field) or 'FFFF' (WORD field) and result in large decimals (maximum possible value) when reading them.
Goal: If the read value is 'FFFF FFFF' then show 'undefined' in a list box
Was I more understandable this time? Hoping  ...
modified on Thursday, September 25, 2008 8:09 AM
|
|
|
|
|
That was more my speed
The problem seems simple enough (just discussing) you read the value, which will be somewhere between Int32.MinValue and Int32.MaxValue or if the value is FFFF FFFF then it is Int32.MaxValue
So a simple function like:
Private Function OverTheMax(ByVal i32 As Int32) As String
Try
If i32 = Int32.MaxValue Then
Return i32.ToString
Else
Return "Weiss ich nicht !"
End If
Catch ex As Exception
MsgBox(ex.ToString)
Return "Error"
End Try
End Function
should take care of things, and no hundreds of If sentences... ?
Johan
My advice is free, and you may get what you paid for.
|
|
|
|
|
Hi Johan, that sounds like a good solution - at first sight.
With your function I'd only have to change the second line of my (hundreds of) property-reading statements, right?
hDWORD = SwapDWORD(br.ReadUInt32)
.fileSize = OverTheMax(hDWORD)
Some important things make me hesitate:
- My property variables (e.g. '.fileSize') are different types (Byte, Int16, Int32, Single etc.) depending on their purpose. I'd have to re-write your function different (the 'ByVal'-part) for every type, no?
- Plus: For each and every value a data type 'string' is returned, so that I would have to declare all the property variables as string types first, and then re-convert each one to what it was before, using another property variable of the correct type.
I'm not sure if the rewards of 'nicer looks' is worth the cost? What do you think?
Thanks
Michael
|
|
|
|
|
You are right, you will have to rewrite this function a little bit.
Fortunately you wouldn't have to actually write byval statements for each different datatype, and you could still manage with a single function by using the Object data type. This type accepts pretty much anything and can return anything.
In other words something like this:
Private Function OverTheMax(ByVal o As Object) As Object
However you would indeed have to write conversions in the function for each conversion necessary.
Michael Schäuble wrote: I'm not sure if the rewards of 'nicer looks' is worth the cost?
That question only you can answer. In your original post, you only said you wanted to display the values in a ListBox. In that case converting everything to strings before you put it there sounds like the best way to me. If you also want to do calculations on these values or manipulate the file, or something like that, you would have to adapt this function accept any data type as input and to output any data type, for example using Object or an array of type Object.
My advice is free, and you may get what you paid for.
|
|
|
|
|
Using object types sounds like an interesting option...
There's a lot to explore, indeed.
Thank you for the inspiration and patience,
and have a nice day!
Regards
Michael
|
|
|
|
|
Coming at you...
But seriously, the problem is that (at least) VB handles only the DateTime type and does not have a separate Time type. As your value appears to be only a time stamp, you will have to first add a (dummy) date part to the value and then extract the time part from the DateTime value, which seems a bit much.
One way (not saying that it is the best way) would be to interpret it as a fixed length string. If the HEX editor reads 06-00-42-11, then you can supposedly retrieve that value from the file "as is".
Next a simple function to replace all -'s with :'s, and Bob's your uncle.
At the same time, assuming that the values are int32 and therefore letting VB convert them to that type, might actually cause some of these funny return values you spoke about.
The other alternative would be to search Google or ask here on the forum about conversion of bytes to other data types (between you and me, not everybody here can (or is willing to) deduct the basic question, when you surround it with too much context). Because, to be honest, I have very little (read no) experience with bytes and DWORDs, etc.
Good luck,
Johan
My advice is free, and you may get what you paid for.
|
|
|
|
|
Thanks for the tip. I'll try to post it in a shorter way and hope someone answers without asking for the context  then...
Have a nice day!
|
|
|
|
|
Hello everybody,
this question sounds simple, yet I couldn't find a better performing way to count the files in folders / subfolders than to make a (countable) string collection with GetFiles(Path, [..etc.]), which is obviously generating an huge list for every folder / subfolder unnecessarily.
Does anyone here have a better idea and can inspire me? I'm new to VB 2008 and need a little guidance.
Thank you,
Michael
|
|
|
|
|
Use the following code for counting number of files in a folder...
dim fol as string="Your folder name"
for each count as integer in My.Computer.FileSystem.GetFiles(fol)
count+=1
next
Now count will have total number of files in the folder fol.
Gagan
|
|
|
|
|
Thank you Gagan, but maybe I haven't expressed my question well.
The code you suggest is exactly the code I'm using
Looking at the performance side of the GetFiles method, a programmer in another forum here looked at my code and wrote "That will create a list of strings that you just throw away, as you only use the size of the list. You should implement a method that loops the folders and counts the files, so that you don't create that huge list just to throw away."
Unfortunately he didn't let me know what "implement a method..." would mean - no further answer came, and more insecurity stayed  That's why I reduced my question to that point only, in order to find someone else willing to tell me which other methods would exist for the purpose.
I appreciate your will to support me,
have a nice day!
|
|
|
|
|
That will result in a number twice the actual number of files in the folder.
You really have no choice but to use GetFiles since there are no other methods of getting/counting the number of files in a folder.
|
|
|
|
|
Thank you, Dave, for clearing that up!
Meanwhile, I think I found out the difference from your suggestions to my code - and that could have been what the other guy had meant. In my code I didn't define "count" as integer but with (varname changed to "count"):
Dim count As System.Collections.ObjectModel.ReadOnlyCollection(Of String)
I'm going to change that and have a look at performance again 
Thanks a lot to both of you!
Michael
|
|
|
|
|
|
Could someone tell me the name of the "this" pointer in Visual Basic?
Sorry to post such a beginner question, but do you know how hard it is to do a search on the word "this?" ;o)
|
|
|
|
|
|
Use the Me keyword.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
I have an app I'm working in which I need to update GUID references based on directory/version. Currently, I can get the current GUID for a dll using TLBINF32. In order to get the GUID, the location of the .DLL must be specified.
Is it possible to determine the GUID based on name only (without specifying the file path)? Something like: GetGuidINFO("somefilename.dll") in which the registry would return the appropriate Guid?
This would be ideal since the location of the .dlls could vary on a system to system basis.
Any suggestions, ideas, or 'constructive criticism' are always welcome.
|
|
|
|
|
Any ideas on this?
Any suggestions, ideas, or 'constructive criticism' are always welcome.
|
|
|
|
|
Show some patience. We get to question on OUR time, as volunteers, not on yours. Personally, I've been in meetings all day, so this is the first I'm seeing this.
No, it's not possible to do that, unless the .DLL is in the CurrentDirectory. The problem with CurrentDirectory, though, is that you cannot depend on it to be pointing to any particular directory at any time. It can change, with or without, manipulation from your code.
But, building fully qualified paths to files is also best practice.
|
|
|
|
|
Dave Kreskowiak wrote: Show some patience. We get to question on OUR time, as volunteers, not on yours. Personally, I've been in meetings all day, so this is the first I'm seeing this.
No, it's not possible to do that, unless the .DLL is in the CurrentDirectory. The problem with CurrentDirectory, though, is that you cannot depend on it to be pointing to any particular directory at any time. It can change, with or without, manipulation from your code.
Sorry Dave, didn't mean to come off as impatient. Was hoping I was asking the question in a clear way.
Roger on CurrentDirectory and fully qualified paths.
Thanks!
Any suggestions, ideas, or 'constructive criticism' are always welcome.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
