 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General / November 2004Anyone have any info on the Delphi bitmaps?
.dfm files (delphi I think) tend to hold bitmap information about delphi forms (I think). The way the information is organized is as follows: Bitmap = { 494C010110001300040010001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600 If anyone has done any research on these and can offer any help as to how it's laid out, that would be great. It looks like the images in an FF format but I don't know if they're organized as 32 bit (4 bytes at a time) or 3 bytes at a time (RGB, BGR ?). Thanks in advance. -- Jim Carlock Post replies to newsgroup. > .dfm files (delphi I think) tend to hold bitmap information > about delphi forms (I think). The way the information is [quoted text clipped - 9 lines] > if they're organized as 32 bit (4 bytes at a time) or 3 bytes > at a time (RGB, BGR ?). From a quick look it looks like a standard .BMP file with an additional header of some description at the start, the Bitmap data starts "424D" (ASCII "BM") followed by a DWord containing the length of the rest of the file (i.e. the amount to read out of the file.) Since it's stored as ASCII though then you'll need to step through each character and convert it back to hex before writing it out to a file opened in Binary mode, and at least here it puts in lots of hard line breaks and whitespace which you'll need to cater for. Hope this helps, Mike - Microsoft Visual Basic MVP - E-Mail: EDais@mvps.org WWW: Http://EDais.mvps.org/ Yeah, you are 100% correct. I pulled the BMP format from wotsit.org and I can see the file identifying itself at that BM mark as a bitmap. Thanks! That's great! I kept looking at the first 10 bytes trying to figure out what those were. It looks like the first two "IL" are probably the initials of the guy that created that header. Everything after the 424D is saying Windows Bitmap. It looks like that dfm file is a Delphi 6 file. I've found some other .dfm files that appear to be from a previous version of Delphi (3 or 4, I think). Those olders one appear to be similar to the VB3 binary files. You use Delphi at all, Mike? -- Jim Carlock Post replies to newsgroup. > .dfm files (delphi I think) tend to hold bitmap information > about delphi forms (I think). The way the information is [quoted text clipped - 9 lines] > if they're organized as 32 bit (4 bytes at a time) or 3 bytes > at a time (RGB, BGR ?). From a quick look it looks like a standard .BMP file with an additional header of some description at the start, the Bitmap data starts "424D" (ASCII "BM") followed by a DWord containing the length of the rest of the file (i.e. the amount to read out of the file.) Since it's stored as ASCII though then you'll need to step through each character and convert it back to hex before writing it out to a file opened in Binary mode, and at least here it puts in lots of hard line breaks and whitespace which you'll need to cater for. Hope this helps, Mike - Microsoft Visual Basic MVP - E-Mail: EDais@mvps.org WWW: Http://EDais.mvps.org/ Hi Jim, > Yeah, you are 100% correct. I pulled the BMP format > from wotsit.org and I can see the file identifying itself at [quoted text clipped - 4 lines] > probably the initials of the guy that created that header. > Everything after the 424D is saying Windows Bitmap. Looking at a .dfm here it's got a Picture.Data = { ... }block and there's 12 bytes of 'stuff' before the "BM" signature so it looks like it's either a variable sized structure, or there are different headers for different image types? The other possibility is that the CreateDIBSection() API call won't load Bitmap data from a mapped file handle unless the offset is DWord aligned so it injects an additional 2 bytes of 0's to align the start of the data. Seems a bit strange through considering that it's stored as ASCII data though, *shrug* who knows :) > It looks like that dfm file is a Delphi 6 file. I've found > some other .dfm files that appear to be from a previous > version of Delphi (3 or 4, I think). Those olders one > appear to be similar to the VB3 binary files. Sounds about right, only got D7 here now but I seem to recall the older versions (pre-D5) used a binary format. > You use Delphi at all, Mike? Yep, all the time at work (their existing development architecture was in Delphi), mostly for DirectX/DirectShow work as you don't have to jump through all the hoops VB forces you to and the "jedi" group has done a good job of porting the DX headers. Still use VB6 and C# for my own development work and utility applications though, sometimes C++ for high-speed DLL's where performance is critical. Cheers, Mike - Microsoft Visual Basic MVP - E-Mail: EDais@mvps.org WWW: Http://EDais.mvps.org/ Close #iFile Open msFileName For Input Access Read Lock Read Write As #iFile I probably should have posted this in a new thread, but perhaps not. This is part of the code that I am using to read the file and get a line count, and then I'm closing the file... and reopening it to restart rereading it. I'll be converting the lines by throwing them in an array. Dim maLines() As String Dim miLineCount As Long '...code ReDim maLines(1 To miLineCount) So I'm really looking for other suggestions and such and if the lines at the top are Okay or if I should put the FreeFile call in again, such as... Close #iFile iFile = FreeFile Open msFileName For Input Access Read Lock Read Write As #iFile Just looking to get a little better understanding of such things. <g> Thanks! -- Jim Carlock Post replies to newsgroup. Hi Jim, > Yeah, you are 100% correct. I pulled the BMP format > from wotsit.org and I can see the file identifying itself at [quoted text clipped - 4 lines] > probably the initials of the guy that created that header. > Everything after the 424D is saying Windows Bitmap. Looking at a .dfm here it's got a Picture.Data = { ... }block and there's 12 bytes of 'stuff' before the "BM" signature so it looks like it's either a variable sized structure, or there are different headers for different image types? The other possibility is that the CreateDIBSection() API call won't load Bitmap data from a mapped file handle unless the offset is DWord aligned so it injects an additional 2 bytes of 0's to align the start of the data. Seems a bit strange through considering that it's stored as ASCII data though, *shrug* who knows :) > It looks like that dfm file is a Delphi 6 file. I've found > some other .dfm files that appear to be from a previous > version of Delphi (3 or 4, I think). Those olders one > appear to be similar to the VB3 binary files. Sounds about right, only got D7 here now but I seem to recall the older versions (pre-D5) used a binary format. > You use Delphi at all, Mike? Yep, all the time at work (their existing development architecture was in Delphi), mostly for DirectX/DirectShow work as you don't have to jump through all the hoops VB forces you to and the "jedi" group has done a good job of porting the DX headers. Still use VB6 and C# for my own development work and utility applications though, sometimes C++ for high-speed DLL's where performance is critical. Cheers, Mike - Microsoft Visual Basic MVP - E-Mail: EDais@mvps.org WWW: Http://EDais.mvps.org/ > I probably should have posted this in a new thread, but > perhaps not. This is part of the code that I am using [quoted text clipped - 18 lines] > Just looking to get a little better understanding of such > things. <g> Thanks! Since VB is synchronous in nature, AFAIK you're perfectly safe using the same file handle for a loop of files since Close won't return until the file handle has been freed (although having said that I generally call FreeFile() before opening a new file just to be on the safe side..) One thing you want to avoid though is too much access to the disk since disk I/O is a very slow task and will severely affect the performance of your overall routine. If on your first run you're reading all the lines in then discarding them then on your second run you're reading everything in again and putting them all into an array, why not simply dump the lines directly into the array on the first run? Better still, create a single buffer rather than having all those strings about and just store offsets to the individual lines within that buffer (strings are again a very inefficient data type, storing offsets as longs is very efficient.) Hope this helps, Mike - Microsoft Visual Basic MVP - E-Mail: EDais@mvps.org WWW: Http://EDais.mvps.org/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.