It's been a while since I posted anything here, but please forgive me - I'm in the middle of finishing every project I'm currently working on before I'm gone for my internship (hooray!). Since there's a lot to be done, this time I'll leave just a short note on some weird problem I've just encountered.
So, not to prolong too much, here's the thing:
If you have encountered a "The specified cast is not valid" when running tests (I'm using NUnit) that have anything to do with TextBox AutoCompleteCustomSource (namely, when you add something to the autocomplete source via .Add(string) method), mark your test with annotation RequiresSTAAttribute. No one explained what is wrong, but the solution works. Maybe I'll investigate what's going on when I'm over and done with all of my current engagements (read it as: never ;-)).
By the way, I'm using .NET 2.0, but it may still be a problem in higher versions.
Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts
Thursday, May 27, 2010
Sunday, February 7, 2010
.NET SplitContainer panels do not deserve a name?
For some time now I've been coding for a world-wide company called Zehnder. I'm implementing some logistic solutions for their Polish office workers. Technology limits: .NET 2.0.
Some part of the work includes UI - that is, Windows Forms. In order to split the form into two spaces, it seems obvious to use SplitContainer control especially designed for that purpose. Everything seems fine if one does not write unit tests for the UI. When it comes to doing so, a small shortcoming becomes visible - neither of the panels of the split container have a name! Unfortunately, the assumption of NUnitForms is that each control or form has it's own name; that is, one has to make sure that each control has a name. That is not a problem to name a control; it's a matter of simple assignments:
this.SplitContainer1.Panel1.Name = "Panel1";
this.SplitContainer1.Panel2.Name = "Panel2";
Not a big deal. But hey, where should one put that code? Is it the InitializeComponents() method body, which is strictly forbidden to be modified manually, a good place for that? Maybe. Until the Designer decides to overwrite this code. All in all, it seems that adding a separate method, let's say - InitializeSplitContainerNames() - and calling it after the InitializeComponents() method (in the form/control constructor) is the best solution (with all of the drawbacks this solution has).
I think.
Some part of the work includes UI - that is, Windows Forms. In order to split the form into two spaces, it seems obvious to use SplitContainer control especially designed for that purpose. Everything seems fine if one does not write unit tests for the UI. When it comes to doing so, a small shortcoming becomes visible - neither of the panels of the split container have a name! Unfortunately, the assumption of NUnitForms is that each control or form has it's own name; that is, one has to make sure that each control has a name. That is not a problem to name a control; it's a matter of simple assignments:
this.SplitContainer1.Panel1.Name = "Panel1";
this.SplitContainer1.Panel2.Name = "Panel2";
Not a big deal. But hey, where should one put that code? Is it the InitializeComponents() method body, which is strictly forbidden to be modified manually, a good place for that? Maybe. Until the Designer decides to overwrite this code. All in all, it seems that adding a separate method, let's say - InitializeSplitContainerNames() - and calling it after the InitializeComponents() method (in the form/control constructor) is the best solution (with all of the drawbacks this solution has).
I think.
Subscribe to:
Posts (Atom)