searching a file for matching data
in [Visual Basic]
|
Prev: Linux
Next: The BIG Picture (VB vs the OS)
From: Mike Williams on 27 Jan 2010 20:03 "Larry Serflaten" <serflaten(a)usinternet.com> wrote in message news:OhPUkL7nKHA.5464(a)TK2MSFTNGP02.phx.gbl... > A bit late (I've been on vacation) but I thought I would > add a second method for those looking to do the same. > Quite simply, put the file data in a byte array, and the > search bytes in a byte array, then use InStrB to find > their location. InStrB will compare byte-for-byte just > like InStr compare character-for-character. Well, well, well! I knew that InstrB picked out individual bytes in a string, but I never actually used it bcause I really couldn't see the value of it, at least for the things I usually do. But I never knew you could use it to find one set of Byte array data inside another! Very interesting. I've often had the need to do that and I've written byte by byte comparisons to perform the task! I think I'm gonna have to get a timer on it and see how much I've been missing! Now if only my old brain was still capable of retaining new information I could leave it at that, but of course at my age it isn't so I'll have to put it in my little database of "things I learned since my brain filled up" ;-) Thanks Larry. Mike
From: argusy on 28 Jan 2010 03:22 Larry Serflaten wrote: > "argusy" <argusy(a)slmember.on.net> wrote >> I'm having a seniors moment (63 tomorrow, that's in 13 minutes time, btw) >> >> I'm trying to open a jpg file, find the position of "FF C0 00 01 08" and get the >> next four bytes of info. (width and height of said jpg) >> >> That data never stays in one fixed spot, so I have to find it. >> >> Seniors moments are a pita, and I can't remember how to do it. >> I could go through all those books I bought on VB6, but I'll bet you I won't >> find what I want until next week, or next month. >> >> Anyone interested in giving me a hand with the code? > > > A bit late (I've been on vacation) but I thought I would add a > second method for those looking to do the same. > > Quite simply, put the file data in a byte array, and the search > bytes in a byte array, then use InStrB to find their location. > > InStrB will compare byte-for-byte just like InStr compares > character-for-character. Also, those functions (InStr & InStrB) > accept byte arrays in place of strings for their parameters. > > LFS > > Thanks, Larry. That's what I was thinking of, originally. I'll try modifying nobody's "bludgeon it with a large rock" code (which works fine) to see what happens. At least I'm now getting the width and height of a jpg file. I just wish these jpg, exif, jfif programs would all do the same thing when they edit a jpg. (well they do, actually - it's that 'FF C0' marker that seems to pop up anywhere from 256 bytes from the SOI, to several hundred later). Graham
From: Larry Serflaten on 28 Jan 2010 04:29 "argusy" <argusy(a)slmember.on.net> wrote > > > Thanks, Larry. That's what I was thinking of, originally. > I'll try modifying nobody's "bludgeon it with a large rock" code (which works > fine) to see what happens. At least I'm now getting the width and height of a > jpg file. I just wish these jpg, exif, jfif programs would all do the same thing > when they edit a jpg. (well they do, actually - it's that 'FF C0' marker that > seems to pop up anywhere from 256 bytes from the SOI, to several hundred later). If you're grabbing only the header info, might you limit your buffer to 4K or 8K? I would think that should go quicker than loading up the whole (100K +) file.... LFS
From: argusy on 28 Jan 2010 07:32 Larry Serflaten wrote: > "argusy" <argusy(a)slmember.on.net> wrote >> Thanks, Larry. That's what I was thinking of, originally. >> I'll try modifying nobody's "bludgeon it with a large rock" code (which works >> fine) to see what happens. At least I'm now getting the width and height of a >> jpg file. I just wish these jpg, exif, jfif programs would all do the same thing >> when they edit a jpg. (well they do, actually - it's that 'FF C0' marker that >> seems to pop up anywhere from 256 bytes from the SOI, to several hundred later). > > If you're grabbing only the header info, might you limit your buffer to 4K or 8K? > I would think that should go quicker than loading up the whole (100K +) file.... > > LFS > > Doh!! Yeah, why add the lot. Most of the JPG files are around 30K, with some up to 50K I use Paint shop Pro a lot (because I bought it years ago), and the damn program wipes the Windows comment if I edit a JPG in any way. Windoze Paint leaves the comment alone. (right click on a JPG, select summary and add a comment. Then change the windows folder display to show comments). I'm working on that as well. Graham
From: Nobody on 28 Jan 2010 14:31
"Larry Serflaten" <serflaten(a)usinternet.com> wrote in message news:OhPUkL7nKHA.5464(a)TK2MSFTNGP02.phx.gbl... > Quite simply, put the file data in a byte array, and the search > bytes in a byte array, then use InStrB to find their location. > > InStrB will compare byte-for-byte just like InStr compares > character-for-character. Also, those functions (InStr & InStrB) > accept byte arrays in place of strings for their parameters. I didn't know that InStrB takes byte arrays. It's clearly undocumented. All it suggests that the input is String. I tested InStrB against the function I posted, and InStrB is faster in all cases that I have tested. It's speed was not affected if running in the IDE, or the EXE. When all optimizations options enabled, InStrB is faster by 2.3 times in the EXE, or 5 times faster with optimization disabled(default). In the IDE, it's 33 times faster. I used 100MB array, and InStrB took 202 ms to scan it on a 2.4GHz CPU. |