Some attached properties still missing #426
Comments
|
After running mdoc 5.7.4.9, this list is reduced. Currently, the following attached properties are still missing:
|
|
Internal item logged |
|
Another thing I've noticed is that some of the ones that were added are only identified as .NET Core 3.0. Different issue? |
|
@mairaw offhand I think yes? but it shows here that the method exists in other monikers as well, so we should be seeing it defined for the .net fw: |
|
Adding some other missing APIs to the list:
|
|
@mairaw I checked with the latest release (dotnet/dotnet-api-docs#2773) the first one on the list The existing understanding for implementing this feature came from here
In a previous release, we modified it to allow for read-only attached properties (ie. only a "get" accessor) ... this would be a new feature, effectively to allow for write-only attached properties. |
|
The current list of missing attached properties:
I'd check with @SamBent the expectation/definition of attached properties and whether they can just have a setter. I also opened two additional bugs: |
|
The first two have both setters and getters in the code. Maybe your discovery process is confused because the argument type is IInputElement (instead of DependencyObject)? Similarly, the next two have setters and getters with argument type Object (instead of DependencyObject). Here's the code. Similarly, the last one also has argument type Object. Code. Most attached properties use DependencyObject's built-in property storage facility (the "effective value table"). But an attached property can work with other kinds of objects, provided the owner is willing to use some other way to store the property values. |
|
Found one more while validating the latest IntelliSense: This was erroneously redirected to https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.animation.storyboard.targetproperty I also noticed that the link from https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.animation.storyboard.targetpropertyproperty?view=netframework-4.8 summary goes to the field, even though we're linking to the property there FYI @BillWagner @gewarren - you'd need to work with @kexu to fix the redirect. For others that are missing, we temporarily have the page on previous versions until this issue is fixed. |
|
@adegeo I'm not sure, but I verified that all the missing attached properties in Maira's most recent list are now present. |
|
EDIT
The TOC shows it missing:
|
|
@mimisasouvanh We still have a problem with at least one missing attached property, where its name clashes with a field of the same name and presumably this is why it doesn't appear in the ECMAXML. See Andy's comment above. |
|
@gewarren @mimisasouvanh Yes this is something that's currently explicitly looked for in the code, and we don't generate an attached property if there's a field or property that already has that name. I'm not sure that we are able to support it because the docid will clash. What would you recommend here? /cc @TianqiZhang |
|
@joelmartinez The DocId would be differentiated by the F: or P: in front of it, respectively.
|
|
@gewarren ahh ... of course you're right, however that still doesn't 100% resolve the issue, because the site's URL doesn't have a reference to that prefix. So we have this URL, which currently goes to the field https://docs.microsoft.com/en-us/dotnet/api/System.Windows.Media.Animation.Storyboard.TargetProperty The attached property would want that exact same endpoint |
|
The resulting link though, would not. It would just be the full type name. |
|
It seems like C# gives a compile time error when you try to add two members with the same name, so this clash can only occur with attached properties? I think it's a corner case, but could we add a suffix to the URL for the attached property, like "AP" or ".AP"? https://docs.microsoft.com/dotnet/api/System.Windows.Media.Animation.Storyboard.TargetPropertyAP |
|
@gewarren I think this is something that in general we have tried to avoid ... but this is quite an odd situation. You should probably create a new devops bug for this scenario specifically, because I suspect it will require quite a different mitigation strategy than what we've done for the rest of the attached properties here. |
|
I logged a bug here: https://dev.azure.com/ceapex/Engineering/_workitems/edit/283041 |
We still have some missing attached properties
System.Windows.Controls.Validation.HasError
https://msdn.microsoft.com/library/system.windows.controls.validation.haserror?toc=xxx
System.Windows.Controls.Validation.Errors
https://msdn.microsoft.com/library/system.windows.controls.validation.errors.aspx?toc=xxx
System.Windows.Shell.WindowChrome.ResizeGripDirection
https://msdn.microsoft.com/library/system.windows.shell.windowchrome.resizegripdirection.aspx?toc=xxx
System.Windows.VisualStateManager.VisualStateGroups
https://msdn.microsoft.com/library/system.windows.visualstatemanager.visualstategroups.aspx?toc=xxx
System.Windows.Localization.Attributes
https://msdn.microsoft.com/library/system.windows.localization.attributes.aspx?toc=xxx
System.Diagnostics.PresentationTraceSources.TraceLevel
https://msdn.microsoft.com/library/system.diagnostics.presentationtracesources.tracelevel.aspx?toc=xxx
The text was updated successfully, but these errors were encountered: