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 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.
Using latest 126.96.36.199.
I have an app with UIButton custom descendants and I change their text color sometimes, like this:
var title = new NSMutableAttributedString(RawText);
title.SetAttributes(IsSelected ? UIBuilder.ToolbarButtonSelectedIconAttribute: UIBuilder.ToolbarButtonIconAttribute, new NSRange(0, 1));
title.SetAttributes(IsSelected ? UIBuilder.ToolbarButtonSelectedTextAttribute: UIBuilder.ToolbarButtonTextAttribute, new NSRange(2, RawText.Length - 2));
where XXXAttributes are an instance of UIStringAttributes. Very often simulator won't pick the changes and still display the version before I apply these changes. Looks like it doesn't know when to refresh the screen.
This is most likely a compilation issue in the VS extension. The remoted simulator simply launches the app bundle it's told to launch. If that app bundle is old then it would explain the issue you're seeing!
It's nothing wrong with the app bundle. During the runtime buttons don't change color as they are supposed to. If I minimize the app and restore it, then buttons are properly colored.
Just to be clear, when you say "still display the version before I apply these changes" do you mean:
1) When your application runs the method which contains that piece of code the text doesn't update correctly.
or 2) When you modify the code, compile it, deploy it and launch it, the old version of the code executes?
I understood your description to mean number 2, but if you mean number 1 then it is definitely a simulator bug that we should look into. If it is number 1, can you attach a project which reproduces the issue? Can you also attach the log files from a session where you trigger the problem?
Ah, I see. No, it's definitely 1).
I've attached the gist of the code, can't attach the whole project but I'll try to create a repro when time permits.
Can you confirm which Xcode version you are using?
Sure, XCode 9 and latest stable VS2017 Xamarin.
info provided... back to NEW
Luis, I tried to create a simple repro but failed for some reason. I'll try again.
@Miha, I'm going to put this back in NEEDSINFO and we'll wait for your simple repro. Also, since we're out of time for 15.4, I'm moving this to 15.5. We'll continue the investigation and will work to get this issue resolved ASAP.
*** Bug 59815 has been marked as a duplicate of this bug. ***
*** Bug 59803 has been marked as a duplicate of this bug. ***
on 2nd thought moving back to 15.4.
Fix has been tested and verified!
The patch is in master, d15-5 and d15-4 now.
Given the nature of the issue the appropriate importance is 'blocker' as our product does not work with the stable Xcode version - reassigning this appropriately.
@miha, we're going to include this fix in the upcoming 15.4.1 service release, as the 15.4 release will be released shortly. In the meantime, you may try this pre-release build which containing the fix: https://bosstoragemirror.blob.core.windows.net/wrench/simulator-win-d15-4/3c/3c341a8aee8d65f1d167b981c341037ff08119f3/Xamarin.Simulator.Installer.188.8.131.52.msi
@luis got it, thanks for the effort.
Just a quick bookkeeping note:
The sample application used to verify the fix in comment #18 does not actually trigger the underlying bug, and so could not be used to verify the fix. I'm not sure why this new sample was used to verify the bug since we had an attached sample which was 100% reliable in triggering the issue.
The original testcase attached to the bug does trigger the bug and I did verify the fix using that testcase.
Screencast showing the above: https://screencast.com/t/7JnwbEoH