Hotfix/CategoryOrderAttribute fixes #1523
Conversation
Since the CategoryOrderAttribute is set to AllowMultiple-true, you must specify a TypeId to ensure uniqueness. Since this attribute should only have one instance per Category, we use CategoryValue as the key.
Update the logic in GetCategoryOrder to use TypeDescriptor.GetAttributes instead of Type.GetCustomAttributes as the latter doesn't take into consideration those attributes added at runtime via TypeDescriptor.AddAttributes. As such, without this change, the property grid doesn't respect dynamically added values for category ordering such as when creating custom PropertyDescriptors in a TypeConverter's GetProperties call.
|
Note: This PR addresses another open issue where a commenter incorrectly rejected changing to TypeDescriptor.GetAttributes claiming duplicate attributes were removed. However, this was actually because of a misconfigured CategoryOrderAttribute and it not having a TypeId override. Once you add that override (which this PR does), the duplicates are no longer removed (because they are no longer duplicates.) That issue is #842 |
|
@MarqueIV |
You should be able to simply cherry-pick from my branch/commit into yours. Since they haven't updated it (or even looked at it apparently!) in a while, there really shouldn't be any conflicts. BTW, just so I understand, why are you maintaining a separate branch? Do you have changes/fixes there that aren't here? If so, wouldn't it make more sense to keep them all here (then somehow bug the mods to actually update them?) After all, these are the NuGet packages most people would use, aren't they? We really do need to somehow get the mods to actually do something here tho. This is ridiculous. It's been over a month and they haven't even looked at it let alone reviewed or assigned it to someone. |
|
cause of that I maintain a fork. I have a few more features as the original one, for example brusheditor and tokenized textbox. And I‘ve netcore support for wich you need to wait years if the updatepolicy stays the same |
|
Thank you for bringing this to our attention. Please note that this OpenSource version is always 2 or 3 versions behind the Plus version. The Plus version contains many more controls and more features. It can be used for free for 45 days here : https://xceed.com/xceed-toolkit-plus-for-wpf/. This OpenSource version is still maintained(with fixes) and will continue to be. All your comments are read and categorized to be fixed following the demand. When a Plus version will be released, a new OpenSource version will be released. |
|
The problem is, if someone is using the OpenSource Version (maybe in a OpenSource Project), and finds a Bug and creates a patch, with the current release cycle it will take years until he gets it. (this year we had only on release, wich means 9 months, so the fix will be included in v3.9 so he needs to wait 4 versions = 36 months for the fix) |
|
Boucher, please say I’m misunderstanding what you said because as I read it, you’re saying my fix will be in the paid version several releases before it goes into the OS version, which as jogibear pointed out, means years away. I get holding off new features and controls by several versions to get people to use the paid version. That makes sense. But it does not make sense for bug fixes, let alone those made by the OS community for the OS version. If you’re saying you’re taking our fixes and applying them to the paid version, then are holding off for several releases before it goes back into the OS version, not only is that a crappy thing to do to the OS community, but may actually be in violation of the OS licensing since I submitted my fix against the OS version, not the paid version. Again, please say I’m misunderstanding this and you are releasing this in the next OS fix which will be the next time the paid version is also released. On a side-note, bug fixes should not have to wait for major releases. They should be done out-of-band because they are exactly that... bug fixes. You don’t wait for a new version of an OS before getting stuff fixed. That’s what patches and updates are for. |
|
@MarquelV see also here: #1528 so maybe create a pull against my fork. And my fork is not a fork of this repo cause I started it when xceed was still useing codeplex |
|
also look here: #1342 |
|
@MarqueIV The licensing issue is an intersting twist I've never thought about in all the years I have been facing this pseudo-open source project. I think someone with a little more of a legal background (with a specialization in software licensing) should be looking at this - do you know anyone who could lent a qualified opinion? |
|
I’m starting to to think the same thing. Again, I get holding back on newer features and enhancements, but that should not extend to the code written by the open source community for the open source version that they’re then using for-profit in the paid version while not adding it back to the open source version. Not even sure that’s a ‘gray’ area. That may very well be black-and-white here of wrongdoing. I think I’m going to ask around about this. |
|
Hi all, In 2019 only 1 version has been released, that is true, 7 and a half months ago(not 9), because of workload, but stay tuned, things will changed !! We have re-think the concept of the Community version. From now one, many new community versions will be released and you won't have to wait for months/years before working in v3.9 ! Eventually the Community version and the Plus version will be at the same point ! We appreciate your feedback and we'll continue to improve the WPF Toolkit to make it the best Toolkit on the market ! Thank you. |
This corrects a missing TypeId from the CategoryOrderAttribute as well as updates the logic to get the order from that attribute for those added at runtime via TypeDescriptor.AddAttributes.