The WinRT API function DataPackage::SetStorageItems takes a parameter of type IIterable<IStorageItem^>^. What I have is a single StorageItem^, not a collection.
I'm a bit confused as to how to create an IIterable collection from this, since I can't find a WinRT collection class that implements the interface. I realize that I can create my own class using IIterable as a base, but my guess is that there are existing classes that I'm just not seeing.
What am I missing here?
I guess this is obvious, but: C++, VS11, Win8, Metro.
I think you want the Vector class from the C++/CX-specific namespace Platform::Collections:
DataPackage^ package = …;
IStorageItem^ item = …;
Vector<IStorageItem^>^ items = ref new Vector<IStorageItem^>();
items->Append(item);
package->SetStorageItems(items);
Related
Winrt::Windows::Foundation::Collection only has interfaces no concrete collection type.
I have been told to use Platorm::Collections, but not sure how you get to that from Winrt::Windows::?????. I thought its only for C++/Cx
3.I have copied and used the Observable_Vector in PhotoEditor sample but am getting error on build saying my type in vector does not implement GetTrustLevel().
If i cannot use Platform::Collections in WInrt, that means currently there is only one example of how to use collections with Winrt (PhotoEditor) and that will also mean onyl concrete collection in Winrt is the Observable_Vector in phtotEditor.
Need help to clarify the scope of collection in c++-Winrt.
And also any help as to why am Getting Trust level error when using same Observable_vector from PhotoEditor.
Thanks
In general, you should not have to implement your own collections. C++/WinRT provides a set of helper functions for creating a variety of common generic collection types. For example:
using namespace winrt;
using namespace Windows::Foundation::Collections;
int main()
{
IVector<int> a = single_threaded_vector<int>({ 1,2,3 });
IObservableMap<hstring, int> b = single_threaded_observable_map<hstring, int>();
}
There is also support for creating custom collections. I described some of those options here:
https://kennykerr.ca/2018/05/12/cppwinrt-creating-collections-simply-efficiently/
Basically that. I'm wondering how to get the functions/methods given a KClass... looks like I can only iterate over the properties and extension properties.
Update: You can now get functions of a class with extensions declared in package kotlin.reflect: functions, declaredFunctions, memberFunctions, staticFunctions, etc.
Kotlin reflection is a work in progress at the moment. We plan to ship API for introspecting functions in the next milestone, presumably at the end of this summer.
Meanwhile, the only workaround is to use Java reflection for this task.
Kotlin reflection is more full featured in later milestones include the 1.0 betas.
View the overview documentation for Kotlin Reflection and specifically that of KClass.
For example, given a class you can see member functions using:
val functions = Someclass::class.declaredMemberFunctions
or properties:
val properties = Someclass::class.declaredMemberProperties
And to get from a Java Class to a KClass:
val kclz = this.javaClass.kotlin
See also: Kotlin.reflect package API docs
I have created a dummy projet for testing collection and ICollection.I have a user class and wanted to create a collection.Example -
ICollection<User> users = new Collection<User>();
Collection<User> users = new Collection<User>();
Both code are working fine whether I use Collection or I collection.Now can anyone tell me what is difference between above two line?
Thanks in advance.
The first line ICollection<User> users = new Collection<User>(); creates a reference to an object (Collection) that implements the ICollection interface whereas the second line Collection<User> users = new Collection<User>(); creates a reference to an object that is a concrete implementation of the class Collection where T = User.
In usage terms you would look to use the ICollection reference where your subsequent code needed to be agnostic about the type of collection it was dealing with, i.e. you could provide any object that implements ICollection and your code would still work. Great if your code is not tightly coupled (which we all want of course).
Using Collection as the reference tightly couples your processing code to Collection class, a specific implementation of ICollection and while you might still only use the methods defined in the interface, you might also use some specific features of the class and then you won't be able to easily replace the collection object with something different. There are good reasons for this but it's bit beyond the scope of an answer here, search for Dependency Injection and Inversion of Control here and I'm sure you'll find loads of background info.
Collection<T> is just an implementation of ICollection<T>. If someone creates another class that implements from ICollection<T>, you can easily use that one by replacing your first line with:
ICollection<User> users = new MyCustomCollectionCollection<User>();
Later on in the code, you don't have to fix anything since the same interface is still used.
ICollection is an Interface. Collection implements ICollection, so it works. ICollection is not a class, so this wont work:
ICollection<User> users = new ICollection<User>();
..because you can't instantiate an interface. An interface just describes what a class must implement.
because users is reference. in both samples it points to same object. behavior is defined by class of object and it is same.
Everywhere I read about the new DLR in .net 4, they say that a good use for it is reflection, and the code snippet always shown is something like
dynamic d = GetSomeObject();
d.DoSomething();
d.SomeMember = 1;
What does GetSomeObject() look like? I can't find anywhere that explains that.
I understand that it can be anything, but in the context of reflection what is it? Is it the assembly? an instance of a type?
The return type of GetSomeObject() will be an instance of some type. For example, here's what it might look like:
public Customer GetSomeObject() {
return new Customer("John", "Doe", 12345);
}
And then the code would say:
dynamic customer = GetSomeObject();
string s = customer.FirstName;
// now the "s" variable would have "John" in it
The GetSomeObject() can return anything. It might return a Customer object or a Product. And it doesn't matter! The idea is that when the variable is declared as being dynamic that when you call a method or a property, as you have shown, the compiler will generate code that uses Reflection to try and call the method or property. If they exist then the calls will succeed. If not then you'll get an error at runtime.
In the general case this example is just simplifying the usage of Reflection by having the compiler generate the code for you.
Having said that, if the Customer or Product object implement IDynamicObject themselves then they can do far more advanced stuff.
What you are describing is the duck-typing aspect of dynamic (there are other facets). The answer is that it could be anything:
a true dynamic object (IDynamicObject)
any regular object, via reflection
A useful example (for reading properties, at least) might be an anonymous type; it could also be a COM object, for example - or (in Silverlight) an object in the html DOM. Or it could be your vendor's Customer object that doesn't implement any common interface, but is remarkably like your own InternalCustomer object. Heck, it could be an IronPyton object.
Well, GetSomeObject() could, for instance, return an instance of type _ComObject. That's one of the primary reasons of having it dynamic, I think.
I think that it's more interesting, as far as dynamic, DLR and reflection concerns, to see what happend in line 2 for instance.
using dynmic you go like this
dynamic d = GetSomeObject();
d.DoSomething();
while with reflection it's a bit more noisy
var d = GetSomeObject();
var mi = d.GetType().GetMethod("DoSomething");
mi.Invoke(d,mi);
As I see it, the first one is more elegant and we are talking about an argument less method, things can go really crazy when you are interoping with COM or APIs with long signature methods. I been there ;)
This is my first time here, but I already found some good answers here, so I'd like to thank everyone.
I'm developping a small Flex application and I want to instantiate every class from a package into an array, so I can parse it afterwards. To clarify, I'm trying to ease a plugin management system for my application, with the old canProcess/doProcess routine :
My plugins are all in ONE package, including an abstract plugin class. First, I create one instance of every classes in this package (that's where I need help) and put them in an array. Then, whenever I need a plugin for an item, I parse every plugin class in my array with the canProcess method (the item is the parameter). If one plugin says yes, then I send the item to the doProcess method and stop parsing the array.
I know I could implement by hand every class in my package, but I'd prefer not bothering to do it.
Has anyone an idea ?
Thx
AS3 reflection doesn't allow you to list all classes in a package. You will have to write the class names to an (xml) file at the server, load it and then use getDefinitionByName to get Class objects from those strings and then instantiate them.
Consider the sample xml file:
<root package="boris.ratak">
<className>Plugin1</className>
<className>Plugin2</className>
<className>Plugin3</className>
</root>
load it with URLLoader and parse it like:
import flash.utils.getDefinitionByName;
var pack:String = String(xml.#package) + ".";
for each(var cl:String in xml.className)
{
var name:String = pack + String(cl.text());
var Type:Class = getDefinitionByName(name) as Class;
pluginArray.push(new Type());
}