text:
Dark / Gray option. How do you disable it.

Microsoft PowerToys version
0710
Installation method
PowerToys auto-update
Running as admin
No
Area(s) with issue?
General
Steps to reproduce
What is this please and how do I disable it:

✔ Expected Behavior
How to disable it
❌ Actual Behavior
How to disable it
Other Software
No response

Those buttons aren’t from powertoys.

Really. This is strange. When I close down PowerToys it stops. Was there some update or maybe this is an experimental aspect?

/reportbug so I can see what you have on but I do not believe this is in our UX.
@jaimecbernardo to keep me honest.

This query is what makes me believe this is not our code.  Gray should be in a resource file or direct string.  It doesn’t exist.
https://github.com/search?q=repo%3Amicrosoft%2FPowerToys+gray&type=code

PowerToysReport_2023-07-23-04-27-19.zip
Here we go.
Okay, I get your point. But then it must be conflicting with something.
Here is an example of windows explorer:

We do have "Gray" in resource files, but I've never seen this before.
@authorleon
So closing PowerToys fixes this? Can you please try disabling the PowerToys utilities one by one to check which one might be causing this?
Mention me in the answer please.

@jaimecbernardo Okay. I did that, still nothing. Only when I close the application, then it stops.

@authorleon , that's pretty weird. You mean close the application, as in go to the taskbar icon for PowerToys, press right-click and select exit?

@jaimecbernardo Hello, sorry for the delay. Yes, that is correct. I have to exit the app completely.
Thanks

@authorleon ,
This is pretty weird. And it seems like we're on different timezones, which makes this harder to figure out.
I've tried copying your settings into my local settings to see if it was some sort of Setting, but that's not the case. I can only assume there might be something in the machine causing this. Some sort of environment variable, perhaps?
Here's some thing to try out:
Test A:
1 - Disable all PowerToys utilities in the Settings.
2 - Exit PowerToys through the tray icon and in "Task Manager" "Details" tab, verify there are no PowerToys.{Something} processes running..
3 - Start PowerToys again. Does this issue appear right from the start?
4 - Enable utilities one by one to try to identify which code might be causing this.
Test B:
1 - Change the theme of your computer (both system and app themes) to the light theme. Does the strange label change from "Dark" to "Light"?
2 - Open a new File Explorer Window or another application. Is the strange label "Light" now?
3 - Restart the computer. After restarting, does the label change to "Light"?
Test C (in case you have Visual Studio installed):
1 - Open Spy++ from Visual Studio:

2 - Press the icon to open the "Find Window" dialog (The one with a rectangle and a binocular):

3 - Drag that crosshairs icon (That's pointed by "Finder Tool" on top of the strange "Dark" or "Gray" labels:

4 - That should give you a Handle and a Caption and a Class, which might be useful information. Press OK and it should show you a Property Inspector where you can see which process is creating it:

5 - In the "Process" tab, you'll have a Process ID, which you can click:

6 - The module name might also be helpful here in understanding what's creating those labels:

7 - I can use calculator  to convert that Process ID (1DC8) to the actual process ID in the way that it'll appear in Task Manager(7624):

8 - In Task Manager I can look for which Process ID is actually linked to the window I clicked (Visual Studio in my case, so it was that devenv.exe process):

Thanks for your patience, this one looks like an hard one to crack, since it hasn't appeared to anyone in the dev team.

Wow... that is impressive!!!
So it is a bug then.. I thought I was going mad!

@authorleon , I'm not sure yet if it is a bug, since we haven't been able to repro it.
That message was me asking you if you could run those tests to try and figure out where that is coming from :)
In the dev team we have no idea where that is coming from.
Can you please try out those tests to see if we can gather more information? /needinfo

@jaimecbernardo
Test A: 3 = Yes
Test A: 4 = All disabled, same result
Unfortunately, I do not have VS

@authorleon What about Test B? Do the labels change if you change the OS and App theme to light? Changing for light and restarting PowerToys, does that change the labels at all?

Hello @jaimecbernardo
Sorry for the delay.
It is still the same. Please have a look at the screenshot.

Hello. I've noticed something recently. The dark grey pop-up only comes up when I'm at the top edge of my screen. If I have a screen which is away from the top edge, this option does not appear when I go to the top of that particular window.
So when the mouse is at the top of the screen that option comes up. I'm wondering if that's being affected by Fancy Zones.

OK, so perhaps there's some specific interaction?
But this didn't go away when disabling FancyZones, right?
Can you please describe the exact interaction on how this is appearing? Perhaps even a video would help. Also, this is Windows 10, is that correct? Any other windows manager software you might have?

Can you please send a screenshot of your monitor layout as well?  From display settings.

Hello. I recorded/made an animated GIF show the exact problem.

Only happens at the TOP of monitor 2 and 3.

After HOURS out searching. I have found the culprit.

A new feature has been added.
Still though, when I close PT, it stop working, then I have to restart CareUEyes....

Thanks for the gif, so this actually even has a close button? I don't think we have such an overlay anywhere on PowerToys. What is it really doing when you press those buttons?
Have tried testing in the same conditions, but without success.
Here's another idea. Can you please install Accessibility Insights for Windows? https://accessibilityinsights.io/downloads/
That allows you to use the mouse pointer to click an application and it gives some information, which might contain the application name of what's creating those labels? Can you please try it out to see if we can get more information?

Ah, nice one! :) I knew it wasn't us. Glad to see this really is a an external app 😆

We do have some mouse utilities in PowerToys which might be conflicting with it.

Thanks for figuring it out :) Definitely would've stayed here lost for a bit 😅

authors: authorleon crutkas jaimecbernardo


text:
Screen Snip

Microsoft PowerToys version
0.71.0
Installation method
Microsoft Store
Running as admin
No
Area(s) with issue?
FancyZones
Steps to reproduce
Have Fancy Zone activated and Start+Shift+S
✔ Expected Behavior
Both screens to be shaded and allow for the screen capture of a designated area
❌ Actual Behavior
The shaded area is offset on both monitors and does not allow for the screen capture outside of that shaded area. Before i started powertoys I am able to use screen snip normally but as soon as I turned on Fancy zones it broke again and after I turned off fancy zones and Powertoys the issue persisted.
Other Software
No response

Does this still happen with the newest version?
/needinfo

source: gharchive/issue

repo: microsoft/PowerToys

license: MIT

license_type: permissive

license_source: github-api


text:
Crop and lock crash

Microsoft PowerToys version
0.85.1
Installation method
PowerToys auto-update, GitHub
Running as admin
Yes
Area(s) with issue?
Crop and Lock
Steps to reproduce
Try to turn on Crop and Lock
✔ Expected Behavior
Crop and Lock turns on
❌ Actual Behavior
When you turn Crop and Lock on the settings window crashes but powertoys stays running
Other Software
No response

It fixed itself??


text:
Clip board is not working with Keyboard Manager

Environment
Windows build number: Microsoft Windows [Version 10.0.19041.329]
PowerToys version: v0.18.2
PowerToy module for which you are reporting the bug (if applicable): Keyboard Manager

Steps to reproduce
I use Japanese Keyboard layout.🗾
I would like to create emacs like shotcuts like F13+B
=←

Set as below

Try clipboard

Expected behavior
Selected text is entered
After turn off KBM, it works well.

Actual behavior
Whichever you choose, it will be entered as v
FYI, normal copy and paste work well.

Screenshots

This seems to be happening because when you click a result from Clipboard it simulates Ctrl+V keyboard stroke. In the above scenario since Ctrl is remapped, it ends up receiving F13+V instead of Ctrl+V.
I don't think we will be able to change behavior such that we can detect Ctrl+V pressed by the user vs Ctrl+V sent from Clipboard. We'll need to look more into it.

This is a wontfix?

authors: Hattomo alannt777 arjunbalgovind


text:
[Run] "Clear on results" has a flicker

ℹ Computer information

Windows build number: Microsoft Windows [Version 10.0.20180.1000]
PowerToys version: 20
PowerToy module: Run

📝 Provide detailed reproduction steps (if any)

Enable option clear previous search
2 Search for app and open it
Reopen PT run and the previous result flashes up for a few seconds then disappears

✔ Expected result
The previous result should be cleared when the PT Run is previously closed so it does not flash on screen when reopening.
❌ Actual result
Previous result flashes on screen for a few seconds.

Yup, verified bug

also hint text stays so that needs to be fixed as well

@crutkas Added the code which solved the problem for all cases except on quick hide/unhide in branch  dev/somil55/bug/5616

The fix is OK, not perfect but better than before.

This has been resolved in the 0.35 release.  https://github.com/microsoft/PowerToys/releases/latest


text:
Long press Windows key incomplete

ℹ Computer information

PowerToys version: 0.25.0
PowerToy Utility: Windows key shortcut guide
Running PowerToys as Admin: Yes
Windows build number: 19042 630

📝 Provide detailed reproduction steps (if any)

Long press WIndows key
You see on screen the functions of Windows key + characters

✔ Expected result
Show all characters that have a function combined with Windows key.
_What is the expected result of the above steps?
To also show what the outcome is of:
Win+B (selecting system tray)
Win+C (open Cortana)
Win+F (open Feedback)
Win+P (open Projecting > not sure if this is the right word in English)
Win+T (select Taskbar)
Win+V (multi paste)
Win+W (open whiteboard)
❌ Actual result
Now long pressing Windows key shows only combinations with A, D, E, G, H, I, K, L, M, R, S, U, X, 1, 2, 3, ...
What is the actual result of the above steps?
A more complete and helpful Windows key utility.
📷 Screenshots

I have my Taskbar at the right side of the screen...

Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form

already tracked in #179

Duplicate of #179


text:
feat(UpdateUtils): Allow disabling update checker

Summary of the Pull Request
This PR adds an option to disable auto update checker to settings UI.

PR Checklist

[ ] Closes: #xxx
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

@yuyoyuppe
See #2701 for discussion.

we intentionally do not introduce this feature

Thanks for your response, but I would like to be able do that. I prefer updating things manually and the update notification is annoying. I know I can disable the notification from Windows settings but still it's a dirty work, also it still sends web request to check if update is available or not. I don't like this behavior.

We'll be adding a deferral as part of the Group Policy Objects work.

Closing it in favour of GPI effort

source: gharchive/pull-request

authors: htcfreek jaimecbernardo xmine64 yuyoyuppe


text:
[Launcher] Fix Launcher not closing when PT running as admin

Summary of the Pull Request
One liner which fixes #4569

References

PR Checklist

[x] Applies to #4569
[x] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Requires documentation to be updated
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed
Tested only as admin. Non-admin should not be affected.

Let's close this in favor of https://github.com/microsoft/PowerToys/pull/4577.


text:
May 5, WW

Event Information

Category
Details

Stream Date
May 5, 2021

Stream Time
3:00 PM

Title
TBD

Description
TBD

Speaker
---------

SharePoint ID
13002

SharePoint Status
Planning

Additional Resources:

Event Checklist
10 Weeks Prior

[ ] Title & Description Finalized
[ ] Tracking Links/Short links
[ ] Published
[ ] Calendar Invite

Moved this to DevOps - closing this

repo: microsoft/ReactorPlanning


text:
Adding the Report Viewer nuget package adds assembly binding redirects due to conflicts within itself.

Almost every time I add the web forms report viewer package to a project, I end up with a warning from Visual Studio telling me to add some binding redirects.

Here's the same but expanded for readability.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	<dependentAssembly>
		<assemblyIdentity name="Microsoft.SqlServer.Types" culture="neutral" publicKeyToken="89845dcd8080cc91" />
		<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
	</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	<dependentAssembly>
		<assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" />
		<bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
	</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	<dependentAssembly>
		<assemblyIdentity name="System.Collections.Immutable" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
		<bindingRedirect oldVersion="0.0.0.0-1.2.1.0" newVersion="1.2.1.0" />
	</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	<dependentAssembly>
		<assemblyIdentity name="EnvDTE" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
		<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
	</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	<dependentAssembly>
		<assemblyIdentity name="Microsoft.Build.Framework" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
		<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="14.0.0.0" />
	</dependentAssembly>
</assemblyBinding>

The newtonsoft mismatch is something in my own stuff that is reffing an older package, but the rest of the recommendations seem to be necessary after adding this package.
Its always the same set of binding redirects, and as far as I can tell its caused by a mismatch for files within the package. Its an Asp.net framework 4.6.2 web application project. There is no reference to EnvDTE by the project or any of the other references I am able to control.
Here's an excerpt from the build log turned up to detailed.
There was a conflict between "EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "EnvDTE, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
9>  No way to resolve conflict between "EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "EnvDTE, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily.
9>      References which depend on "EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\EnvDTE.dll].
9>          c:\projectdev\CustomerProject\Trunk\packages\Microsoft.ReportingServices.ReportViewerControl.WebForms.140.1000.523\lib\net40\Microsoft.ReportViewer.Design.dll
9>            Project file item includes which caused reference "c:\projectdev\CustomerProject\Trunk\packages\Microsoft.ReportingServices.ReportViewerControl.WebForms.140.1000.523\lib\net40\Microsoft.ReportViewer.Design.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          c:\projectdev\CustomerProject\Trunk\packages\Microsoft.ReportingServices.ReportViewerControl.WebForms.140.1000.523\lib\net40\Microsoft.ReportViewer.WebDesign.dll
9>            Project file item includes which caused reference "c:\projectdev\CustomerProject\Trunk\packages\Microsoft.ReportingServices.ReportViewerControl.WebForms.140.1000.523\lib\net40\Microsoft.ReportViewer.WebDesign.dll".
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.14.0\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Shell.14.0.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.14.0\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Shell.14.0.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.Design\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Shell.Design.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.Design\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Shell.Design.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VSDesigner\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VSDesigner.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VSDesigner\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VSDesigner.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.DataDesign.Common\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DataDesign.Common.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.DataDesign.Common\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DataDesign.Common.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.DataDesign.DataSetDesigner\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DataDesign.DataSetDesigner.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.DataDesign.DataSetDesigner\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DataDesign.DataSetDesigner.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.TemplateWizardInterface.dll
9>            Project file item includes which caused reference "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.TemplateWizardInterface.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\EnvDTE80.dll
9>            Project file item includes which caused reference "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\EnvDTE80.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.DataDesign.Interfaces\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DataDesign.Interfaces.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.DataDesign.Interfaces\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DataDesign.Interfaces.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.WizardFramework\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.WizardFramework.dll
9>            Project file item includes which caused reference "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.WizardFramework\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.WizardFramework.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL

9>      References which depend on "EnvDTE, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [].
9>          C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\VSLangProj.dll
9>            Project file item includes which caused reference "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\VSLangProj.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\VSLangProj80.dll
9>            Project file item includes which caused reference "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\VSLangProj80.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>          C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\VSLangProj2.dll
9>            Project file item includes which caused reference "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\VSLangProj2.dll".
9>              Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL
9>              Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL

I've also found this same problem mentioned/reported here a while ago.
I'd like to not have to add assembly binding redirects for a conflict within a single package. If there is something I can do to avoid this warning without having to remove (or change) the package, that would be great.

This project handles the sample code release, bugs and issues
For the product issues I would recommend you to contact support and they can help you to identify the best way to get the product fix.
You can also use https://powerbi.microsoft.com/en-us/support/

@jtarquino - Am I misreading the name of this repo, or is it misrepresenting itself?
The SQL team doesn't respond to posts in the MSDN forums, or to issues logged on dev comm. If you are on the SQL team, or are the person charged with handling community or subscriber issues on their behalf, please let me know when the reports in those other systems will be addressed and I will try to refrain from logging things in this and other incorrect repos.

@StingyJack the repo is a way to us from the product team to share samples and small pieces of documentation in the most direct and quick way possible, but is not meant to replace the support channels and other community channels like the forums.
The place where you are more likely to get prompt response for the report viewer control is directly from the nuget page https://www.nuget.org/packages/Microsoft.ReportingServices.ReportViewerControl.WebForms/
For your final question PBIRS is a super set of SSRS that is why I added the PBI support channel

The place where you are more likely to get prompt response for the report viewer control is directly from the nuget page

Email == siloed, hidden information. Little benefit, more work for everyone.

I am having this exact same problem regarding Microsoft.Build.Framework. It all seems related to:
Microsoft.ReportViewer.Design 15, and Microsoft.ReportViewer.WebDesign 15 want Microsoft.Build.Framework, Version=14.0.0.0
Meanwhile Microsoft.ReportingServices.ReportViewerControl.WebForms.150.1484.0 directly depends on Microsoft.Build.Framework, Version=4.0.0.0 for some reason...
This is causing me an issue because with the binding redirect, when I build and publish, my app throws a YSOD complaining about not being able to find v14.
If I dont have the redirect, my app throws his warning in my console.

authors: StingyJack VictorioBerra jtarquino

repo: microsoft/Reporting-Services


text:
rsAccessDenied - Permissions insufficient to perform this operation (logon)

Hello, I am implementing the security extension and I have the following problem. At the time of logon I get the error: The permissions granted to the user 'test' are insufficient to perform this operation. Test is a registered user and is in the database.
How can I give this user permissions if I can't enter the site?
Is there a generic user that has permissions?
With a windows user (who had permissions before implementing the security extension) should I log in?
Thank you!

In the sample documentation check the section "Locate the  and  elements, within the  element, and modify the settings as follows:" , that entry defines what user will be an admin

Thanks, i can logon whit the admin user, but i hava a new problem, i see the page like this...

use /reports instead of /reportserver

i have the same problem...

look this captures from the rs configuration manager.. i don't know if its ok, or the name "/reports" depends on this.

its the one from the Web Portal Url

authors: adrods jtarquino


text:
Power BI measure format is not applied

The legend in the tree map pictured below looks messy because it doesn't reflect the measure's format (in this case, % with 1 decimal):

The same lack of formatting can be seen in the Data Browser:

As well as in tooltips:

Thanks for filing this. It seems that currently, this format is not provided to a custom visual - see this issue:
https://github.com/microsoft/PowerBI-visuals/issues/313
Also, there is a link to vote for this feature:
https://community.powerbi.com/t5/Custom-Visuals-Ideas/Format-Decimal-Places-for-R-Custom-Visuals-More-data-to-send-it/idi-p/375018#M165
Until then, the guidance is that the custom visual provides this itself. Let me know if you would like to make this feature request.

authors: danmarshall otravers

repo: microsoft/SandDance


text:
objaverse-github download error

Very appreciate for your data opensource, have you met the error when download source github from objaverse-xl? If yes, how to solve it. Or May be  I can ignore the error. Thanks again!

Could be network issue or the repo does not exist anymore. Ignoring them is ok.

Could be network issue or the repo does not exist anymore. Ignoring them is ok.

OK, Thank you very much

authors: JeffreyXiang feiqiu-cyber

repo: microsoft/TRELLIS


text:
Poor error message when names conflict

TypeScript Version:  3.5.2

Search Terms: debug failure unexpected node error message exception
Obviously the following code is incorrect, however I would expect a friendly error message directing the user to the problem, rather than the nasty/ambiguous error message that is currently given: Error: Debug Failure. Unexpected node.
I ran into this in a large codebase and it took me awhile to find source of the problem.
Code
yarn add @types/lodash

import * as pick from 'lodash/pick';

export const pick = () => pick();

$ tsc

/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:73748
                throw e;
                ^

Error: Debug Failure. Unexpected node.
Node 156 was unexpected.
    at getDeclarationSpaces (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:46074:41)
    at /Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:46066:84
    at Object.forEach (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:217:30)
    at getDeclarationSpaces (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:46066:28)
    at checkExportsOnMergedDeclarations (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:46009:41)
    at checkVariableLikeDeclaration (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:47011:17)
    at checkVariableDeclaration (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:47048:20)
    at checkSourceElementWorker (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:48787:28)
    at checkSourceElement (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:48648:17)
    at Object.forEach (/Users/oliverjash/Development/typescript-playground/node_modules/typescript/lib/tsc.js:217:30)

Error: Debug Failure. Unexpected node

🐞
That's not a normal error message.  The compiler actually crashed.  It's 100% a bug. :smile:

What version of lodash is this?

repros with @types/lodash@4.14.136. The unexpected node kind is MethodSignature, which probably has something to do with following an alias along until the original pick method is encountered.

Starting failing this way in 2.6.

I have same error:
ERROR in [internal] INTERNAL ERROR: Debug Failure. Unexpected node. Node Identifier was unexpected. stack trace: Error: Debug Failure. Unexpected node. Node Identifier was unexpected.     at getDeclarationSpaces (app\node_modules\type script\lib\typescript.js:59394:41)     at checkExportsOnMergedDeclarations (app\node_ modules\typescript\lib\typescript.js:59320:41)     at checkVariableLikeDeclaration (app\node_modu les\typescript\lib\typescript.js:60568:17)     at checkVariableDeclaration (app\node_modules\ typescript\lib\typescript.js:60606:20)     at checkSourceElementWorker (app\node_modules\ typescript\lib\typescript.js:63058:28)     at checkSourceElement (app\node_modules\typesc ript\lib\typescript.js:62912:17)     at Object.forEach (app\node_modules\typescript \lib\typescript.js:309:30)     at checkVariableStatement (app\node_modules\ty pescript\lib\typescript.js:60616:16)     at checkSourceElementWorker (app\node_modules\ typescript\lib\typescript.js:63027:28)     at checkSourceElement (app\node_modules\typesc ript\lib\typescript.js:62912:17)
after migration from 3.5.3 to 3.7.4.
And I have no clue which package triggers this error, because project is big

I'm getting a similar error, though not speicific to lodash:
/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70731
                    return ts.Debug.failBadSyntaxKind(node);
                                    ^
Error: Debug Failure. Unexpected node.
Node 193 was unexpected.
    at serializeTypeNode (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70731:37)
    at serializeTypeOfNode (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70594:28)
    at addOldTypeMetadata (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70536:97)
    at addTypeMetadata (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70530:17)
    at transformAllDecoratorsOfDeclaration (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70447:13)
    at generateClassElementDecorationExpression (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70472:40)
    at generateClassElementDecorationExpressions (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70458:34)
    at addClassElementDecorationStatements (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70451:44)
    at visitClassDeclaration (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70252:13)
    at visitTypeScript (/Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js:70137:28)

How do I even start to debug this?

@joeprivettsmart If you can get this caught in the debugger, you can probably find a SourceFile object somewhere in the stack and inspect its name.
Basically, node --inspect-brk /Users/joe.privett/Sources/cms/node_modules/typescript/lib/tsc.js, then put a breakpoint in serializeTypeNode on the ts.Debug.failBadSyntaxKind.
The alternative is "binary debugging", in which you delete half of your files at a time to see which ones had the bad node.
Either way, I'm pretty sure it's in a file with decorators because that's serializeTypeNode says that it converts type nodes to their equivalent runtime types.
It would be a good idea to open a new bug while you're at it, because your stack is quite different from the original one.

The test case for the original issue reported by @OliverJAsh here:
// @strict: true
// @noEmit: true

// @filename: node_modules/@types/lodash/object.d.ts
import _ = require("./index");
declare module "./index" {
    interface LoDashStatic {
      pick<T extends object, U extends keyof T>(
        object: T,
        ...props: Array<U>
      ): Pick<T, U>;
    }
}

// @filename: node_modules/@types/lodash/pick.d.ts
import { pick } from "./index";
export = pick;

// @filename: node_modules/@types/lodash/index.d.ts

/// <reference path="./object.d.ts" />
export = _;
export as namespace _;
declare const _: _.LoDashStatic;
declare namespace _ {
    interface LoDashStatic {}
}

// @filename: index.ts
import * as pick from 'lodash/pick';
export const pick = () => pick();

authors: Andarist OliverJAsh SerhiiBilyk fatcerberus joeprivettsmart sandersn

repo: microsoft/TypeScript


text:
Abstract property cannot be accessed in the constructor check cant trace through function

TypeScript Version:  3.9.0-dev.20200328

Search Terms:
abstract, property, constructor error, check
Code
abstract class P1 {
    abstract property: string;
    constructor() {
        console.log(this.property)
    }
}

abstract class P2 {
    abstract property: string;
    constructor() {
        this.init()
    }

    init() {
        console.log(this.property)
    }
}

Expected behavior:
TS error tip should show in class P2
Actual behavior:
If I wrapper it with function, its not work correct. Its easily to take mistake.
Playground Link:
https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200328&ssl=15&ssc=39&pln=15&pc=42#code/IYIwzgLgTsDGEAJYBthjAgCgRgQbwCgFiFRIZ4EAHKAeyoFMoIBPALgXIEsA7AcwDcRErFo9yAV3i0oACgCU+YSRFiwtZAwB0yWn1kQAFlzBaa9Jq3nKEAXwL2CZaHEQo0GTACYlK5xURzRmZ2TmheQRtRcWgpCBkFXxUSIxMtXi4IBRtHFQysxUJk1XENbV19VNMgyxZFAHp6hB5aRCM6AHcEJjooJEMGWABrBGQuIYYsbByHAiA
Related Issues:
#19197 #26642

Methods aren't inlined for purposes of CFA, and shouldn't be since they're virtual - the design contract of this class may well be "Initialize property then call super.init()`"

I have no idea about CFA mean.
In my mind, i just want to call init by parent class constructor. so its unnecessary to call it by other way.
If i try to access property in . TS will tell me its error, i cant do it, its very good, i will modify it.
But, if i wrap it with function at first, no error tip throw, and its hard to find this error. Maybe it can be improve?
Just raise this problem as typescript user, FYI.

authors: RyanCavanaugh moonrailgun


text:
importsNotUsedAsValues = error should apply to export statements

TypeScript Version:  3.9.2
Search Terms: importsNotUsedAsValues, error, export
Code
import { Interface } from "./module";
export { Interface } from "./module";

With a "importsNotUsedAsValues" set to "error".
Expected behavior:
tsc would error on the export statement.
Actual behavior:
tsc does not error on the export statement, it only errors on the import statement.  TypeScript, by default, would elide both statements in the compile and should error in the same way.
Playground Link: N/A

This seems reasonable. What’s the use case? Why is it important?

The use case was originally to give early feedback from tsc when transpiling/bundling when re-exports might not work as intended.

That’s exactly what --isolatedModules is for, and it does error when re-exporting a pure type.

@andrewbranch Could you please explain the unique purpose of each of them and why they in different flags?

https://www.typescriptlang.org/tsconfig

In first look it seems that --importsNotUsedAsValues should yell for all pure type, export & import...

Why? It conspicuously says “import” and not “export” right in the name of the option. If there are docs that gave you this idea, let me know and I’ll update them. But the TSConfig reference reads pretty clearly to me that it’s about imports.

The documentation isn't inaccurate, but what is the purpose of "importsNotUsedAsValues": "error" if not to provide a hard diagnostic of something that could be elided if type information is available. If you are saying that is only "isolatedModules" then what is the purpose of this flag?

Setting --importsNotUsedAsValues to anything other than the default allows you to be more explicit about your module dependency graph. In either preserve or error mode, you can count on the fact that import type declarations will always be elided and normal import declarations will never be elided (though this guarantee does not extend to the names imported, only to the statement on the whole—i.e., import { Interface } from './foo' becomes import './foo'). preserve is important because it allows users to maintain a predictable module order and side effects when an import otherwise would have been elided. error is frankly not that useful in my opinion, but it forces you to explicitly annotate imports that would be elided under the default remove mode. This means that when you have an error-free compilation, the emit should be exactly the same as it would be if you had not specified --importsNotUsedAsValues and not used import type at all. So by definition, it offers you literally nothing over the default in terms of emit behavior; it’s purely for people who want the human-readable signal of “this import will be elided” and “this import will not,” but are happy with the module graph they get under remove.
This is why I think the original suggestion here does make sense—because an export ... from does affect the module graph and could be used to trigger side effects in the same way that imports do. Notably, not only does export { PureType } from './module' not get an error with --importsNotUsedAsValues=error, but it also gets fully erased in the emit in error/preserve—we should probably be keeping it as export {} from './module' if we’re treating it as an effective import.

authors: andrewbranch kitsonk yuvalshim


text:
Template literal destructure

Suggestion

🔍 Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

Template literal destructure
String pattern destructure
String pattern validation and extraction
String type destructure

✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[ ] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

It would be nice if we could destructure a string with template literal into variables. Please find the example code below
📃 Motivating Example

const {y: number, m: number, d: number, t: string}: `${y}-${m}-${d}T${time}` = '2020-08-05T10:15:00'
// result is y = 2020, m = 8, d = 5, t = '10:15:00'

This could be done by generating code from split, type convert and custom validate function and the code would be very easy to read, compact and type safe.
💻 Use Cases

id string, phone string, date format
custom string data extraction

I try to extract date string from web and it is really a pain. Using library such as momentjs can be do so but with more lines of code and I face a lot of problem when I need to move to luxon as the momentjs itself suggests to move on (https://momentjs.com/docs/#/-project-status/). It would be better if I can manage this from vanilla code. Currently, I am doing something like this:
const [year, month, date] = dateString.split('-').map( v => Number(v) )

This could be implemented without emitting different JS based on the types of the expressions

We don't do things that don't check this box; that's why it's on the form.

authors: RyanCavanaugh meepeek


text:
Typescript does not pick up definitions with exports field in package.json

Suggestion
The ESM spec from Node has introduced the exports property which can replace main. This means that packages can now have exports and not main. An example of this is globby.
However without defining main, typescript's definition location logic does not automatically pick up the types.
The proposal is when there is No “types” field in the package json, to change checks “main”, then index.d.ts to checks “main”, then “exports”, then index.d.ts
This said, we would also need to figure out how to handle the more complex object structured "exports" functionality so this is an overly simplistic ask compared to what would actually be needed.
🔍 Search Terms
ESM, ES modules, exports, package, package.json
✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
The proposal is when there is No “types” field in the package json, to change

checks “main”, then index.d.ts to
checks “main”, then “exports”, then index.d.ts

📃 Motivating Example
My org is currently basing a bunch of new updates based off the ESM spec and using sindresorhus' projects as a baseline. You can see his package.json doesn't have a main to automatically determine the types for.
https://github.com/sindresorhus/globby/blob/main/package.json
💻 Use Cases
Automatically finding the types associated with the entry file of exports.

Looks like duplicate of #33079

Sure is!


text:
Boolean function inference has incorrect behavior

Bug Report
Typescript is unable to correctly determine that a function's return satisfies the specified type.
🔎 Search Terms
"Typescript expanding boolean into true/false" (https://github.com/microsoft/TypeScript/issues/30029)
🕗 Version & Regression Information
v. 4.7.4

This is the behavior in every version I tried, and I reviewed the FAQ for entries about: YES

⏯ Playground Link
https://www.typescriptlang.org/play?ts=4.9.0-dev.20221014#code/LAKALgngDgpgBAIQIYBMBiA7OBeOAKPAShwD44wAnAVxmIB98jS4AzJAGwGdaBuUAYwD2GTmHIxRALkSpMOfMWxkA3qDhwKMMFQpYAskjAALAHQUkGFIIC2TMgAY+IAL48gA
💻 Code
type SomeInferredFunctionType = (() => true) | (() => false);

// Gives TS error!
const test: SomeInferredFunctionType = () => {
  return Math.random() > 0.5;
};

🙁 Actual behavior
Typescript thinks test does not satisfy its given type when it does. Note, that it is possible (with much difficulty) to collapse SomeInferredFunctionType into the correct simplified type() => boolean when I have direct access to the type. However, in my codebase, the type is actually automatically inferred and I do not have access to it and I am just consuming it.
🙂 Expected behavior
Typescript should be able to determine that test satisfies the condition given by SomeInferredFunctionType

This is correct behavior. SomeInferredFunctionType describes a value that is either a) a function that always returns true or b) a function that always returns false. A function that returns Math.random() > 0.5 is neither of those.

Yes, () => true is different from () => boolean. However, in this particular case the types should collapse. In every type of logical system I can conceive of, (() => true) | (() => false) is equivalent to () => boolean

(() => true) | (() => false) is equivalent to () => boolean

That's only true if you assume the functions in question are mathematically pure (i.e. that the effects of calling the function are not observable beyond the return value).  Incidentally Math.random is not, and purity is not, in general, a safe assumption for a type system built on top of JS to assume.

... However, in this particular case the types should collapse.

Why? Naively, the provided function does not satisfy any constituent of the union. I don't know what logic you're using here to make this reduction step -- it's plainly wrong in the presence of nonpure functions, as noted by fatcerberus just now.

Can you give me a concrete example of real life functions of type (() => true) | (() => false) would NOT be equivalent to () => boolean?
As a general rule, I'm not proposing that we collapse types like that, but I'm just saying I can't think of any specific use case where this specific function types shouldn't be equivalent.

If I say I accept f of type () => true | () => false, then the tuple [f(), f()] must be of type [true, true] | [false, false] (TS does not do this combinatorial expansion, but in principle this is what that union type means). The provided function is capable of returning [true, false] which is outside the domain of [true, true] | [false, false]

I could 100% envision code that depends on that invariant too.

Yes, that's clearly what the Typescript compiler is doing internally. But you're using the self-contained logic of set notation here. And maybe I'm wrong, but to me it seems that smart outside observer logic should be prioritized over set logic. And I would argue that any reasonable outside observer without the equivalent of a phd in set theory would think those two types should be equivalent.
Also concrete example would be great! Maybe I just need to see a real life example for what you're saying to make more sense to me.

Do you think that for all T and U, () => T | () => U and () => T | U are equivalent? Or is this logic particular to boolean?

"If you call the function twice you get the same type" seems like an invariant that real code could easily depend on, no deferral to set theory necessary.

No, those definitely should not be equivalent. You can see it in the comment mentioned issue but the problem primarily arises from the fact that boolean is considered a ts primitive by most devs. https://github.com/microsoft/TypeScript/issues/30029
And that's a good example @fatcerberus I hadn't considered. With the conditional type, in theory you should be able to do type narrowing (although currently the ts compiler isn't smart enough to do so).
Maybe the real issue is the convoluted inference process that is generating this conditional type and I should isolate that issue and write up a bug report.

Why is boolean different?

@RyanCavanaugh I assume the relevant distinction is unit type vs. not

It's honestly a little unfortunate that we made boolean secretly a union; it makes sense but doesn't match intuition with the other primitives which have infinite domains. Likely this is going to boil down to a conditional type with an incorrectly distributive type parameter.

I'm doing some complex type inference stuff and deep down in the chain of logic, this is the core offending logic:
type Example<T> = T extends any ? {val: T} : never
type Bool = Example<T> // Equals { val: false } | { val: true }

I then use the inferred types to generate an inferred function type.

Right, see https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#distributive-conditional-types

Well, I think I'll just close this. There's no good way to solve this issue without likely causing more problems than it solves. Maybe one day on a major TS bump it might make sense to explore the ramifications of making boolean not secretly be true | false. But for now I can fix the problem with a little bit of repetition. AKA
type DoSomething<T> = T extends true
  ? DoAnotherThing<boolean>
  : T extends false
  ? DoAnotherThing<boolean>
  : DoAnotherThing<T>;

@scottmas You know you can just disable the distributive behavior, right?
type Foo<T> = [T] extends [boolean] ? T[] : unknown[];
type Test = Foo<boolean>;  // boolean[] - NOT true[] | false[]

Ahh yes, thank you

authors: RyanCavanaugh fatcerberus scottmas


text:
Forbid function assignment to index signatures:any

I'll open a bug for this shortly, but in the meantime:
It doesn't make sense for functions or constructors to be assignable to types with an index signature; it doesn't even make sense for anything to be assignable to a target with an index signature if the source doesn't have one (h/t @weswigham). This PR makes a small change of exempting types with call/construct signatures from the rule that makes any non-primitive source type assignable to string/number index signature of any.
This has the concrete advantage of preventing functions from being assigned to ArrayLike<any>.

@typescript-bot run dt
@typescript-bot run rwc

it doesn't even make sense for anything to be assignable to a target with an index signature if the source doesn't have one

This was my thought at first too, but only if you take the index signature to mean "it has all the properties in the world".  But that's logistically impossible so I prefer to think of it as "it can have any possible property, but doesn't have to" (effectively it's a type in which every property is optional).  TS just avoids bugging you about the potential undefinedness of properties, but I tend to take that possibility as a given when working with types having index signatures. :wink:
https://github.com/microsoft/TypeScript/issues/31661#issuecomment-497138929

I'm not sure of any examples in the wild, but I can see how a function might be used as a property bag as well. Maybe the assignment needs to be allowed if the target type also has a call signature?
It's also possible that that is allowed in the code and I didn't notice, but could be good to add a test for it.

+1 to this change. I'm curious if we could take it even further. It's confusing for [string: any] indexers get special treatment (in particular compared to [string: unknown], but in other cases as well). I suspect it is also indirectly responsible for another case of special treatment -- ignoring indexers entirely in generic constraints (see https://github.com/microsoft/TypeScript/issues/31661#issuecomment-499311256).
I'm curious what the original context and motivation was for adding the special behvaior, and whether it's too late to revisit it.

@russelldavis Wait - I’m confused: you want the code here: #31808 to be made to work again despite the free-for-all it allows, but are okay with the change proposed here which is about further restricting the semantics of index signatures?
I don’t mean to sound combative but - if the case here is made to be an error, then why shouldn’t the one in #31808 continue to be an error as well?

@fatcerberus the change here only applies to index signatures of the form [key: string]: any, which get special treatment in the language. #31808 is using [key: string]: string, so it wouldn't be affected at all by this change.

@fatcerberus to be a bit more explicit, you're right that I think typescript should be more restrictive here and less restrictive in #31808 (and somewhere in the middle where the two overlap).
Indexers in general are safe, and using them in generic constraints doesn't change anything about their safety (which is why I'm questioning the breaking change that led to #31808).
What is actually unsafe is the special rule that allows everything (except for primitives) to be assigned to [key: string]: any, which is what this issue is about.
If you look at the "crazy stuff" example given at https://github.com/microsoft/TypeScript/issues/31661#issuecomment-497138929, the craziness has everything to do with the special rule being discussed here, and nothing to do with generics (it applies equally to an equivalent example without generics).

Right, but any is just a free-for-all anyway and inherently unsafe - and the behavior for any for indexers in this regard doesn’t actually seem that special since similar safety issues arise for e.g. [key: string]: string - just in a more restricted fashion, as I showed here: https://github.com/microsoft/TypeScript/issues/31661#issuecomment-499740178
In that example an assignment was allowed through an alias that otherwise would have been prevented.  The only difference with []: any is that the type of the properties involved isn’t restricted - which would equally be the case for something like []: unknown I think.

and the behavior for any for indexers in this regard doesn’t actually seem that special

It really is special. More below.

The "special rule" you cite has nothing to do with any and just boils down to, if all properties' types match the index signature, then it's assignable

This is not correct. The assignment let dict: { [s: string]: unknown } = new Error(); is not allowed, even though all properties of new Error() match [s: string]: unknown equally well as [s: string]: any.
Also, just look at this PR. The code literally has a special case for targetInfo.type.flags & TypeFlags.Any.

unknown, unlike any, is typesafe, yet the bad stuff still happens

Your example above that statement actually shows the opposite. The bad stuff does not happen with unknown. It doesn't compile as given, due to #30769, but if you change it to function foo(obj: Record<string, unknown>), you'll still get compile errors, while if you change it to function foo(obj: Record<string, any>), it will allow the bad stuff.
I think you may have gotten confused because, prior to 3.5, there was also a special rule for [s: string]: unknown indexers. That rule was removed in 3.5, which was a great change that increased type safety.
(Note that https://www.typescriptlang.org/play/ isn't updated to 3.5 yet, so you have to be careful when using it to test things -- I've been bitten by that as well.)

let dict: { [s: string]: unknown } = new Error();

Thanks, so you're right - that is indeed an error in 3.5.  However, this isn't (I tested in VSCode with 3.5.1 selected):
type X = { [key: string]: unknown };
type Y = { pig: number, cow: number, ape: number };

let y: Y = { pig: 812, cow: 1208, ape: 128 };
let x: X = y;    // shouldn't be allowed but is
x.whale = "it's fat";

So the new Error() treatment seems to be a special case of some kind.  I personally would rather the behavior of index signatures be consistent rather than having a bunch of patches that make certain cases safer while leaving other related loopholes open.  The patchwork of special cases makes it more difficult to explain :-/

I'm not sure I agree that that example should be disallowed, but it's nuanced and I'm currently out of time. Either way, it's completely unaffected by this PR and by my proposal at https://github.com/microsoft/TypeScript/issues/31661#issuecomment-499321653. Thanks for the discussion @fatcerberus.

Mostly I’m just trying to understand what mechanism disallows the assignment from new Error() but allows the assignment above.  Under structural typing, the cases don’t seem that different.

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

authors: Jessidhia fatcerberus russelldavis sandersn


text:
feat(#45195) Improve perf of unions with many primitives

Fixes #45195

@typescript-bot perf test this

Looks like there's no change in full type-checking time. The change might still be good for end-users though and specifically in editing scenarios.

oops, missing semicolon

Hello! Please let me know which milestone will this land to, when you know. Thank you.

authors: DanielRosenwasser ypresto


text:
Fix detecting an existing Map/Set

This didn't affect compilation to CJS since that sets exports.Map
instead of creating a global.

The point of the declare const Map on the preceding line is to force the lookup of Map to look at the globally scoped Map (rather than ts.Map due to namespace merging). How did this become an error for CJS emit?

The problem is not in the CJS output.  If I set module to es6, the resulting code is:
var NativeCollections;
(function (NativeCollections) {
    function tryGetNativeMap() {
        return typeof Map !== "undefined" && ...;
    }
    ...
})(NativeCollections || (NativeCollections = {}));
export var Map = getCollectionImplementation("Map", "tryGetNativeMap", "createMapShim");
```

@rbuckton, does that make sense?

authors: elibarzilay rbuckton


text:
In typeof x === object, type parameters extending unknown narrow like unknown itself

In addition, improves relating keyof T and keyof NonNullable<T>-like types (to allow the relation) so that the impacts of, eg, chaining a typeof x === "object" and a truthiness check still produce compatible types.
Should fix #48468 even after the {} and unconstrained type parameter change is back in.

@typescript-bot pack this
@typescript-bot user test this inline
@typescript-bot test this
@typescript-bot run dt
@typescript-bot perf test this

DT looks clean (some unrelated intl change is making it fail but otherwise clean), RWC has removed an error on an Object.keys call from the better narrowing. Looks good!

This mostly got folded into #49119. I'll extract the improvements to keyof relations into a new PR, since those changes are the only thing that didn't and are pretty standalone.


text:
Cannot install WSL using PowerShell Add-AppxPackage

Windows build number:
Microsoft Windows [Version 10.0.18363.592]
What you're doing and what's happening:

I'm trying to install Ubuntu 1804 on my WSL using Add-AppxPackage command on an Administrative Powershell follow this guide

What's wrong / what should be happening instead:
No distro got installed
Ubuntu should be installed on my system.

From the documentation you linked:

Once your distro is installed please refer to the Initialization Steps page to initialize your new distro.

That link explains what you need to do next.

From the documentation you linked:

Once your distro is installed please refer to the Initialization Steps page to initialize your new distro.

That link explains what you need to do next.

Thanks, sorry I did not note that there is no shortcut in the Start Menu nor the Microsoft Store at all.
I've renamed appx file to zip, unzip and double click on ubuntu1804.exe, now my wsl works.
But I think it could be better if inatall-process could open the first-time-launch-console automatically.

authors: DHowett-MSFT long-nguyenxuan

repo: microsoft/WSL


text:
More nonzero exit codes when trying to exit a WSL instance lately

User reports increased frequency of non-zero exit codes when exiting WSL in Ubuntu 18.04:

Second user confirms in Pengwin.
I am re-directing conversation here.
Aaron and Stephen could you please provide steps to reproduce?
Aaron I see in your screenshot that you have SSH'd into a remote server, shut it down, and then exited that shell. I am curious how did you spawn that shell though?
When I exit a shell in Windows Terminal it normally closes the terminal. Are you launching it in Windows Terminal? With a custom entry by chance? What do you have in the Windows Terminal entry for that shell?

I can reliably reproduce [process exited with code 130] on Penwgin. It seems to happen I use Ctrl+c in a session and later try to close the session.

Steps:

Open window/tab
Start some ongoing process, such as tail -f
Press Ctrl+c to cancel the process
Press Ctrl+d to quit the session

The session stays open, and displays [process exited with code 130] instead of quitting.
valorin@Pengwin:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Pengwin
Release:        11
Codename:       bullseye

{
    "guid": "{7f586916-8357-53d4-bb2b-ca96f639898a}",
    "name": "Pengwin",
    "commandline": "wsl.exe ~ -d WLinux",
    "icon": "ms-appdata:///roaming/pengwin.png",
    "backgroundImage": "ms-appdata:///roaming/dark-pengins.png",
    "source": "Windows.Terminal.Wsl"
},

In case it's helpful, I don't have any Terminal keybindings set for the letters d, or c.

@valorin
Does the behavior change when you omit "commandline" and change "name" to "WLinux"?
I know why you did that, just curious if the change is because you are calling it by wsl.exe instead of the name.

No difference in behaviour @sirredbeard. I also realised I can replicate by clicking Ctrl+c without running a process. The mere act of hitting Ctrl+c causes the code 103.
I just tried using the raw Pengwin console, instead of Windows Terminal and was unable to replicate. So it only happens within Windows Terminal. I'm on Version: 0.10.761.0 right now, but I updated it only yesterday from v0.9.something and I have been getting the code 103 error for the past few weeks. (I can't remember exactly when it started.)

I also just confirmed the same code 130 error on my Ubuntu 18.04, Debian, and Kali instances. All are WSL2, installed from the store, and updated using apt periodically with no system changes I can think of.

I can reproduce the code 130:

By calling Ubuntu via the command line method you are using:
            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu via wsl.exe",
                "commandline": "wsl.exe ~ -d Ubuntu",
                "source": "Windows.Terminal.Wsl"
            },

But not when Ubuntu or other distro is called this way:
            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl"
            },

Repeated same with my Ubuntu 20.04 test image:

            {
                "guid": "{4ac2e77b-9dac-50fa-9c00-39e6b455b32b}",
                "hidden": false,
                "name": "Ubuntu2004 via wsl.exe",
                "commandline": "wsl.exe ~ -d Ubuntu2004",
                "source": "Windows.Terminal.Wsl"
            },

But not:
            {
                "guid": "{4ac2e77b-9dac-50fa-9c00-39e6b455b32b}",
                "hidden": false,
                "name": "Ubuntu2004",
                "source": "Windows.Terminal.Wsl"
            },

Can you post your profiles.json?
I suspect this is some interaction between how WSL is being launched within Windows Terminal.

I don't think this is a WSL bug - or at least my code 130 isn't. I just did a Ctrl+c in my Git Bash console (C:\Program Files\Git\bin\bash.exe) and it threw the same error code. So it looks to me like a Windows Terminal bug.
It will be interesting to see if Aaron's error is linked to Terminal like mine, or something completely different.

Looks like it's the intended Windows Terminal behaviour: https://github.com/microsoft/terminal/issues/4223

@valorin @sirredbeard I haven't been able to consistently reproduce this bug, so I'm not sure… but I looked at microsoft/terminal/#4223 and it just doesn't seem right for ^D to not work for Linux-in-WT… because it works in Terminal-on-Linux, that way… so why not here???

Put a copy of my profiles.json up.

The cause in my case is that WT detects an error code was returned by the last command. So when you click ^D and it goes to close the tab, it checks for an error code from the last command first. As of v0.8, WT prevents itself from closing a tab when there is an error code, to avoid the problem where the tab throws an error when it's first launched. If it auto-closed, a broken profile would open and close quickly and you'd miss the error code.
It may be different in your case, but in every test I ran, it always displayed the error when the last command didn't close cleanly.

One of the discussions in the WT issues explains that the gnome terminal handles the ^D differently than they can in WT. Hence the different behaviour. I'll try to find it for you when I'm back at my computer.

Ah this is the comment I'm thinking of: https://github.com/microsoft/terminal/issues/4223#issuecomment-574834181

Just for the record, it isn’t related to WT “handling” Ctrl+D differently. Terminal tracks exactly one process and reports on its exit code. In all WSL cases, that process is wsl.exe. It doesn’t go digging to find your shell, or the last command you ran.
Your shell is reporting, by using exit(130);, that it is exiting with code 130. wsl.exe dutifully reports that exit code, and Terminal receives it.
This is how bash, zsh and a number of other shells report their exit statuses when the last command was unsuccessful either through its own failure or through the user pressing ^C.

@DHowett-MSFT , I wonder if it could be possible to allow the user to specify a list of exit statuses to be considered "fatal", and close the tab if none of those is observed?

I have set "closeOnExit" to "always" and it seems to be ok. I would maybe switch back if anything suspicious is happening or to debug my terminal.

Thx to both @DHowett-MSFT  and @yveslange . The former for explaining why this happens (and that it "works as intended"), and that I didn't borked my WSL installation somehow. The latter for providing a means to handle it the way that that suits my needs.

@yveslange That did the trick.

@yveslange That did the trick.

For WSL tabs this happens if you stop some command before exiting with Ctrl-C, or simply hit Ctrl-C on empty input before doing exit (or doing Ctrl-D): in this case latest code will be 130.

As noted previously I can confirm having the "C:\Users\tkonick\AppData\Local\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe\LocalState\settings.json" field of "closeOnExit": "always"

authors: DHowett-MSFT akulbe dseven hakuno imposeren knuth-konrad sirredbeard tijko valorin yveslange


text:
WinDev2022 Eval WSL2

Trying to run WSL2 inside Windows 11 Development image . According to the website everything should work out of the box and installed perfectly however getting a weird virtualization error.
Looked everywhere and all my settings check out mostly because the image provided everything out of the box.  Also to note I am using the VirtualBox provided image.

Does your hardware or the hypervisor allow nested virtualization? If not WSL1 is the only choice in that environemnt.

Yeah I run WSL1 and WSL2 on the same laptop.

I also ran Get-VM in Powershell and it's not showing the VirtualBox VM. Instead showing the Virtual instances I created with Multipass.

Does running the image in a hyper-v vm work? Looks like an issue with nested virtualization.

authors: Biswa96 benhillis casedup


text:
Not quite

Not quite.
I'm looking for information on how to set Wifi SSID, Wifi Password, API Password, MQTT settings, etc, via API when the ESPHome device is in captive_portal mode. I don't believe setting all of these via any kind of API call is possible, though, I think at least Wifi SSID and Wifi Password are.
And the documentation for how to bring an ESPHome device developed on one Network to a different Network is lacking, if this is even possible without a recompile and reupload. I'd be happy to write the guide if I knew how to do these tasks. But I don't. That's why I'm looking for such documentation.
Thanks for the help.
Publicado originalmente por @dlashua en https://github.com/esphome/feature-requests/issues/1053#issuecomment-751835951

Not relevant to this repo

authors: jlooper zanins

repo: microsoft/Web-Dev-For-Beginners


text:
Can the virtual camera be accessed from multiple applications simultaneously?

In readme Getting Started's 5th step says Install VirtualCamera_UWP, this one I am not sure what I should do. I have seen in other issues people were able to install uwp camera manager app, but I am not sure how do I do this. Any comment about this would be appreciated. What I was able to do was the following:

Built all the projects successfully
Installed VirtualCamera_MSI
Ran VirtualCamera_Installer and was able to install VCam-SimpleMediaSource and VCam-HWMediaSource. When choosing VCam-AugmentedMediaSource, the installer crashes.

VCam-SimpleMediaSource and VCam-HWMediaSource I registered were visible in ms teams (for example). However, it was not possible for me to use the same virtual camera from another app (e.g. slack) simultaneously while ms teams was using the virtual cam. Maybe I am missing smth or doing smth wrong. If not, is there a way to modify/extend this project so the virtual camera is consumed from multiple applications simultaneously? Or any way to use MediaSource to build a virtual camera that will be consumed by multiple applications simultaneously.

Thank you very much for the detailed comment. For some reason I was told that in order for the camera to be accessed concurrently, I need to create a virtual camera. So I don't. I will just use WinRT in my app to initialize my camera in SharedReadOnly mode. I assume this will work in any scenario, right? That is, regardless what api the other app is using to initialize the camera (for example, regardless if the other app is a UWP app or not), I can always use the camera in SharedReadOnly mode, right?

Hi, I guess you are asking 2 questions:

how can you install the virtual camera UWP control app?
follow the steps 1 to 4 in the readme section related to the app (https://github.com/microsoft/Windows-Camera/tree/master/Samples/VirtualCamera#virtualcameramanager_app). This will allow you to launch the UWP app from which you can create and destroy virtual camera instances using a GUI. In this case though you don't need to run VirtualCamera_Installer which does mostly the same thing as the app but from cmd line.
how to use the same camera from more than 1 app concurrently? VirtualCamera is not meant to be a way to allow concurrent usage of a camera from more than 1 app. VCam is a mechanism to virtually 'plug' a new camera on the system, and have that camera produce frames/expose capabilities in a vast number of ways such as wrapping an existing camera or synthetizing frames on its own. MediaCapture is a client-side API to instantiate a camera handle and use it from an app. That said, this quesitons refers to the 'sharing mode' with which you initialize your camera client (i.e. in WinRT this would be your MediaCapture instance, the way you initialize it using a MediaCaptureInitializationSettings and specifying a MediaCaptureSharingMode)
if an app initializes a camera client with SharingMode == ExclusiveControl (most if not all apps do), then only it can control the camera (i.e. change MediaType, set controls, etc.). However, a second app can open the same camera using a camera client initialized with SharingMode == SharedReadOnly, which will allow it to receive frames but not to change the MediaType nor set controls. I think this is what you are asking for correct? Your other app needs to open the camera in SharedReadOnly to receive frames despite the other app concurrently running and using the same camera with a client initialized in ExclusiveControl.

Hi, yes mostly as there is a caveat sadly:
some USB cameras that started to ship a while ago may block you from reading from them even in shared mode if the other app is using them via DShow (an older API instead of MF or WinRT).
We have been requiring cameras to not do this but we can't prevent 1) older hardware that already shipped and 2) older apps that still use DShow to get you in that situation in your UWP app even when using readonly sharedmode when 1) + 2) are put together. There is however nothing that can be done in that situation to read frames concurrently so your approach is the one to use to cover that experience.

Thanks for the comment @LPBourret . One more question)) Here, it is said
Virtual drivers do this by making copies of the video frame, which results in significant performance penalties.
Does this suggested solution, i.e. virtual driver, solve the caveat you mentioned? If you know about this approach, i.e. virtual driver + copying frames, a few words about this approach, or hints for further research would be appreciated. In any case, you already helped me :)

Thanks @LPBourret . Closing the issue.

authors: DavitMob LPBourret

repo: microsoft/Windows-Camera


text:
Sugg: Clear message for long XSLT-Transform

When I start a XSLT-transform with e.g. 50MB input, then I see ..

at first nothing
then a turning sandclock
"(not responding)" as additional information in the program title
heavy load on my CPU-monitor
and I don't know if the software is dead or not ...

So if you add a message / dialogue / status bar info or something else with
" Started transformation on 11:34:23, wait until final message" ....
the user will now what is going on.
Chris - have a fine weekend!

Great suggestion, thanks.

I added a progress dialog with a cancel button in these commits and this one in case you want to try it:

The progress only pops up if it takes more than 1 second and the cancel is not perfect, the cancel can only cancel when the transform starts reading input or writing output, but I notice some transforms spend a lot of time doing calculations internally before writing anything so you can still see a pause between the time you try and cancel and when it actually cancels.

Fixed in https://github.com/microsoft/XmlNotepad/releases/tag/2.9.0.9

authors: Pierre-de-la-Verre lovettchris

repo: microsoft/XmlNotepad


text:
Dropdown list opens a dialog container

Hi,
Thanks for the repository that allows my angular app to use fabric components in react :). Most of components work very well in my project except the issue below:
I followed the same set up from demo app, and put following component into my app component
<fab-dropdown
  contentStyle="width: 300px;"
  [placeholder]="'Select one'"
  [defaultSelectedKey]="'A'"
  (onChange)="logEvent('dropdown change', $event)"
>
  <options>
    <fab-dropdown-option optionKey="A" text="See option A"></fab-dropdown-option>
    <fab-dropdown-option optionKey="B" text="See option B"></fab-dropdown-option>
  </options>
</fab-dropdown>

However, what I got is a dropdown list that occupies the majority of the page:

And when I inspected the dropdown list dom and compared it with the correct dropdown in demo app, the difference is:
In my project, parent div is

However in demo app it renders as:

This issue happens when load the app into outlook add-in. Dropdown list in the same code works very well in web page.

https://stackoverflow.com/questions/46692251/office-ui-fabric-js-dropdown-component-not-loading-correct-style-when-its-click
It helps to resolve it, basically we need to specify responsiveMode.

https://stackoverflow.com/questions/46692251/office-ui-fabric-js-dropdown-component-not-loading-correct-style-when-its-click
It helps to resolve it, basically we need to specify responsiveMode.

repo: microsoft/angular-react


text:
Add method to check manually for new updates

Describe the solution you'd like
The Distribute Android SDK relies on the host Activity lifecycle to start the update check process.
This is fine in most scenario, but if we want to initialize AppCenter Distribute manually later on (after onResume) it is causing issues.
I have written a ReactNative wrapper for AppCenter Distribute so I can start the library from the ReactNative layer.
But by the time the wrapper is ready and initializes Distribute, the Activity already went through the onStart/onResume calls so the update check is not triggered.
So the user would have to send the app to the background and foreground to trigger the onResume call and so the update check process.
Having a method to trigger the check of updates, out of the lifecycle of the Activity would fix this issue.
Describe alternatives you've considered
~It looks like we can enforce the update process to kick in by disabling and enabling Distribute manually by doing the following:~
~Distribute.setEnable(false).get() and then Distribute.setEnable(true).get()~

https://github.com/microsoft/appcenter-sdk-android/blob/develop/sdk/appcenter-distribute/src/main/java/com/microsoft/appcenter/distribute/Distribute.java#L347
https://github.com/microsoft/appcenter-sdk-android/blob/aef71abd8164d769eba6408f2a53fcee45fa07cb/sdk/appcenter/src/main/java/com/microsoft/appcenter/AbstractAppCenterService.java#L97
I have tried the above and it doesn't work :/

An alternative is to call the following:
Distribute.getInstance()
		  .onActivityResumed(this.reactContext.getCurrentActivity());

This works but is obviously a bit hacky...

Thanks for bringing up this feature! I will take this to the right team for review.

@tjsomasundaram I'm trying to figure out how the app updates are supposed to be handled when we wire up AppCenter.Start in Application.OnCreate. From all the testing I've done, the in-app updates are never triggered, and I'm wondering if this is because it isn't properly wiring into the Activity.OnResume/OnPaused handlers.
I am happy to take control of this and manage my own updates (ie. check every 30 minutes), but I simply cannot see how this should be done with the existing API. I'm on Xamarin.Android, so I don't see an option to call Distribute.getInstance().onActivityResumed()...
Any input would be appreciated!

Hi @Bishbulb, thank you for providing great details on what you are looking for. I took this to the Distribute team and they are looking to see the scope of the work involved. I am not aware of this feature being a part of their plans in the near future, but I can confirm with them.

Hello @Bishbulb and @fabiendem - Thanks for providing all the info. We don't have plans to make this scenario from the SDK in the near future. I'll keep you updated on this thread if anything changes!

authors: Bishbulb dimazaid fabiendem tjsomasundaram

repo: microsoft/appcenter


text:
AppCenter Test + Android Emulators

I have tests that require a lot of API coverage and leasing all of the physical devices needed is very time consuming.

Thanks Connor @cofitz1 for the feature request! @Oddj0b would you mind taking a look?


text:
Allow reporting custom errors

Originally reported as this ticket: https://github.com/Microsoft/AppCenter-SDK-Unity/issues/220
In our apps, we log different types of "errors":

Crashes - these are errors that cause the game to crash (exit). With Unity this usually means native stuff that throws an unhandled exception (e.g: on Android, some null reference exception at the Java level), since a NRE in Unity will not cause the app to crash.

Unhandled or handled exceptions - an actual Exception object that is thrown and we report (e.g: inside the Catch clause)

Custom errors - this can be anything basically, for example - some sort of argument validation that fails and we'd like to log as an error to keep track of. Also, with Unity it's easy to set up a "global" error reporter by hooking to the Application.logMessageReceived. This will get called whenever a new message is logged (for example - an error or an exception). In this case, however, we do not get the actual Exception object so we cannot report this using the current APIs.

The 2nd and 3rd options are what i am looking for: i do not have an Exception object, but i would still like to report the error to AppCenter.

Is this feature present in the backlog ?