tab control: images on tab label

[dummy_decoy]

is there a way to programatically change the image appearing to the left of the label of a tab page ? SetTabPageAttribute() does not define any attribute concerning images.

also, how are those image displayed ? it seems the image always has the same width and height, regardless of the size of the font used for the label. also, the image seems to be resized to always fit this width and height, without any respect for the aspect ratio of the original image. so what are the constraints for those images ?

finally, is there a way to set the height of the tab header without having to grow the font ridiculously ? (same question for the ring control by the way).
for the curious: i am trying to design an interface for a touch screen. controls should be big enough for a finger to fit. people may have big fingers, but they are not blind !

[Peter_Prinzen]

as far as I know, You can use "SetCtrlBitmap" to set an image to a tab.

for your other questions, I'm also interested in the answers...

[jared]

1) SetCtrlBitmap will programmatically change the image of a tab page.

2) The image height and width are 16 pixels, and currently cannot be changed.

3) The image is stretched to fit the 16 X 16 pixel rect.

4) The tab header height is determined by the font height.

Sorry that these aren't the answers that you were looking for. You could submit a product suggestions.

- jared

[dummy_decoy]

thanks a lot. the documentation for SetCtrlBitmap does not mention the tab control, nor the tab control does mention SetCtrlBitmap. at least now the constraints on the tab headers are clear. i finally resorted to the use of toggle buttons instead of tabs: not quite the same but it should be ok for now.

i may submit a product suggestion, i don't know if what i expected does really represent what people are expecting... i may start by submitting a product suggestion asking for documentation improvement.

[LuisG]

Hello dummy_decoy,

When trying to find out which functions operate on which types of controls, good help topics to check are the Library Reference>>User Interface Library>>Controls topics. Each control type has help topics that list all the functions, controls, and events that are supported by that control type.

You can also right-click on a control in the UI editor, and select Control Help, which will take you to these topics.

The "Tab Control Functions" help topic does mention SetCtrlBitmap. And the SetCtrlBitmap function help does mention the tab control (in the imageID parameter help).

Luis

[dummy_decoy]

LuisG, you are right, i overlooked the function list and did not catch SetCtrlBitmap.

anyway, given all the constraints listed above, a small paragraph about images in "Programming with Tab Controls" would be welcome. same for SetCtrlBitmap which does not list any of its control type-dependent behaviors: like stretching the bitmap to always fit it exactly inside a picture control. i always found documentations coming from NI are lacking precision, especially regarding input parameter constraints.

(and i let aside the documentation for imaqTranspose(), which as clearly as it is written in the documentation "transposes an image", this i could find by myself reading the function name. good luck to anybody who does not know what a transposition is...)

[JumperBones]

Luis, I have a related question...

Is there anything in the documentation that tells you anything about the ideal *size* and *format* of the bitmap image that would work best when setting the control bitmap using "SetCtrlBitmap" on CVI's new tab control?

(ideal in the sense that the image you programmatically push into the tab will not become visually altered, or at least not altered too much)

For example: is it a 16 x 16 pixel size in a standard *.BMP format?

Also, was it by design that the image overlaps the top of the tab by about 1 pixel? 

Or is it that my icon image I'm starting with is too big (it starts at 32 x 32 pixels in my example below).

Thanks,

JB

[LuisG]

Hi JB,

Concerning the image format, it makes no difference what the original format is. Once you call GetBitmapFromFile, and the bitmap becomes an in-memory object, any connection with the original format (BMP, JPG, PNG, etc...) is lost. The only connection to the original format might be if the image has a transparency mask (typically, ICO files) or an alpha channel (PNG files). But you can always set and unset those programmatically. And there are no other inherent characteristics of each format, such as color depth, size, etc, that would be a factor in this. So the format really doesn't matter. But I suppose one would expect images in tabs to be smallish, such as the images in menus or toolbars. Therefore, I would expect that most users would pick ICO files.

As far as the size is concerned, as Jared said earlier, images will be rendered in 16x16, regardless of their original size, and regardless of the label font size. I see your point, in that if you tried to display a 1024x1024 image, it probably wouldn't look very good -- but I wouldn't go as far as saying that you have to pick a 16x16 image to display. Bitmap compression is such that 2:1, 3:1 or even higher reductions might look perfectly fine. So there really is no hard-and-fast rule for what the size of the original image should be. But I'll make a note to add to the documentation the fact that final image size is 16x16.

And yes, I just noticed that there is a 1-pixel overlap between the image and the highlighting of the tab, when the tab is the active tab. This is not related to the original size of your image. But it might not be noticeable if the top part of your image is transparent (which is the case with a lot of icons). You ask whether this is intentional or not. There's been a spirited discussion here in CVI-land this morning, concerning the acceptability of this overlap, so I can't give you an objective answer: it depends on whom you ask . This hadn't come up before, but we're going to re-evaluate it and then make a final decision as to whether we're going to change this or not in the next version.

Luis