Developer Express recently released first beta version of their XPO2 ORM product to their subscribers (currently there are also betas of both XtraCharts and XtraLayout - all of these betas look really good). Since I've already dived into Linq/DLinq world I soon missed Linq features for doing queries. Thus I couldn't resist and started implementing it myself - hence the XpoLinq project is born. Here is an example of syntax:
RhCollection<Address> address = from a in addresses where a.City == "Nova Gorica" select a;
Note that Linq is used only for creating select expressions while behind the scenes runs XPO2.
XpoLinq syntax and has few benefits over existing Xpo CriteriaOperator syntax:
- intellisense support (a.City)
- code checking during compile time
- integrates with Linq (you can mix queries between Xml, DLinq, XLinq and any other Linq compliant subset)
I find all of these points above extremely useful features that should be present asap in any product that does queries. Perhaps the only problem is that Linq is still far away to being released (but it is very functional right now) and using its features for short time projects might be risky. Anyway, whether I continue work on XpoLinq is unknown depending on several factors: my time, DevExpress implementing it, my curiosity, etc. Regardless if my XpoLinq lives or not it has been certainly an interesting Linq learning experience.
There are two things you have to know:
- don't do a simple upgrade. Rather uninstall previous version, clean GAC, Program Files and Common Files and do a fresh install. There seems to be an issue in previous installer. No big deal.
- The other issue is with designer. To be more precise, the designer of inherited forms. If you happen to get an exception at design time when opening a derived form don't fear another Visual Inheritance drama. Just follow these steps (note: I am not sure which step is required and which is not (I guess removing and re-adding references is not) as I just did them all):
- delete license.licx file
- remove references to all devexpress assemblies and re-add them
- close IDE
- open IDE and rebuild the solution
- open the form again and you shouldn't have any problems
As soon as I downloaded the new WinForms Component Collection 2.2.1 for Visual Studio 2005 I installed them, turned the visual inheritance "experimental" support on opened an existing project. It won't compile though because you have to manually update the references: remove DevExpress.* ones from each project that uses them and re-add them. This will fix all problems of upgrading. Now, the interesting fact is that if you initially look at the references (before updating) everything seems ok - while the project has all sorts of problems you would expect when there are bad references. Not sure whether this is a problem with Visual Studio 2005 or not.
Sit down, this one is huge.
Apparently Microsoft doesn't have Windows Forms Designer support for complex controls on derived forms, in other words, if you created a form with a complex control (DataGridView is perfect candidate), made this control protected or more, derived a new form then you have problems. Nasty, huge problem if this is caused by a bug in Windows Forms Designer in 2005. The control on derived form is readonly (1) for designer - no more visual editing. Even worse, if you implemented control's events on derived form with previous Visual Studio 200x versions designer will yield an exception (2). And this "feature" affects third party controls, too. This bug is a joke compared to this "lack of feature".
In my view, this lockdown feature is horrible. I always used visual inheritance with 3rd party and it always worked just fine. Needless to say that this impacts design of my application tremendously. Again, if this is a new problem in WFD this has to be fixed as soon as possible - Microsoft, please?
UPDATE: The situation is unclear so far. It isn't clear so far what is wrong with designer and if this problem was introduced with Visual Studio 2005 or if it was there before in 2003 or even 2002.
UPDATE: I checked and saw that DataGridView was locked even in beta 2 this leads me to the conclusion that the problem was always there in VS 2005.
UPDATE: To be more precise, it is up to the control itself to deny its editing in designer when it is inherited. The readonly status was therefore implemented by Microsoft (in case of DataGridView and ToolStrip) or Developer Express guys (in case of XtraGrid, XtraBars and few others).
UPDATE: I checked the Prouduct Feedback Center and of course, I am not first person to notice this problem. This is one of the MS' response on the subject:
"Thanks for your problem report. I understand your frustration around this issue, but we disabled this scenario intentionally. We chose to not make the engineering effort it would have required to enable this scenario for Whidbey. This decision was not make lightly and we understand customers would like this functionality, but the existing visual inheritance architecture in combination with collection based controls makes it extremely costly to address. We hope to enable this in future versions. Until then, you'll have to use code to achieve this. Thanks again for your support of Windows Forms and ToolStrips." See the entiries here, here and here.
Now, my only hope is reduced to the fact that this problem might have been around since previous Visual Studio versions (and for sure it has been around since 2005 beta 2) which means, that, when carefuly using designer you shouldn't have problems (assuming as I worked with Developer Express controls normally until they disabled editing in the last version.
Funny - I would be happy to know that this bug has been around for a while.
I've posted about the problem of co-existance of DevExpress componenents here. And here is the fix, thanks to support:To fix the problem you need to delete the following registry key after installing the latest update.
Note: the RTM version coming on Monday won't have this problem.
Regarding to this post I just noticed that the WinForms suite 2005 RTM version (numbered 2.2) doesn't co-exist with non-whidbey 2.x version. You'll get errors when you create or open an instance of suite components such as XtraGrid while editors work just fine. Also note, that this version is an intermediate and not yet released thus the problem will be probably fixed by release data 7th November.