Develop Reference

Multiple input-ouput and steps winform application

I am developing a winform application where a set of classes and its methods calculate a geometry from 3d points.
As there is some input from the user needed from step to step in the algorithm we have designed some buttons which represent the steps. The intermediate data is stored in a class (maybe we use a structure in future Versions), so as the user input is. As result of pushing the Buttons the intermediate data will be calculated, saved and shown to the user, so that he can edit it, affecting to the calculation in the next steps.
The application began as an application which calculate everything in 4 steps but now we have more than 10 steps so we have divided it into 3 parts (horizontal geometry, vertical geometry and other...). Now I am doing some divisions because everything is getting too complex to manage all the gui interaction in one Form so I will create user controls for the smaller parts of the form.
Do you have general recommendations for me?
Should I have these data structures (input and intermediate data) in the controls I make or in the general form?

You should avoid mixing UI with the business logic. In that way when the program grows larger it will be a lot easier to maintain. It will also make it much simpler to write automated unittests.
If there is no particular reason you are using winforms. I would recommend using Windows Presentation Foundation (WPF). Read a tutorial about the Model View ViewModel (MVVM) design pattern. This is a very nice way of separating the UI logic from the business logic.
It takes some effort to switch from Winforms to WPF but it is definitely worth it.
EDIT (answer to comment)
Well it depends on the problem your solving. But generally:
In the MVVM pattern the:
Model would contain all your data and algorithms in classes/methods. The ViewModel would connect all the stuff you have in your Model and control the flow of the program, it will expose properties (commands, strings, numbers collections etc...) that view can bind to. The View is simply a "skin" that makes it possible for the user to communicate with the ViewModel. This is a very simple explanation of the MVVM pattern and I would recommend reading a tutorial about it.
The first time I came across this pattern it was called Model View Controller MVC, I like what AngularJS is doing by just calling it Model View Whatever MVW because there are a lot of MV* out there. But WPF is specifically built for MVVM.
The most important thing, if your creating a program that is going to be used and maintained for many years, is to keep the code as simple as possible. Instead of writing all the functionality into the Button_Click event handler (I have seen some programs that do this), try to write a class or method for every single task (use long descriptive names), this is also called Seperation of Concerns. In other words one method/class should not do more than one tasks. The nice thing is that you end up with a "program flow controller" (ViewModel/Whatever) that just passes data from one method to the next. And just by looking at the code you go: Aha I know exactly what is going on here! In the same way when you look at your algorithms (Model) they should do a single job and all variables should be have descriptive names. This makes it very easy for other developer to understand the code.
I also have very good experience with dividing my namespaces according to type. So every time you have more than one object of some sort (DataProviders, FileReaders, etc...) create a namespace/subnamespace for them and put them in there. So when your creating a new object/interface/enumeration... you always know where to put it. And you always know where to find again: Oh its a DataProvider so it must be located in ProjectName.Objects.DataProviders :)
So my recommendation is: have some fun and read about: MVVM and SoC

Probably state machine diagram will help you do devide actions in parts. It's a better practice, to create some of diagrams before codding.

ASP.Net: Best Way To Handle Multi-Function Form Based on User

In my scenario, let's say there is a ASP.Net 4.0 C# page containing a form with several inputs on it. Based upon which state the user is in, the form needs to act in entirely different ways: some fields might be required, some not visible at all, some might have different requirements (state A might only allow numbers 1-5, state B numbers 5-10), etc.
So, to simplify things, let's just say for any given input on the form, I need to determine whether or not it's required for the user, again based on their state. For those of you who run into this scenario quite a bit, what's the best way of implementing a system to handle this? I can see the following options:
Hardcoded - Difficult to maintain, obviously
Custom Database Rule Framework - This seems like it would work; however, it would be somewhat of a pain to maintain depending on how complicated the logic is
Windows Workflow Foundation - This would be able to handle just about any kind of logic, and be decent to maintain, but I'm not sure how this would do performance wise. (could be stored externally in database)
Dynamic Code - Store the logic in a database and run it directly based upon the user. I've never done this.. is it possible?
That's all I've come up with at this point, but I'm hoping someone out there has found an elegant solution to handle scenarios with complicated forms like this.
Thanks!

I have never worked with WWF, but I have encountered a scenario like this and implemented an entry form for it that works well and is easy to maintain once you understand the system.
I will discourage you from using hardcoded logic because any degree of complexity will quickly become impossible to maintain. I tried a hybrid approach that included some hardcoding initially and it did not turn out well.
I ended up creating, as you call it, a custom database rule framework. It is a little extra work to set up config forms to associate user groups with certain codes and pieces of functionality, but in the end it is well worth it for everything to automatically configure itself. Also in my case I was able to farm out user & code setup work to a supervisor in the department that uses the application, so that is a big plus.

Hardcoding -- not so hard to maintain, just depending on how fluid the rules are. I.e., if your "states" are relatively fixed, you're not adding new ones or changing the way those states interact with the page, then hardcoding might be fine. My only recommendation in this case would be to keep it in a separate class so you can re-use it, modify & re-publish easier, etc.
If you want the flexibility to change the rules a lot, create new states (I'm thinking of these as "roles"), then storing the info in a database would make more sense.
Personally, I use the database approach. It saves me some re-publsihing of the app, and it has allowed me to build additional interfaces for my end-users to have limited capability to manage their own app in terms of role assignments ("states" as you put it), etc. For example, my end-users can grant one of their clients (based on the client's login) access to a certain report. Or in your situation, they could change the min number for some range-validator your .aspx is using.
Since this approach lets me delegate some admin functions to my end-users, it allows them to do on-the-fly changes (to a limited extent), and also saves me a lot of rush-work / do it yesterday work as far as my own to-do list is concerned.

Checking-in Designer Generated code into TFS, issues

I just had a conversation with my manager relating to checkin\out policies on a project I'm currently working on. Basically I tried to edit a file that was already checked out by another developer and I couldn't - I asked my manager why we couldn't edit the same class at the same time and he gave this reason for turning that functionality off: We had a lot of problems with developers editing the same Form (or anything visual done in the designer) and then cheking it in. Merging the changes in the designer generated code was a lot of hassle...
As I'm writing this I'm struggling to see what problem they were having - surely they were getting the latest code before trying to check something in??
Have any of you come across problems with editing the same Form (or something in the designer) as another developer and then checking into TFS? If so how did your team get around the problem? Did you also turn off the ability for developers to work on the same class?
EDIT: The following post (found here) is exactly the problem my manager was describing. Anyone know of a simpler way to resolve the issue than the ones in that post?

I would argue that the solution to your problem would be to establish best practices for source code modification.
Discourage people from going into UI code and arbitrarily jiggling the components around in the designer. Any reasonable UI modifications should be easily mergeable. Your best bet is to try and educate people as to the best way to merge in any given source control system. Also, as helpful as the designer is, ignorance of what code is being automatically generated in the background will be significantly detrimental in the long-term.
People who insist on locking checked-out files for the reasons you stated in your post typically wait long periods of time to check their code in. Naturally, the more time passes, the more code gets modified, so it makes merging difficult for these people. Checking in early, often, and incrementally requires people to think about their changes in stages, and for some coders, this is a rather painful cultural/psychological adjustment.

I've just checked back through the histories of some of my .designer.cs files and I can't see any changes that would cause a merge problems. There were no wholesale rearrangements of code for example.
Another thing to consider is to make sure that everyone does a "get latest" at regular intervals then any individual merge/resolution isn't going to be that great thus minimising the chances of anything going wrong.
It might also be worth investigating a 3rd party merge tool. There are plenty around.
Now it could be that the changes I've done are simple compared to the ones you've got so you should take my anecdotal data with a pinch of salt.

It can cause problems (in general) when a lot of people are editing UI concurrently. The merge logic will do a fine job merging things, but in a lot of cases the UI is drawn according to how things are added to the form. Your UI can get messed up quickly.
I don't know if I would use this as an excuse to enforce exclusive checkouts across the board, though. I might go from a (non programmatic) policy standpoint that says shared checkout for business logic, but exclusive for UI changes.
I would couple that with a strong MVP, MVC, or MVVM approach, though, which should limit the number of people that have to touch the UI concurrently.
As others have alluded to, keep one of the seminal rules of SCM in mind: merge early and often, and your problems are reduced. (along with that is "always get latest before you start working on the code).

Testing complex entities

I've got a C# form, with various controls on it. The form controls an ongoing process, and there are many, many aspects that need to be right for the program to run correctly.
Each part can be unit tested (for instance, loading some coefficients, drawing some diagnostics) but I often run into problems that are best described with an example:
"If I click here, then here, then change this, then re-open the form, then click here, it crashes or produces an error"
I've tried my best to use common code organisational ideas (inheritance, DRY, separation of concerns) but there never seems to be a way to test every single path, and inevitably, a form with several controls will have a huge number of ways to execute.
What can I read (preferably online) that addresses this kind of issue, and is there a (non-generic) term for it. This isn't a specific problem I'm having, but one that creeps up on me, especially with WinForms.

You're trying to do acceptance testing, not unit. It is useful to test whether all bricks of your system are properly connected together. But bricks themselves should be tested with unit-tests.
So if you have a functionality that takes some coefficients and makes diagram, test it separately from GUI from all sides. Give it all possible edge-cases of coefficients and test point coordinates it returns. It was just one unit, there will be dozens, hundreds or thousands.
After you're sure in your units, do few functional/integrational/acceptance tests to make sure your units play well together.
For unit testing you can use NUnit or built-in test system.
For acceptance testing look at FITnesse or search for commercial products.
And to get an idea of how to divide the application in units, read about MVC and similar architecture solutions.

Each of those principles (inheritance, DRY, separation of concerns) is not a guaranteed recipe for high quality code, of course. If you use your inherited and DRY method to divide by zero, then you're still doing something wrong.
My advice for hard-to-trace errors: logging! Log the internal state of variables at key points in the user's steps to reproduce the problem.

I'd try and map common user UI workflows (with slight deviations, perhaps using "foreach" on control lists to pretend you're a user spamming everywhere and changing stuff) as unit tests.
I wouldn't go as far as (click at (x,y)) but more firing events like "txtUsername_Focused", "txtUsername_TextChanged", "btnBack_Click", "btnForward_Click", "btnSave_Submit", of course with some handling if you get different forms showing as a result.

I have faced this problem (test every single path) with Windows Forms. But after moving to WPF,Silverlight the problem is solved. Use MVVM along with command pattern (basically ensuring that you have no code in code-behind files). Ensure that you have single responsibility classes. In your unit tests, you can simulate every scenario including button clicks and you will be able to test all possible paths.
I am not sure how you will be able to use MVVM and command pattern in WinForms. But, I am google will definitely provide you with some answers.

C# penalty for number of lines of code?

Are there limits or performance penalties on the amount of code inside of my home.cs form?
I am writing a database application front-end in C# in Visual Studio 2008. The way things are lining up, I am using a tab-page way of changing the info shown to the end users, instead of using new forms.
Coming from VBA/MS Access, I remember that if you go over a certain number of lines of code, it would produce an error and not compile. Will C# do this in Visual Studio 2008, or will I suffer a performance hit? I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations.

It's not the lines of code in your .cs files that you need to be worried about with regards to performance - it's the number of controls on your form at runtime that might cause problems. If it's just a few controls on a few tabs, you will have no problems. If it's hundreds of controls on lots of tabs, you may have performance problems (not to mention usability problems - I personally hate tab controls with more than one row of tabs).
Also, I don't think tabs are appropriate if the purpose of the UI is more wizard-like where you want the user to interact with all of the tabs in succession. Tabs are meant for presenting sets of options to the user, without requiring them to see all the options at once.
Finally, if the purpose of each tab is significantly different, I find that it's easier to encapsulate each bit of functionality as a separate form. With tabs, you could at least encapsulate each bit as usercontrols, and then have each tab on your form host one instance of a usercontrol.

The only problem i would foresee is that in the future its going to be very hard to maintain.
Try break the logic of that main form up as much as possible into classes so that when you need add something you can actually do it without having a fit.

If you are using tabs, you can still create custom user controls that will hold the content that goes in the tabs. Make a control per tab, and then you can keep your code for the different tabs separate. There is a walk-through on MSDN here.
In response to your comment above, about not showing the tabs, I would really re-think how you're approaching this. Why not simply have all of your user controls sitting on your main form, in a Panel if necessary, have them all set to Dock = DockStyle.Fill, and then change the Visible and Enabled properties based on which one you want to show? You may be making this harder on yourself than it needs to be.
More responses to comments - You may be looking for something like the CardLayout in Java. The source for the GNU Classpath version can be found here, it might give you some ideas on how to implement this.

"I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations."
In my experience, this attitude will ultimately leave anyone who has to maintain your code in the future with quite a headache, as it's an accepted practice to modularize your code so that the pieces that may change or the ones that serve distinctly different purposes are separated away from each other.
With that said, I don't think there is a limit imposed by VS on the length of your files, but I think you will run into some seriously frustrating performance degradation as your files become longer, especially while switching between design and code views.
I would urge you to save your future self and his/her sanity and break your code up logically into separate files. You'll thank yourself later!

It shouldn't be a problem.
Just keep good coding practices in mind and modularise your code for readability and maintainability.
On the other hand, if you put too many controls on your form, then it will probably take longer to load. Factor that into your design if you want a snappy interface.

Sounds horrible but I don't see any reason why it would be a problem.

I have a form that in inherited with my new job that had over 30,000 Lines. It is completely cancerous. Please think before you code and modularize!