We Keep Coding

In MVC-4 (C# ) Is it best to use one large object that can be used many places, or several small objects that align with the views

I am new to asp.net MVC. I am adding to a project that has already been developed. There is currently a large user object (Fname, Lname, email_addr1, email_addr2, phone1, phone2, title, company, division...) It has around 18 fields.
I need to create two new pages that each use different fields of the current user object. As it has already been created, do I use the original object, and just use the fields I need?
Or do I create two new user objects, that have exactly the user fields needed for that view so that I can use them as view models?

If your Two Pages are separate in a way that each time you would navigate from page a to page b, the server has to handle a request then it would be smarter to shrink down the object in case the size of it impacts response time. Otherwise, if your Two Pages are not SSR (Rendered at Server Side), it would still be wiser to split the object into two smaller objects if and only if you fetch them via Ajax calls.
In any other cases, it will not result in any significant difference.

Its common to use 1 viewmodel for each view.
You'll maintain flexibility and independence.
Normally your view will change over time. If you tie them together, changing one will impact the other. In most circumstances this makes things harder, while making a copy of the fields initially is very easy.

How can I conditionally swap out the "User Input" part of my form?

I am creating a utility that needs to be flexible enough to use different types of data input by the user. Not just different data, as one user may enter "Rory Gallagher" another "Merle Travis" another "Louis Jordan" and yet another "Gatemouth Brown."
More like one user would enter "Rory Gallagher" another "42" and another both a date (such as 9/8/1956) and an ID value (such as "00034872184").
So the problem is with the GUI: how can I "swap out" the section of the form that prompts them for their input? It seems overkill to create several utilities that are 99% the same. But some "versions" of the app will just need a single "enter some value" label along with a TextBox, while another may need to prompt them for two or even more pieces of information.
I don't want to have an "Input Data" button on the form that would invoke another form, because when the user only needs to enter one single bit of information, that would seem quite bizarre.
I'm thinking the Strategy pattern may be in my future here, but the GUI part is still the conundrum. It would be easier if we were using WPF, but we're not. I guess I could still have a section of the form that I leave large enough to incorporate the "largest" scenario, but is that the best way to go?
UPDATE
I tried the suggestion below:
I added a panel to my form and created a user control via Add | UserControl and tried this:
panel1.Controls.Add(UserControl1);
UserControl1.Dock = DockStyle.Fill;
...but suffered an epic fail ("'PlatypiRUs.UserControl1' is a 'type' but is used like a 'variable'" and "An object reference is required for the non-static field, method, or property 'System.Windows.Forms.Control.Dock.get'")
UPDATED AGAIN
Epic success now with this:
UserControl1 usr1 = new UserControl1();
panel1.Controls.Add(usr1);
usr1.Dock = DockStyle.Fill;

I would suggest dynamically loading a different user control onto that section of the form. For design-time simplicity, you could put a panel where the dynamic control will be, and then just load it into that panel with docking turned on so it fills the whole panel. Then you can just create a separate user control for each set of data entry fields you need. For instance, if you had a panel control called pnlCustom, you could do the following in the form's load event (or wherever makes sense):
UserControl1 customControl = new UserControl1();
pnlCustom.Controls.Add(customControl);
customControl.Dock = DockStyle.Fill;

In my opinion, this is a Builder pattern.
Basically, think of your form as a "two-step view", which means the following:
Think out the structure which defines the form elements (e.g. textboxes, dropdowns, etc.),
Implement an abstract view builder (first step builder) so that in different situations you produce a different structure (remember, the structure is a common, no concrete UI components must be involved, just a structure which defines them),
Implement the abstract builder for all cases where the structure must differ,
Then implement the UI builder which takes the common structure and builds the UI coponents. Basically, this builder just translates the common structure into the platform specific UI components (such as win-forms textboxes or Html inputs).
Next step is to process the data obviously. For that you have an abstract processor and then concrete implementations for each situation (similar to the first step builder above).
Now it is clear that the UI construction and data processing can be associated 1 to 1, which means the situation is a Factory and it produces the view builder and data processor.
Pseudo code would look like this:
// construct the view.
var factory = Situation.GetCurrentSituationFactory(); //abstract factory.
var uiBuilder = factory.GetUIBuilder(); //abstract builder
var structure = uiBuilder.GetFormStructure([context goes here]); //build view definition
var viewParser = Platform.GetViewParser(); //abstract builder (step 2)
viewParser.ConstructForm([context with form goes here]); //build form UI
// later on, process the input data.
var input = viewPrser.GetInput([context with form goes here]); //input definition
var dataProcessor = factory.GetDataPocessor(); //strategy
dataProcessor.Process(input); //execute processing strategy
In addition, this does not conflict with dynamic controls or anything else you want to use to construct the form. Just implement your abstract concerns correctly.

Save value of custom field type

I am new to SharePoint developement and have a few startup problems which I hope you will help me with.
I am trying to make a custom field type and I am using WPS builder to create the project. Right now I have the following files which are all compiling just fine :)
SuperLookup3.cs
SuperLookup3Control.cs
SuperLookup3FieldEditor.cs
SuperLookup3FieldEditor.ascx (controltemplate)
fldtypes_SuperLookup3.xml (XML)
I have tried look at this example but I just can't get it to work.
My questions
How is the relationsships between the files?
I can see an override of UpdateFieldValueInItem() which is setting the value to the selected item of a dropdown list. But this method is never called (when debugging). How can this be?

Some general advice would be to post this question to the SharePoint Stack Exchange site (if this answer is unsatisfactory), since there are a lot more SharePoint developers there.
From what I understand of that example, it seems to be quite a complex Custom Field Type to start with (given that it has multiple values). There's a good straightforward and pretty well explained tutorial on MSDN that you might want to try out: Walkthrough: Creating a Custom Field Type
Here's a brief explanation of your files (and the classes they contain):
This is the main class of your field, which derives from the SharePoint field base class (SPField). Your naming seems to indicate you're creating a lookup derivative; if so, you may wish to derived from SPFieldLookup.
This is the class the creates the form control displayed on a list item's New, Edit, and Display forms (but not the List View). It's a go-between for the forms and the item's value for this field.
&
This is the section displayed on the Add/Edit Column page. I would expect 3. to have the ending '.ascx.cs' instead of '.cs', since it is the code-behind for 4.; which may be the cause of your problem. This control sets up your field; associating the class in 1. to the list.
This is the field declaration. It says to SharePoint "Hey, I've created my own field; go look here to find it.", and directs SharePoint to the class in 1., which makes the field available on the Add Column page.

Monotouch: send data back down the stack to another ViewController

I have a question concerning Monotouch.
The situation: I have 2 ViewControllers. The first (let's call it VC-A) looks similar to the contacts edit screen, meaning it has a TableView with multiple Sections each containing Buttons and TextFields. Now when the user clicks one of these Buttons, he will get to the second ViewController (VC-B), which displays a TableView containing data from the database. When the user clicks on any of these rows, VC-B will be closed and i want to display the selected database entry (string) as the title of the Button (in VC-A) which opened VC-B in the first place.
When I did an objective-C project last year, I managed to send data back down the stack by using delegates, but I haven't found a way yet how this works in Monotouch.
I have read several questions here on SO about using the AppDelegate or using singletons, but I'm not sure that this is the right way of returning data from a subview.

You can kind of copy the delegate pattern. Add a C# delegate to your VC-B that takes one parameter, some data structure.
In VC-B's "ViewWillDisappear", call the delegate it it is not null and pass the data on to it.
This way, your calling VC can get acces to the data but you don't need tight coupling between the two controllers. All it has to do, is register a delegate-method in VC-B.
As MonoTouch is .NET4 you can use Func<MyDataStructure> or Action<MyDataStructure> and don't need to use full qualified delegate types.

I have a static singleton class that I use to store "state" type data about my app - current settings and selections that are needed in many different places in the app. That's one way to approach this.
You could also pass VC-B a reference to VC-A when you create VC-B, so that it can explicitly access it's parent view and pass back values that way.

I actually prefer to use TinyMessenger for cross container calls I find this to be very very useful when you don't want to keep references to your heavy viewcontrollers around which could potentially result in memory leaks!
var messageHub = new TinyMessengerHub();
// Publishing a message is as simple as calling the "Publish" method.
messageHub.Publish(new MyMessage());
// We can also publish asyncronously if necessary
messageHub.PublishAsync(new MyMessage());
// And we can get a callback when publishing is completed
messageHub.PublishAsync(new MyMessage(), MyCallback);
// MyCallback is executed on completion
https://github.com/grumpydev/TinyMessenger

How to call form several time but with diffrent variables!-C#-Winforms

I am new to C#.Winform.
I stuck in the situation where i want to call confirmation form from 5 different buttons event.Like Train ticket confirmation button,vehicle book button, flight book button.
But on clicking each button i want to call (let say form2) but each time with different context!
Like when i call from train ticket.(User info and payment info on form).
When i call from flight(User info and flight booking info on form).
How i do this!

You don't "call" a class. You might create an instance of a class, or call a method in a class. It sounds like in this case you may just want to call the constructor, passing different arguments depending on the context:
using (Form2 form2 = new Form2(userInfo, flightBookingInfo))
{
form2.ShowDialog();
}
(Or whatever you need to do, of course... this was just a guess.)

Honestly, at this stage of your programming skill level, I'd suggest you create seperate forms for each kind of confirmation. There are certainly ways to reuse a single form for something like this, but to do that well may be a bit more advanced than you're current skill level.
There's a concept called the Single Responsibility Principle, which says that any object should only do one thing. While it's possible to fit SRP into this scenario, like I said it would take a lot more knowledge of how things work than you likely have right now (I say this based only on the way you phrased your question).
Keep things simple, make a FlightConfirmationForm, and a TrainConfirmationForm. Maybe you can share some common code between them and derive from a common ancestor. And, as your skills grow, you can look into ways to refactor and simplify the system.