Skip to content

Added AppVeyor build status badge to readme.md file #365

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 22, 2016

Conversation

pedrolamas
Copy link
Member

Added the AppVeyor build status badge to the readme.md file

@msftclas
Copy link

Hi @pedrolamas, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

Copy link
Contributor

@ScottIsAFool ScottIsAFool left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have one for master too?

@pedrolamas
Copy link
Member Author

Fair question! I honestly don't have any opinion on this one...

@ScottIsAFool
Copy link
Contributor

I would have thought if anything, we should be showing the badge for master by default, and it's dev that we should be discussing whether to include :)

@deltakosh
Copy link
Contributor

I would say both

@deltakosh deltakosh merged commit ca60249 into dev Sep 22, 2016
ghost pushed a commit that referenced this pull request Jul 21, 2020
## Fixes
Remove the `lock` statements used in `InAppNotification` as well as all the timers used to detect when the animation ends.

## PR Type
What kind of change does this PR introduce?
- Feature
- Code style update (formatting)
- Refactoring (no functional changes, no api changes) 
- Sample app changes

## What is the current behavior?
The current `InAppNotification` implementation is using a lot of `lock` which are not needed since all the code lives in the UI thread. 

## What is the new behavior?
The control is no longer using any `lock`. All the notifications are now pushed to `_stackedNotificationOptions` which will control when the notification is displayed. This change allow us to set the appropriate content on the `ContentPresenter` when the control template is applied.
WE can also now push directly an `object` content as the notification payload. To make it always work, I've simplified the logic between the `InAppNotification` and its template. This is introducing a breaking change in the notification template.


## PR Checklist

Please check if your PR fulfills the following requirements:

- [x] Tested code with current [supported SDKs](../readme.md#supported)
- [x] Pull Request has been submitted to the documentation repository. Link: [#365](MicrosoftDocs/WindowsCommunityToolkitDocs#365)
- [x] Sample in sample app has been added / updated (for bug fixes / features)
    - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)
- [ ] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [ ] Contains **NO** breaking changes

The `ContentPresenter` of the `InAppNotification` template must now be named `PART_Presenter`.

## Other information
The XAML files have been updated by XAML styler and contains a lot of changes unrelated to this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants