Odd Imageview Behavior

[dlfallen]

I'm working with the 71x96 png files.

I started with the 320x480 default layout and an ImageView1 created in the designer with Width = 71 and Height = 96. I created a new variant of 480x800 to more closely match that of my device. When I did that, the designer changed the dimensions of ImageView1 to 105x144. I guess that makes sense given that I was going from a scale of 1 to a scale of 1.5. In the attached screenshot this is the upper-left image (the image is added in the Activity_Create sub).

Where things get a bit strange is when I created ImageView2 in the new layout with dimensions of 71x96. Despite the fact that in the designer gravity=fill, when I run the code loading the same image into ImageView1 and ImageView2, I get a "zoomed-in" image (see upper-right image in screenshot).

Keeping both ImageViews for reference, in the designer I created ImageView3 at 71x96, and in the Activity_Create sub I added ImageView3.Gravity = Gravity.Fill, resulting in the proper display which can be seen in the bottom-left image. But why was this statement necessary when Gravity was already set to Fill in the designer?

Curiously, I added ImageView4 in the designer (71x96) and preloaded the image in the designer itself, rather than adding it by code. Now when I run the program it displays correctly without my having to specify ImageView4.Gravity = Gravity.Fill (bottom-right image).

This behavior seems a bit odd to me.

 

[agraham]

But why was this statement necessary when Gravity was already set to Fill in the designer?

Because the gravity is a property of the BitmapDrawable that is the image and not of the ImageView so you lose it when you assign a new image.

 

[dlfallen]

Actually, it goes further. I didn't document it in my previous post, but if I create a 71x96 Imageview in designer and preload it with ANY 71x96 png file and then from code load a DIFFERENT png file into that ImageView, it displays properly despite not explicitly setting the ImageView.Gravity to Gravity.Fill. So if the gravity was a property of the first image, why is in not changed back to whatever the default is when the second image is loaded?

Also, it seems logical to have the ability to specify a property or behavior for the ImageView itself so images load the way you expect them to. Also, note that in the designer that Gravity is listed under "ImageView properties".

 

[agraham]

Because setting the ImageView Bitmap property copies the Gravity from the previous Bitmap and applies it to the new one. You lose the gravity setting if you don't specify an image in the Designer because there is no image to which the gravity belongs and hence nowhere to propagate it from to the new image.

 

[Cableguy]

The same behaviour was shown in Image's controls in B4Ppc...
The strtchImage had to be set only AFTER the image was assigned to the control, in B4A, I've found the same to be true, so if you set it by code, after the image is assigned, the fill is correctly shown.

 

[dlfallen]

Thanks guys. In a perfect world (my version of it), the gravity selection in the designer would be the default for the first image loaded. My second choice would be for the gravity option to be greyed out in the designer until an image were specified, thus making it clear that the property belonged to the image and not the ImageView.

But I certainly can live with your explanation and the current behavior. B4A is so darn slick I really have no complaints at all.