Trying to get my head around static cells in tableviews and adding iboutlets. When using static custom cells, whenever I try to add an iboutlet the only options I get when ctrl-click-drag are 'action' with object 'exit'. I want to add a iboutlet reference. Can I not do this with Static cells??
You have to go to the StoryBoard and click on the TableViewController. You just have to set the Class attribute as the name of your Class that you are using which inherits from UITableViewController.
After that, you will be able to add the #IBOutlets.
Related
In the code behind of a main window of a WPF project, there is a grid with a specific name in XAML page as follow:
<Grid Grid.Row="2" x:Name="PnlGraphics" Margin="5"></Grid>
In another class (e.g. ClsChart) in a function, I need to set this grid value.
Here is the piece of code that uses that grid name in clsChart class:
PnlGraphics.Children.Add(host)
I tried many things as below, but my problem has not been resolved yet.
1- I made an object from the main class and tried to use that to get access to the grid name. But in practice, it gives an error when I run the program!
Dim mainClass1 as new mainClass = new mainClass()
mainclass1.pnlGraphics.Children.Add(host)
2- I made a panel control in the ClsChart class and tried to fill the grid in the main class.
In the clsChart class:
Private _panel1 As Panel
Public Property Panel1 As Panel
Get
Return _panel1
End Get
Set(value As Panel)
_panel1 = value
End Set
End Property
Panel1.Children.Add(host)
and in the main:
ChartObject.Panel1 = PnlGraphics
3- I changed the grid modifier to the public.
Any thought on this?
Instantiate an clsChart object in your main class and pass the grid as parameter to the constructor (e.g. clsChart c = new clsChart(grid)). In the constructor you assign grid to some member variable of type Grid and use it as needed.
My goal is to create an array to handle seating in a theater. The array part is fine , but I want the array to display an "x" or a 1 to show if a seat has been taken by someone , but I also want to be able to save a name to that location in the array so that I can check who is sitting where.
Let me know if you need more info.
Assuming your seating are in a grid style (Cinema)
Create an object like:
Public Class SeatingArrangement
Public Property Row As Int
Public Property Col As Int
Public Property Occupier As String
End Class
Then, create a list out of it
Public Property Items As New List(Of SeatingArrangement)
Then you can use Linq to manipulate the items, if occupier is null or blank, it's not taken, if the not null/blank, it's taken by the occupier (name).
For you displaying:
You can using INotifyPropertyChanged.PropertyChanged event to update the UI and optionally show occupier name on the tooltip.
I just discovered than I can do the following:
var button = new Button();
button.SetValue(TextBlock.TextProperty, "text");
var text = (string)button.GetValue(TextBlock.TextProperty); // text is "text"
While the above example is a bit unrealistic, it does show that I can attach a regular dependency property onto another object. It doesn't have to be a an attached property (TextBlock.TextProperty is not registerd with DependencyProperty.RegisterAttached().
This bares the questions why are there attached properties in the first place? The only difference I can see for now ist that I can't attach regular dependency properties in XAML. But that's about it. Are there any other differences?
Update:
To make it more clear, the below code works and looks pretty close to an attached property from the end users perspective:
public static class AttachedPropertyDeclarer
{
public static readonly DependencyProperty TextProperty = DependencyProperty.Register(
"Text",
typeof(string),
typeof(Button),
new PropertyMetadata(default(string),OnTextChanged));
private static void OnTextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
// do something when text changed
}
}
...
button.SetValue(AttachedPropertyDeclarer.TextProperty, "text");
var text = (string)button.GetValue(AttachedPropertyDeclarer.TextProperty);
Compare this to the attached property way:
public static class AttachedPropertyDeclarer
{
public static readonly DependencyProperty TextProperty = DependencyProperty.RegisterAttached(
"Text",
typeof(string),
typeof(AttachedPropertyDeclarer),
new PropertyMetadata(default(string),OnTextChanged));
private static void OnTextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
// do something when text changed
}
}
The only effective differnce to an attached property here is that I have to declare the owner of type Button whereas in a attached property it would usually be AttachedPropertyDeclarer. But this only needs to be done if I need a changed event handler (i.e. OnTextChanged).
Regarding your example, you have not as you say, attached a regular dependency property onto another object. All your code has achieved is to store a string value in a Dictionary along with a reference to your object. That does not make it an Attached Property - importantly, you cannot access that string value from the Button directly, as there is no Text property on a Button.
What your code does is actually very similar to this:
Dictionary<object, object> values2 = new Dictionary<object, object>();
var button = new Button();
values2.Add(button, "text");
string text = values2[button].ToString();
Now to answer your question:
The main reason to declare an Attached Property is in order to add a property to a type that you didn't declare, thereby extending its functionality.
A great example of this would be to add a SelectedItems property to the ItemsControl or ListBox class. In doing so, we extend the current, or default functionality of the class. Another good example would be declaring an Attached Property that automatically brings added items into view (again in an ItemsControl or ListBox class).
UPDATE >>>
According to your comments, you seem to be refusing to accept the differences that I have outlined... you said:
There is literally no difference from the end users perspective except that I can't use it in XAML.
Firstly, do you not think that this is a huge difference?.. you won't be able to use it for data binding for a start. Furthermore, you keep saying that you can attach a property to a type that you haven't declared using a DependencyProperty, but you are 100% incorrect. You can reference an Attached Property directly in both code and XAML, while you can't reference what you are calling your attached property directly in either XAML or code.
All you are doing is storing a value in a Dictionary and you certainly don't need the overhead of a DependencyProperty to do that. There really is no comparison between doing that and declaring an Attached Property. From the Attached Properties Overview page on MSDN:
You might create an attached property when there is a reason to have a property setting mechanism available for classes other than the defining class.
Note the following part: a property setting mechanism
Adding values into a Dictionary is not a property setting mechanism. So again, you lose the ability to use your pretend Attached Property in Styles, Animations, Triggers, etc.
To clarify this situation for once and for all, you can develop a simple test project. Implement the IList SelectedItems Attached Property for a ListBox that I mentioned (you can find online tutorials for this) and then do the same using your pretend Attached Property (if it is even possible). The difference in the simplicity of development bewteen the two will clearly show you why you should use an Attached Property instead of a regular DependencyProperty.
If you look closely at dependency property identifier, all DP's are registered with class DependencyProperty and we pass the Owner class type and property name at time of registration.
Sample:
public static readonly DependencyProperty IsSpinningProperty =
DependencyProperty.Register(
"IsSpinning", typeof(Boolean), typeof(OwnerClass));
At time of registration it creates some unique hash code combining property name and owner class type to represent each DP uniquely.
So, when you set value for that DP on some object like in your case on Button, code flow is like this:
First it will get the unique value generated at time of registration of property and add the key value pair in private dictionary named _effectiveValues declared in class Dependency Object with Key set to unique hashcode at time of registration and value being the value set by user.
Note - No written documentation for this on MSDN but verified this by peeking into source code using reflector.
So, when you set the value from code behind it will work like I mentioned above because it does not validate before adding value in the dictionary if it belongs to that type or not and fetching value will get you the value from dictionary.
Not sure but might be constraint is there in XAML only where WPF guys enforced the type check. Sadly there is no written documentation for this on MSDN.
Attached properties are discovered, when you want to have control over an existing control, but dont want to extend it. A pretty good example is, there is no way to bind BlackOutDates property in XAML for WPF DatePicker. In that case you can use an Attached Property to attach a custom functionality to map the BlackOutDates. This suits good in MVVM, since attached properties provided way for binding in XAML.
public class BlackOutDatesAdapter
{
public static List<DateTime> GetBlackOutDates(DependencyObject obj)
{
return (List<DateTime>)obj.GetValue(BlackOutDatesProperty);
}
public static void SetBlackOutDates(DependencyObject obj, List<DateTime> value)
{
obj.SetValue(BlackOutDatesProperty, value);
}
// Using a DependencyProperty as the backing store for BlackOutDates. This enables animation, styling, binding, etc...
public static readonly DependencyProperty BlackOutDatesProperty =
DependencyProperty.RegisterAttached("BlackOutDates", typeof(List<DateTime>), typeof(BlackOutDatesAdapter), new PropertyMetadata(null, OnBlackOutDatesChanged));
private static void OnBlackOutDatesChanged(DependencyObject sender, DependencyPropertyChangedEventArgs e)
{
var control = sender as DatePicker;
var list = (List<DateTime>)e.NewValue;
foreach(var date in list)
{
control.BlackoutDates.Add(new CalendarDateRange(date));
}
}
}
Binding in XAML will look like this,
<DatePicker VerticalAlignment="Center"
Width="200"
local:BlackOutDatesAdapter.BlackOutDates="{Binding BlackOutDates}"
DisplayDate="{Binding DisplayDate}" />
In the callback of property, you can do your own mapping of adding the dates to DatePicker. For more information, please read this post.
I have a Module,Within the module .I need two Ribbon buttons "Create" and "Edit".Both these buttons point same View and ViewModel.The only way i can distinguish these is using the command parameter property part of Ribbon Button.I am using Navigate View to move to the View.I want to pass additional parameter to ViewModel constructor saying the invoke is from Create or Edit.Any suggestions??
RibbonButton has a Tag property:
http://msdn.microsoft.com/en-us/library/microsoft.windows.controls.ribbon.ribbonbutton.ASPX
http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.tag.ASPX
When defining the buttons, you can set Tag property for each ribbon button. You can then extract Tag value in your event handler and react accordingly.
I would bind Create and Edit buttons two different Commands e.g. CreateCommand and EditCommand. I would pass any additional details about the caller in the corresponding Execute methods of the Command.
Sample Code:
void CreateCommandExecute(object o)
{
YourMethod("Create", o);
}
void EditCommandExecute(object o)
{
YourMethod("Edit", o);
}
void YourMethod(string caller, object commandParameter)
{
// Your logic goes here
}
You need create two diferentes Commands in your ViewModel:
1- CommandEdit --> Asingned the CommandProperty button Edit by binding;
2- CommandCreate --> Asingned the CommandProperty button Create by binding.
Is not good idea shared logic in the shame command behavior.
I am reading data and outputting it into an interactive printer map. The printer positioning data contains the x coordinate, y coordinate, make, model, and IP of the printers. I create an image using this data and position it. The problem is is that I'm trying to figure out some way to bind the make, model, and IP to the image so I can read it easily in future interactions with it. For example, something like this would be nice:
printerImage.Attribute("Make", "HP");
Is this possible/advisable?
Create yourself class if you haven't already done so that has all the properties you need, your data source may already be providing such an object.
All FrameworkElements including Image have a Tag property to be used for your exact reason.
printerImage.Tag = instanceOfYourPrinterInfoClass;
You can then retreive the info you need with:-
YourPrinterInfoClass info = printerImage.Tag as YourPrinterInfoClass;
Edit
Having said that possibly a better place than Tag to assign the object is DataContext. You could for example then add a Tooltip that renders these details when the mouse hovers over the image.
I take it you are using System.Windows.Controls.Image, correct? In that case it's a DependencyObject, so you can define and set attached properties on it.
public static class PrinterImageExtensions
{
public static readonly DependencyProperty PrinterMakeProperty =
DependencyProperty.RegisterAttached("PrinterMake", typeof(string), typeof(ImageExtensions), new PropertyMetadata(null));
public static string GetPrinterMake(Image obj)
{
return (string)obj.GetValue(PrinterMakeProperty);
}
public static void SetPrinterMake(Image obj, string value)
{
obj.SetValue(PrinterMakeProperty, value);
}
// ...
}
Then use the attached properties like this:
PrinterImageExtensions.SetPrinterMake(printerImage, "HP");