|
|
Post by Walt Decker on Apr 12, 2021 14:19:03 GMT -5
Trying to load a bitmap with:
LOADBMP "IMAGE", FileName$
where FileName$ is a fully quantified path I get the error from my error handler:
Error string is "index: 2787 is outside of collection bounds"
Error number is 0
What does that mean?
|
|
|
|
Post by Carl Gundel on Apr 12, 2021 15:02:50 GMT -5
Trying to load a bitmap with:
LOADBMP "IMAGE", FileName$
where FileName$ is a fully quantified path I get the error from my error handler:
Error string is "index: 2787 is outside of collection bounds"
Error number is 0
What does that mean? Hey Walt, Is it an actual BMP file? It needs to be instead of a PNG or JPG for example. If it is indeed a BMP file, there are a few BMP file formats that LB doesn't like. Sometimes the easy way to fix this is to load it into MSPAINT and then save it back out. Then try again. -Carl |
|
|
|
Post by Walt Decker on Apr 12, 2021 17:09:56 GMT -5
Yes, Mr. Gundel, it is a DIB format bitmap. I created it with mspaint some years ago (perhaps 5).
However, I resolved the problem by loading it through gdi+
I still have no idea what that error means.
|
|
|
|
Post by Carl Gundel on Apr 12, 2021 23:38:03 GMT -5
Yes, Mr. Gundel, it is a DIB format bitmap. I created it with mspaint some years ago (perhaps 5). However, I resolved the problem by loading it through gdi+ I still have no idea what that error means. Walt, Would you be able to share the file with me so I can try to troubleshoot it? Thanks. -Carl |
|
|
|
Post by Walt Decker on Apr 13, 2021 9:50:01 GMT -5
Here it is, Mr. Gundel. The zip contains test code plus a bmp file. The bmp file resides on a drive letter different from that of LB PRO and 3 levels deep.
|
|
|
|
Post by Rod on Apr 13, 2021 11:21:21 GMT -5
This is your bmp header as Liberty probably sees it with 2786 file size but pixels well outside that range.
bfType =BM
bfSize =2786
bfReserved =0
bfReserved =0
bfOffBits =26
biSize =12
biWidth =1966110
biHight =1572865
biPlanes =53448
biBitCount =51412
biCompress =3502822608
biSizeImage =3570452692
biXPels =3369390280
biYPels =3502822608
biClrUsed =3570452692
biClrImport =3369390280
This is what it should look like
bfType =BM
bfSize =2814
bfReserved =0
bfReserved =0
bfOffBits =54
biSize =40
biWidth =30
biHight =30
biPlanes =1
biBitCount =24
biCompress =0
biSizeImage =2760
biXPels =2834
biYPels =2834
biClrUsed =0
biClrImport =0
So not even the width and height are correctly recorded. It is a 30x30 bmp
|
|
|
|
Post by Rod on Apr 13, 2021 12:16:42 GMT -5
I see there is an OS2 dib/bmp header which is 12 bytes, thats what is probably knocking off the rest of the data. I am not sure Liberty has ever catered for this 12 byte header. The norm is 14 bytes.
|
|
|
|
Post by Carl Gundel on Apr 13, 2021 14:38:50 GMT -5
I see there is an OS2 dib/bmp header which is 12 bytes, thats what is probably knocking off the rest of the data. I am not sure Liberty has ever catered for this 12 byte header. The norm is 14 bytes. As Rod explained, the format of that bitmap is a little bit non standard. I tried my suggestion, which is to load the bitmap file into mspaint and save it back out. Liberty BASIC loaded the resaved file fine. |
|
|
|
Post by Rod on Apr 13, 2021 14:49:43 GMT -5
I used Paint Shop Pro which loaded the original as a .bmp ok but saved it out with the changed header as I posted. So the format isn’t wrong just obscure?
|
|
|
|
Post by Carl Gundel on Apr 13, 2021 14:54:25 GMT -5
I used Paint Shop Pro which loaded the original as a .bmp ok but saved it out with the changed header as I posted. So the format isn’t wrong just obscure? Yeah apparently it's not an invalid format, but it isn't the default one that Microsoft uses. |
|
|
|
Post by Chris Iverson on Apr 13, 2021 15:12:04 GMT -5
I used Paint Shop Pro which loaded the original as a .bmp ok but saved it out with the changed header as I posted. So the format isn’t wrong just obscure? Correct. The Linux "file" utility correctly identifies it as an OS/2 1.x format bitmap. chris@Sayaka:/mnt/c/Users/cjnoo/Downloads$ file BRUSH.bmp
BRUSH.bmp: PC bitmap, OS/2 1.x format, 30 x 30
chris@Sayaka:/mnt/c/Users/cjnoo/Downloads$ file BRUSH2.bmp
BRUSH2.bmp: PC bitmap, Windows 3.x format, 30 x 30 x 24, cbSize 2814, bits offset 54(BRUSH2.bmp is a file I made the same way as Carl; opening it in MSpaint and resaving it.) The biSize parameter actually indicates it perfectly: according to this Wikipedia page: en.wikipedia.org/wiki/BMP_file_format#DIB_header_(bitmap_information_header)12 bytes is the size of the secondary header used by the OS2 1.x and Windows 2.0 BMP format. (Called either BITMAPCOREHEADER or OS21XBITMAPHEADER). 40 bytes is the size of BITMAPINFOHEADER, the secondary header used by Windows 3.x and later. That Wikipedia page also details each header, to extract the proper information from them. (There are also later bitmap formats that include further information than just pixel information.) |
|
|
|
Post by Walt Decker on Apr 13, 2021 15:28:14 GMT -5
As far as I know, none of the API's have a problem with it, open office does not have a problem with it, and mspaint does not have a problem so I am just going to use my work-around rather than loading the bmps into paint and saving them.
|
|
|
|
Post by Carl Gundel on Apr 13, 2021 15:36:47 GMT -5
As far as I know, none of the API's have a problem with it, open office does not have a problem with it, and mspaint does not have a problem so I am just going to use my work-around rather than loading the bmps into paint and saving them. LB5 loads both formats successfully. |
|
|
|
Post by Walt Decker on Apr 14, 2021 8:06:27 GMT -5
"LB5 loads both formats successfully."
That is good. However, LB5 is not available. I hope LB5 has better error facilities than LB4x. Not being able to disable error trapping is a throw-back to beginning DOS programming.
|
|
|
|
Post by Carl Gundel on Apr 14, 2021 8:31:57 GMT -5
"LB5 loads both formats successfully." That is good. However, LB5 is not available. I hope LB5 has better error facilities than LB4x. Not being able to disable error trapping is a throw-back to beginning DOS programming.
LB5 is not ready, true. But it is more and more ready as we go.  Could you be more specific about your error trapping point? Thanks. |
|
