Recent posts

#71

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 08:24:16 AM

If you're going to edit a BMP, then use a graphics editor (like Paint Shop Pro here), not a stupid  hex editor.

Well thats all  I could think of, to see the bitmap data.     Carry on.

#72

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 08:15:37 AM

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

Personally, I would use a hex editor myself. But you never know about anyone else.

Sure, one could use a hex editor. But you'd have to work out where the BMP header ended, where the palette data was, where the bitmap data started, all that. The motivation for this was to display all that data without having to wade through the hex dump.

Maybe this tool could/should use a hex-dump format in displaying the palette and bitmap data? Maybe even allow editing? Ugh; lotsa lotsa work there.

No, I think I'll stick to read-only for this version at least. If you're going to edit a BMP, then use a graphics editor (like Paint Shop Pro here), not a stupid  hex editor.

Anyhow, I'm open to suggestions.

#73

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 08:10:32 AM

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

Personally, I would use a hex editor myself. But you never know about anyone else.

Speaking of hex editors, I had played around a bit with trying to write one years ago. The trick to that is to not try to display all the data at one time, but only portions of it from a small buffer... if I can find that half finished code, I might post it some day. Later: I looked for it, but did not find it.

#74

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 08:09:18 AM

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

#75

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 08:05:35 AM

OK, dynamic memory allocation it is. I told those damned code monkeys they needed to do this, but they thought I was being silly.

Give me a couple hours here.

[did finish]

#76

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 08:03:35 AM

Larry: could you test this again with that file that showed a bitmap size of 0? I added code to show the actual size in that case.

Program says: "File is too big (> 2 MB)".
It is a 5.93 MB size file.    You never know just how big a user will use the program on.

For the 256 color version of the same bitmap, the report window says... "Wait..." and I am still waiting.    It does show a miniature of the file, though.

edited later -->  It did finish and display after quite some time.

Both of those files are attached above  (the zips in post #3), for your own testing...     error correction: I orignally wrote post #8, its in post #3

#77

The Workshop / Re: A useful tool: BMP data vi...

Last post by sinsi - November 22, 2024, 07:58:40 AM

File is too big (> 2MB).

Really? Why don't you dynamically allocate memory? 2MB is on the small size for an uncompressed BMP.

#78

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 07:49:16 AM

OK, latest version here.
I've pretty much fixed the unresponsiveness problem. Pretty much, but not completely: using a really big BMP (1.8MB), it goes catatonic for maybe 8-10 seconds. Not perfect but better.

Not sure what I could do to remedy this. One thing I do is to display a "wait" message in the edit control, so at least the user has some clue as to what's going on. But I really don't like that "freezing" ...

Larry: could you test this again with that file that showed a bitmap size of 0? I added code to show the actual size in that case.

Thanks to everyone for their patience! I'm trying to get the code monkeys here at NoCforMe Laboratories, GmbH, to be a bit more careful in releasing code ...

#79

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 07:09:03 AM

Also for larger 24 bit bitmaps, displayed bitmap size = 0. Which obviously is wrong.

Actually, no, that's correct: I'm reading the bitmap size from the BMP header, which can set that field to zero.

It seems wrong though, or at least misleading. Maybe you should use "Header bitmap size" for size that was read from the header, and a separate listing "Actual bitmap size" displaying the actual size of the bitmap. This would help to avoid any confusion.

#80

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 06:51:47 AM

Thanks for all comments so far.

Yes, I realized there was a massive problem with how long things took for really large BMPs (as well as another buffer not large enough). Which has prompted me to revamp how I display all that bitmap info.

Currently I'm just writing all that text to the edit control directly. Now, even though I bigger-ized the edit control's text buffer (by using the EM_SETLIMITTEXT message), if you watch the program's progress with Task Manager you'll see a slowly but surely increasing memory usage as the edit control tries to cope with all that incoming text. Not a good arrangement (which is also why the program becomes unresponsive).

So what I'm going to do instead is write all that text to a buffer, then at the end dump it into the edit control all at once. That should solve all these problems.

Also for larger 24 bit bitmaps, displayed bitmap size = 0. Which obviously is wrong.

Actually, no, that's correct: I'm reading the bitmap size from the BMP header, which can set that field to zero. I think that field is only used by compressed BMPs (which I don't handle).

I'll have an updated version soon. Thanks for being my guinea pigs!