Graphic Control - how to load without knowing image dimensions?

[Gary Beene]

I want to load an image from a bmp file, without having to specify the final image dimensions, into a graphic control. The result would fill the graphic control, or not, according to the size of the image.

I can do that with an image control, but I want to use a graphic control.

The four basic commands for loading an image into a graphic control are:

- render:     load from bmp/pbr           entire picture         resizable
- copy:       load from existing target   all/part of picture   cannot resize
- imagelist:  load from imagelist           entire picture        cannot resize
- stretch:    load from target              all/part of picture   resizable

I'd want to use RENDER, which reads from a file, but it requires that I specify the final image size.

The other 3 methods don't read from files.

Help provides code that lets me get the image size from a BMP:

nFile& = FREEFILE
 OPEN "myimage.bmp" FOR BINARY AS nFile&
 GET #nFile&, 19, nWidth&
 GET #nFile&, 23, nHeight&
 CLOSE nFile&

But since I don't want to resize, then the steps aren't useful - except that RENDER requires them. I know it's only a few lines of code, but you'd think there'd be a way around them.

So, is there an straight-foward way to load an image from a file into a graphic control without knowing the final dimensions? I'll be loading multiple files and will have a control that's big enough to handle the largest image.

[Chris Holbrook]

Graphic Bitmap Load?

[Gary Beene]

Chris,

Thanks for the comment. I had already written code along the lines of your suggestion, but it didn't seem like much of a code savings. Having to kill the temp memory bitmap and then reattach the target graphic control keeps the lines of code about the same as using the Help example for getting the dimensions directly from the file.

    'select the control, create a bitmap, read the file, copy to control
    Graphic Attach hDlg, %ID_TARGET       'set graphic control as target
    Graphic Bitmap Load "icons/cowgirl.bmp", 0,0 To hBMP
    Graphic Copy hBMP,0 
    'now get rid of the temporary memory bitmap
    Graphic Attach hBMP, 0
    Graphic Bitmap End hBMP
    'now start using the graphic control
    Graphic Attach hDlg, %ID_TARGET       'set graphic control as target

The Graphic Bitmap Load is good because it reads the image, using its real size without me having to know and supply the dimensions.

I would have thought that reading a file, without knowing the size, and displaying it would have been a common enough task that it might have been an option for RENDER, and perhaps the Help didn't tell me. It occasionally likes to keep secrets from me!

[Michael Mattias]

>keeps the lines of [source] code about the same ...

.. which is worth exactly what? (Hint: the answer is 'zero').

Aren't you the same Mr. Beene who recently asked about creating some kind of "one for one, SDK-style to DDT-style source code function equivalence" and there learned that any one DDT or other intrinsic BASIC language statement is conceivably many SDK or machine instructions?

Unless you are really pressed for disk space, the number of lines of source code is immaterial. (And I mean really pressed for disk space).

[Brad D Byrne]

hehe! Michael's at it again!

Gary, don't let Michael's posts get to you, we all have had to go through it!

wait tell you see him criticizing the assembly programmers who know 100 times more than him in assembly!! we just gotta bite the bullet and appreciate Michael for what he does bring here!

[Chris Holbrook]

...it didn't seem like much of a code savings.

Gary, Why not use a function or for faster execution a macro to save your typing finger?

macro mLoadPic(spath,hDLg,lCtlId)
    macrotemp hBMP
    dim hBMP as dword

    'select the control, create a bitmap, read the file, copy to control
    graphic attach hDlg, lCtlId       'set graphic control as target
    graphic bitmap load spath, 0,0 to hBMP
    graphic copy hBMP,0
    'now get rid of the temporary memory bitmap
    graphic attach hBMP, 0
    graphic bitmap end hBMP
    'now start using the graphic control
    graphic attach hDlg, lCtlId       'set graphic control as target#
end macro

[Paul Dixon]

Brad,

wait tell you see him criticizing the assembly programmers

!lea esi,TrashCan
!mov eax,CriticismOfASM
!mov [esi],eax

Paul.

[Gösta H. Lovgren-2]

Brad,

!lea esi,TrashCan
!mov eax,CriticismOfASM
!mov [esi],eax

Paul.

You think that's bad, Paul. Search YouTube for a video ("Real Men Use Rubber") of MachoMan instructing a freshman programming class on the delicate intricacies of creating punch cards using a rubber mallet as opposed to a wooden one . (Tip - look in the 8 track section of YouTube. Much clearer than the shellac platter version available on SmokeSignalHistory.com)

==============================================
When they took the 4th Amendment,
I was quiet because I didn't deal in drugs.
When they took the 6th Amendment,
I was quiet because I've never been arrested.
When they took the 2nd Amendment,
I was quiet because I didn't own a gun.
Now they have taken the 1st Amendment
I can only be quiet.
(Internet)
==============================================

[Gary Beene]

Michael,
Actually, what I said was I wanted to see "side-by-side with the equivalent SDK code". I knew the SDK side would be longer. I never said I actually wanted to use the lengthier SDK tomes (not yet, anyway), I just wanted to understand SDK better so I could understand why the been-here-for-a-while folks were so enamored with it!

The side-by-side comparison is still on my action item list.

Brad - thanks for your comment. I'm rather enjoying watching Michael in action. He's definitely a positive sum game. Whoops - did I say that on a public forum? Please - no letters on that one!

[Michael Mattias]

So you mean you have a 'graphic area' which is a fixed size, and depending on the size of the selected image, it either does or does not get 'filled?"

So create a static control the size of the desired viewing area. Make a nice border and fill it with a nice background color.

As you open graphic files, get the size of the image, then create an image or graphic control the exact size needed, located within the static control (align or center as desired), and fill that control with the image.

>I can do that with an image control, but I want to use a graphic control.

You can (sort of) pound nails with a saw, but you can't cut timber with a hammer.

[Gary Beene]

Yes, and my daddy (who actually was a carpenter) told me that "It's the poor carpenter who blames his tool!"

Sometimes I can't tell whether people in this forum tell me what I want to know, or they tell me what I should want to know. Both can be useful, of course.

I simply thought PB made it harder (take more steps) to load an image of unknown dimensions into a graphic control than I wanted it to be. That Wall guy could have a point, you know.

I was hoping someone would say "Oh, Help forgot to mention it, but if you put (?,?) in for the values of (x,y) the GRAPHIC statement will figure out the image size for you and load the image into the graphic control at full size."

Since that's not the case, I'll just use one of the longer solutions 'cause that's what works.

[Michael Mattias]

"Loading an image of unknown dimensions" involves a lot more than loading an image. It's deciding how you want to show an image which does not fit in some predefined space.

Shrink/Grow? If so, how much horizontally or vertically? Shrink/Grow options?

Clip if too big? If so, where to clip, from the edges toward the middle or start at one corner and show what fits?

Put in some kind of control at full size and provide scroll bars?

You have been given the tools you need to figure out how big that "unknown size" image wants to be... but exactly what to do with that information is, as usual, "application-specific"

[Michael Mattias]

FWIW, you could probably pull off the "multiple choice load and show" above with a minimal number of Windows' API calls... however, each such call would require multiple parameters, and each parameter is going to be variable with multiple constants to specify.

Unless I am mistaken, the whole raison d'etre for the simplified PB instrinsic functions is to eliminate "one complex statement with a lot of parameters and a virtually unlimited number of permutations of same."

Come to think of it, that's the whole reason high-level language compilers themselves exist.

MCM

[Dave Biggs]

..I wanted to see "side-by-side with the equivalent SDK code"...

The side-by-side comparison is still on my action item list.

Gary, Take a look at Borge's WinSpy utility. http://www.powerbasic.com/files/pub/...ols/WinSpy.zip

Once you have created a dialog plus controls using DDT style code you can then use WinSpy to 'capture' it and automatically generate equivalent SDK style code for the same results.