Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 7134 [details]
The attached test case defines an Image with XAML. The AnchorX attribute is not working when ran on Android. It does seem to work when running on iOS.
## Steps to Reproduce:
1. Run the attached sample.
## Actual Results:
The "verizon" logo is cutoff on the screen.
## Expected Results:
The "verizon" logo should be completely visible. Run on iOS to see the expected behavior.
## Build Date & Platform:
## Additional Information:
Relevant XAML is in the CarrierHeaderComponent.xaml file.
I have checked this issue and getting the same behaviour mentioned in bug description. To reproduce this issue I have followed the instructions mentioned in bug description.
Xamarin.Forms Version 184.108.40.20606
Environment Info :
=== Xamarin Studio ===
Version 5.2.1 (build 1)
Installation UUID: 952292e8-1484-4c56-b664-6ff701bef591
Mono 3.6.0 ((no/f540f8a)
GTK+ 2.24.23 (Raleigh theme)
Package version: 306000039
=== Xamarin.Android ===
Version: 4.14.0 (Business Edition)
Android SDK: /Users/xamarin76/Desktop/android-sdk-macosx
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
=== Apple Developer Tools ===
Xcode 5.1.1 (5085)
=== Xamarin.Mac ===
Version: 220.127.116.11 (Business Edition)
=== Xamarin.iOS ===
Version: 18.104.22.168 (Business Edition)
Build date: 2014-08-01 15:27:48-0400
=== Build Information ===
Release ID: 502010001
Git revision: d06832ce9807d6be24aca225457e8b37c7669f6f
Build date: 2014-08-07 12:10:47-04
Xamarin addins: 1de032531be4cecf2f39dbee3b87aac78204058c
=== Operating System ===
Mac OS X 10.9.3
Darwin Xamarin76s-Mac-mini.local 13.2.0 Darwin Kernel Version 13.2.0
Thu Apr 17 23:03:13 PDT 2014
Setting AnchorX is not supposed to result in any translation to the image itself. This is a mistake that should be fixed now.
Just to save anyone the time of testing, it looks like this fix hasn't yet made it into a Xamarin.Forms release.
- 22.214.171.12457 (Released 2014-10-02)
- 126.96.36.19962-pre0 (Released 2014-10-08)
Given the relatively close timing between comment 4 and these two releases, I suspect the fix simply hasn't made its way into a release branch yet. I expect the 1.3 -pre1 release will include it.
Correction to my previous comment (comment 5):
The Anchor properties _do_ work in 188.8.131.5257, **but** on Android the anchor positions are by default calculated before the elements have non-zero sizes, so the initial pixel positions of the anchor are always calculated to be 0. The Xamarin.Forms team is working on fixing that (other) problem.
## Possible workaround
If you wait until late enough in the display update process, the elements do eventually get non-zero sizes.
For example, one workaround is to set the Anchor positions in the `LayoutChildren()` override. If you set the anchor positions after the call to `base.LayoutChildren()`, they behave (almost) correctly. The one extra problem is that you must set the Anchor positions to values other than (0.5, 0.5). For example, you can use (0.49, 0.51). The problem with using (0.5, 0.5) is that the property setter will see that the values are unchanged from their defaults, and so will return immediately without updating the calculated pixel coordinates. If you like, you can also set the anchor to (0, 0), and then _back_ to (0.5, 0.5) to achieve the correct behavior.
I have checked this issue with attached sample project in bug description and I am still getting same behavior mentioned in bug description with Xamarin.Forms 184.108.40.20696-pre1.
Could you please let me know should I close this issue with provided workaround in comment #6?