I've faced with problem yesterday. I want to use System.Drawing.Color structure in Android and iOS projects. Xamarin documentation claims that MonoTouch framework has System.Drawing.Color structure (link - http://iosapi.xamarin.com/?link=T:System.Drawing.Color). But in monotouch.dll namespace System.Drawing hasn't structure with name Color.
What did I do wrong?
Add a reference to the OpenTK library and you'll have System.Drawing.Color available. The doc you linked was indicating it:
To add a reference: double click on Reference in your project, and under the **All* tab, select OpenTK,
It clearly states "System.Drawing.Color Structure", i.e. not
namespace. This means you cannot do something like "using
System.Drawing.Color;" in C#.
For all your color needs in iOS, you need to use MonoTouch.UIKit.UIColor, the type that MonoTouch uses in most cases (e.g. all the UIKit API).
I am not sure for Android, but I guess you need to use Android.Graphics.Color
Related
I have several questions regarding Visual Studio:
two developers using VS2012 and VS2013 are working on the same project but the one with the lower version studio cannot use ctrl+F12 to find the implementation of a function.
Those implementations are separated from the interfaces in another library-project.
Second question is strictly concerning VS2013:
two different solutions both are MVC, the first one is version 5.2.2.0 and the other is - 4.0.0.0
in the second project I am able to find a view by using F12 on in the controller (e.g. return View(model); or return View("CustomFormat", model);)
However I am not able to do it in my first project.
Any information on why it is the way it is or how to fix it, would be appreciated.
TLDR;
Q1: Why doesn't ctrl+F12 work in VS2012 when decoupled implementation from declaration (but it does work in VS2013)
Q2: Why doesn't F12 when pressed on 'View' return View(model); find the View itself regarding using 2 different MVC version projects (one is 5 and the other is 4)
I am stuck with this issue and I cant seem to solve it. I have my logic in a PCL and a a .Droid and .iOS clients.
I need to use the [serializable] attribute in my logic so I need to add a reference to system.runtime.serialization. The problem is there is a different dll for android and iOS how can I manage this? I did not encounter this problem before because I used shared files between the projects so each project had its own reference to the correct system.runtime.serialization and I could use the [serializable] attribute with no problems.
Have I missed something?
Thanks
Amit
In general I'd recommend avoiding trying to use the SerializableAttribute in portable code. That type of serialization is basically not portable. However, if you really need to do it, that attribute is actually treated specially and is represented by a bit on the type as opposed to a normal attribute. So if you define your own attribute with the same name and namespace in a PCL, the compiler will emit the bit and everything may just work like you need it to.
The generated designer.cs properties are private by default (at least without manual tweaking of generated code). This makes coding against something like a UITableViewCell feel much different than if I were doing this in Objective-C.
The popular way in the case of UIxxxViewCells, at least from what I can tell, is for the UIxxxViewDataSource to populate the IBOutlet properties, and that the cell should only be responsible for anything related to drawing/rendering the view.
With Xamarin.iOS, we are unable to access these properties from the data source, and instead are required to provide additional setter methods to populate the cell. In this way, the cell is responsible for setting it's own properties.
Is this just "The .NET way" of doing things?
It's so that we don't break encapsulation by default.
The outlets belong to the object they're on, it should be able to choose whether they're able to be modified from the outside. The fact that they're properties is an implementation detail of the Xamarin.iOS outlets system - you should think of them as private fields.
If you wish to expose them, you can create properties that do so - preferably read-only.
It was probably done that way because that's how the other GUI designers in MonoDevelop worked at the time (still do). Auto-generated bindings to the native controls used by the user-designed control for toolkits like Gtk# are also created as private.
I'm not sure if other UI designers for .NET work (I've never used Visual Studio to develop GUI apps using Windows.Forms or WPF).
Feel free to file a feature request on https://bugzilla.xamarin.com to make them public - I'll gladly implement it, I think it probably makes more sense for them to be public. I haven't changed it mostly because no one has expressed that they wanted it be any other way.
I tried the simpledroid with INotifyPropertyChanged and ICommand successfully.
I want to do the same with monotouch and xib designer,but without TouchDialog. Is there a way to implement without inheriting from mvx class as in monodroid?
Is it possible to do the same with MonoMac without Dialog as Portable Library in MonoMac or XaMac in supported now?
I understand what is your goal.
I think you want to start learning MvvmCross for Monotouch with a basic application example as you probably did with SimpleDroid. I tried to do the same without success.
Why ? Because SimpleDialogTouch is an "Advanced" example in my opinion. When you learn Monotouch, you use xib to design your view. But the sample tells you to learn a new tool "Monotouch Dialog" which is a way to display controls programmatically.
You get those errors because the sample implements the ViewModel only for Dialog and not for xib or classic binding.
Finally, you will have to dig into MvvmCross to build your own SimpleTouch implementation. The problem is that you don't have a lot of documentation, but Stuart is the best supporter for a beginner or you can switch to advanced Mvx features if you don't need to understand the underground of MvvmCross. There are a lot of samples, tutorials and posts to tweak Mvx.
Hope that helps.
Is there a way to implement without inheriting from mvx class as in monodroid?
I don't believe this is supported in the current source.
There is an effort underway to separate out the databinding code in MvvmCross so it can be used more easily with other frameworks - e.g. we might try porting MvvmLight across too. This is where my effort is currently focused.
If you need this now, then I think you could fairly easily create this simple binding yourself if you wanted to - but you'd have to take a look at what the SimpleDialog version does - it's not too big a code to copy across to the XIB version - https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Dialog.Touch/Simple/MvxSimpleTouchDialogViewController.cs
But... why not just implement a proper portable MvxViewModel instead?
Is it possible to do the same with MonoMac without Dialog as Portable Library in MonoMac or XaMac in supported now?
Portable libraries are not supported in any release from Xamarin yet - there is an unofficial installer that Jeff very kindly provided - but it's not a release...
For MvvmCross MonoMac/XaMac support, there is one non-PCL version from #deapsquatter around, but I don't believe this has data-binding yet.
I will be working on a PCL and data-binding release for MonoMac or XaMac - but it's on a spare time basis - no-one's come forward with a customer project to fund that work yet. If you or anyone wants to assist with this port, then you are very welcome... but it will be quite technical work - there are changes I intend to make 'under the covers' - so the easiest place for others to help will probably be in later work - adding more views, more bindings, doing QA, making samples, etc.
Note: "Simple" bindings are not the future for MvvmCross and may get dropped from a future release. However, this will only happen after I've separated out the Binding code so that it can be used with other libraries - the first of which will probably be a simple binding example.
I personally don't see much difference or advantage in using these so-called Simple bindings... but maybe I'm missing something...
I am creating a series of window mockup templates based on the excellent Mockups library available on CodePlex.
I'm using their BaseMockup as the base for my control as well, and I followed the same outline of the steps listed here for sub-deriving from existing controls (Create a new empty class, add your default style to /Themes/generic.xaml, etc.)
The control is working great - the only thing is that it doesn't show up in the Assets library. I think this is because it's sub-derived, or because I need some attribute (the equivalent of the ToolboxItemAttribute for WinForms controls? ... which didn't work) to get it hooked up.
When I modify the code to derive directly from Control, it shows up - no custom attribute necessary. Of course that defeats the purpose of what I'm trying to do though...
The only thing I can find are several articles telling me to muck with registry keys, and none of them are clear or suggest a definitive way to do this with Blend 4. That last one advertises as a Blend 4 tips article, but admits at the end that it plagiarizes the content from the other two (for Blend 3).
Is that my only option - register my DLL? Is there a better way to do this?
A while ago I wrote a blogpost about this. I've included a .reg file and a .bat file for setting up the register and some directories. I think that's what you are looking for.
I believe you do need to muck with registry keys. Specifically,
32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
Create a new key with the name of your control assembly. Then edit the Default string value under this key and set the value to the directory where the control assemblies are installed. See here for a full example (using the Silverlight paths).
Found it - there is an analogue attribute after all, it's ToolboxBrowsableAttribute.
You have to go through a little more rigmarole to get it set up, but it works great - no registry mucking necessary. It requires creating a designer metadata provider class, attributing your assembly so it's designer-discoverable, and then adding the attributes to your sub-derived controls inside your metadata provider.
Make sure you choose the appropriate version of the page for your version of Visual Studio, because the interface changes a good bit between 2008 and 2010.
This article on CodeProject has some good, real-world examples of setting this up. They're all in the 2008 style though, so bear that in mind if you're using 2010.