Fixed constructors of LayoutAnchorableFloatingWindowControl and Layou…

[bdachev]

It seems to me that in both LayoutAnchorableFloatingWindowControl and LayoutDocumentFloatingWindowControl classes the constructors with single parameter should call the other constructor of the respective class instead of the base class as otherwise at least _model field won't get initialized and there are problems afterwards.

[Dirkster99]

This is dublicate with Issue #1442 - please read the attached thread to understand why this is not fixed in version 3.5 of this project (the short version is that the current version of the open source version of the toolkit is no longer actively maintained).

[bdachev]

Hi Dirk, Thank you for pointing that out. I should have checked before adding my pull request. I was already aware of Xceed's policy to delay fixes in open source version of wpftoolkit with two versions. I will most probably give a try to your fork! :)

[Dirkster99]

Yes, you could say they implement an early crash adding and late fixing policy.
Thats an interesting way to put it :-)

Unfortunately, its a useless contribution and you only find out until after you incorporated it in your application which crashs on all kinds of random interactions 👎 thats when they want you to pay for it 💯 but whats even more fun: the current version is not much better in terms of quality then the open source version - so, you end up wasting your time and your money...

[XceedBoucherS]

Hi all,
I suggest you try the Plus version before talking to fast(https://xceed.com/xceed-toolkit-plus-for-wpf/).
Xceed has been working for the last 10 years on the Toolkit to offer the most complete WPF toolkit controls on the market. The Plus version contains many new controls and features that are not included in the OpenSource version. It also offers fast support and an up to date version.

The OpenSource version is still maintained and will always be. We love to ear what the community is using, how they work with our controls and if they find any bugs so we can fix them.
You can make sure that if you pay for the Plus version and have any problems, we will find you a workaround or a fix. We something even send you the code to modify the sources in order to have an immediate fix so you can continue to work on your application. The same can't be done for the OpenSource version or else the Plus version wouldn't be necessary.

You can try the Plus version for free for 45 days and you have all the benefits of the paying customers:
-access to all the controls and features
-fast support
-the latest fixes and additions to the toolkit

The OpenSource version is not updated quite often, but we are thinking about a way to improve this. We understand your concerns of late fixes, but you need to understand that this is a version which is updated for free !
Thank you for your comprehension.

[MarqueIV]

I have to say the constant ‘plugging’ for the paid ‘Plus’ version is a little frustrating when dealing with open-source versions. Yes, we know there is a paid version with more features and enhancements. But perhaps we don’t need that. We just need what’s in the open-source version. To say you’re delaying fixes in the open source version but not in the plus version, especially when those fixes are made by the open source community I feel is a little disingenuous to the open source community and the philosophy thereof.

Don’t get me wrong. I understand Xceed is a company that’s trying to make a profit and it is nice to release an open source version at all, and of course you provide better support when a customer has paid, but bug fixing is not something that should be delayed, let alone by several versions, let alone when those fixes are contributed back to the open source project. That’s holding the open source code hostage if you don’t pay. After all, if someone fixes something in the open source version, we’re assuming that fix would, if needed, also make it back into the paid version, right? So that means we’ve taken the time to fix something that you’re benefitting from in a paid product while purposely not fixing it in the open source product where it was originally applied.

Again, this just tastes so wrong to me. When you contribute something to open source, you are making somewhat of a promise to the open source community that you are working with them on it. You are all contributing to make it better. You also agree to, as the owner of the repo, stay on top of such things. After all, the only thing that has to happen is testing, then merging. It should not delay a fix to wait for something in the pro version, which is unrelated. By your own admission, they are several versions behind, therefore it’s a different product.

Please start to work on committing bug fixes to the OS versions sooner.- It helps everyone and shows us you’re a company that cares about the code, not just cold profits.

[XceedBoucherS]

I understand your point MarqueIV and as said in another post, things will change for the Community version of the Toolkit. Stay tuned, more versions are coming real soon !!
#1523
Thank you for greatly appreciated feedback.