Develop Reference

Possible to access any XAML Window Object globally from codebehind?

I am converting my program from Winforms to WPF. With Winforms, it is easy to access a form from anywhere within code since the form seems to be static. However with WPF, I am finding this to be challenging. Example:
In WinForms, if I had a form with a text field, I could access it anywhere in code, and update the text field like so:
My.Forms.FormMain.txt_field.Value = "test"
In WPF, this same form is now a Window object and it seems the only way to call it globally is by using the following code:
Application.Current.MainWindow.txt_field.Value = "test"
The problem with using the Application.Current.MainWindow method is that this value is only available if the window is presented. My goal is to get a list of all of my Xaml Window objects and store them statically into global variables. This way if I need to update a property at a later time in code, I can easily do so.
So my question is, is this possible to accomplish in WPF?

There is a different way to implement WPF Window controls than WinForms, and that is through binding. To update the control's values, you have to set the Data Context of the Window with a view model. You have to implement a view model, which is a class file, implementing INotifyPropertyChanged interface. You have to declare properties here and notify the property changed event on their setter. Then bind those properties with your xaml controls. For details you can check 'Data Binding Overview' in WPF on msdn.

I have never done this, but u can try with Properties.
Something like
public string TexBoxValue
{
get {return txt_field.Value}
}`
But, i don't think this works with child window accessing parent window properties. Only other way around.
Other things u can do:
this way u can save your app important data and reused it after.
use Configuration Manager and store important in App.config file with Key - Value.
You can also create your own XML file with some of your app settings with your own tags!
It's easy and accessible from anywhere.
`

If I understand correctly, you are having trouble using Application.Current.MainWindow because it is typed as a WPF Window, which means you cannot refer to the controls on the window as members of the window.
The solution is to cast Application.Current.MainWindow to the type of the main window in your project (in the code below, MyMainWindow):
(Application.Current.MainWindow as MyMainWindow).txt_field.Value = "test'
The same applies to using windows via the Application.Current.Windows property, which holds a collection of all the open windows. Again, the Item property is typed as Window, so in order to use functionality defined in your windows, you have to cast them to the actual type of the window.
(Application.Current.Windows[0] as MyWindow).txt_field.Value = "test'

How to dynamically create a class out of the DataContext, in WPF?

Is it possible to dynamically get the binding properties for a view into a class and manipulate it in run time.
for example, if the DataContext is of type User that has 10 properties, but the bound properties are only 4, can I make a class that has these 4 properties only?

Doable, but difficult.
You must parse the visual tree, and visit every control using VisualTreeHelper (see: https://stackoverflow.com/a/874426/275330).
For every control you can get a list of its dependency properties (see https://stackoverflow.com/a/26367132/275330)
Then for each separate dependency property you can check if its value is set locally (see: Knowing if a DependencyProperty has not been set in XAML). If so - you have the value you need.
I've never used 1+2+3 together, so I don't know what additional difficulties you may have.

Validating Attached Property in Property Change handler

I am developing a custom control for Windows Phone 8, which is derived from ItemsControl, will have many child objects(another custom class). It needs to have an Attached Property IsMinonAxis which should be set only once by one of the child, and not more than once. So the below code will be a problem I want to avoid.
<WPGraphControl:GraphControl>
<WPGraphControl:GraphLine GraphDataPoints="{Binding SpeedPoints}" WPGraphControl:GraphControl.IsMinonAxis="True" />
<WPGraphControl:GraphLine GraphDataPoints="{Binding AltitudePoints}" WPGraphControl:GraphControl.IsMinonAxis="True" />
</WPGraphControl:GraphControl>
The problem is attached properties are attached to child controls, and not to the parent.
In the PropertyCHangedCallback (registered as part of RegisterAttached as part of PropertyMetadata) I can get the child object for which the property is being set, but I can't access the actual control instance (this) to be able to validate the whole collection of child controls as its a static method common across all instances .
One option I am thinking is to have another attached property (internal) which will be attached when the child controls are added, and then use that property to get to parent inside the callback, and fire the validation logic. It sounds like a overly complicated logic to me.
Could you please suggest what is the best way to handle situations like this?

Might be easier to have a non-attached property on GraphControl that takes a Element to be used. Its been a while since I did WinPhone XAML, but in WPF this would look something like:
<wpgc:GraphControl MinorAxis="{Binding ElementName=Foo}">
<wpgc:GraphLine x:Name="Foo" />
<wpgc:GraphLine x:Name="Bar" />
</wpgc:GraphControl>
Since you can only assign a single value to the property, then this would ensure that only one is set.

Making a grid of objects

I'm trying to make something like a quiz application where 3 questions will be brought up on screen at a time, allowing the user the check a radio button containing "Yes" or "No", and have an answer come up appropriately to his response. The questions will continually come from a database I'm using.
After a few attempts I've figured that using x:Name property is not a great solution, since it doesn't allow me to use a loop in order to change the questions and answers. Is there any other way to make a grid with the same types of objects in each cell, being able to access each object inside each cell of the grid in the code-behind?

Here is list of steps you need to implement,
Need to create QuestionModel, contains question properties, make sure your model inherits INotifyPropertyChanged.
Need to create ViewModel, which contains data objects, public/dependency properties
Need to bind/set data objects/properties on viewmodel constructor
Need to set your ViewModel as a DataContext of your View(.xaml) (You can create this on zammel directly and codebehind as well
Need to bind your UI objects like Question/answers/yes-no with viewmodel properties accordingly
WPF/Silverlight has their own fundamentals like Data Binding, Resources, Compiler, Dependency Properties. Above steps comprises MVVM design pattern. During each steps, please google for specific stuff.

How can I edit the properties of a button in a form, where the button is on a custom user control?

I have a custom user control, onto which I place a button control. I set the access modifier of the button to Public. When I drop the user control onto a form, I see the button, but am not able to select it or edit its properties in the form designer.
Ultimately, I want to create a far more complex custom wizard control, with a content panel, "Back" and "Next" buttons, etc. I have successfully created a content panel to which controls can be dropped into at design time on the main form.
However, I am bulked at not being able to edit nested controls on the user control itself.
When inheriting from a user control, or inheriting from a form, one can typically edit properties of controls whose access modifier is set to "Protected".
What do I need to do to be able to access controls of the custom user control from the designer of the form?

I think you need go to the user control designer view to modify the properties of the button (instead of the form where the user control is placed), since it is nested in the user control.

You can make basic changes to a child control of a user control on a form to the limited extent that you can expose the properties of interest via the parent user control designer and support the property changes at design time. You can make much more complex design time behaviors by writing your own custom designers but that is a potentially difficult to very difficult undertaking.
There is a good reason why it does not work the way you probably think it could and should and if you think about it carefully enough for a while, you will understand why. When you inherit from an object, yes you can change properties etc, but in this case you are creating a new type, so you can modify, add, redefine properties.
But when you drop a user control on a form, you are not creating a new type. You are creating an instance of a type, the user control, that is already defined. To the extent you can modify properties, you are modifying state that must be preserved for that instance. State must not only be persisted, but user controls also often involve painting etc so state changes can also have complex behavioral effects and this is a potentially complicated requirement that cannot be completely generalized.
So there are some modifications that are not possible at all, because they imply modifying the type, and you already have a type, you are only creating an instance. For the rest of the possible range of modifications that are ultimately state based, the platform only supports so much of the total possible state management.