Win8 M3 (7989) findings relevant to Managed .net & WPF/SL developers

alright, previously I said there is no INotifyPropertyChanged and ItemsControl.ItemsSource in DirectUI in 7955.
now they are actually here in 7989 as Windows.UI.DirectUI.Data.INotifyPropertyChanged and Windows.UI.DirectUI.Controls.ItemsControl.ItemsSource.
and there is more bridging code in CLR to support exposing CLR object as PropertyValue etc, so DataBinding may actually work in 7989.

and there is IValueConverter !

 

there is Window/WebView/WebViewBrush in Windows.UI.DirectUI namespace.
and a Window have a CoreWindow property which is a wrapper for HWND.

and, can you test that if this WebView have the 'airspace' problem with other controls ??

 

and Windows.UI.DirectUI.Media.Animation has been flooded by easing stuff. can you revalidate your previous speculation about the animation changes ?

 

oh and Windows.UI.DirectUI.FrameworkElement.DataContext is an 'object' now, not a 'PropertyValue' as in 7955

 

ICollectionView on its own has little to do with UI controls; like IVectorView, it provides a filtered, grouped, and sorted view of a collection. It also provides some additional functionality like tracking the current selection. Anyway, as NativeUser was hinting, ICollectionView has nothing to do with UI virtualization. Since IVectorView is a similar but even lighter-weight interface, it has nothing to do with virtualization either.

UI virtualization, in fact, has nothing to do with the data source; it's a function of the control rendering the data (or, in WPF's case, the items host panel). The data source could support data virtualization, but that's another matter entirely.

 

oh and ItemsControl.Items is an ItemCollection (which implements IObservableVector<object>) now, not just an IObservableVector<IPropertyValue> something in 7955.

suggetions, you can try to modify those xaml files of glcnd and see if the glcnd ui will change as you like.

 

You need to login to view this posts content.

 

ah yes ! 'marketing' name is another story ! I think 'Jupiter' or 'the whole framework exposed by WinRT/WinMD' will be branded as 'Windows Runtime' because its a catchy name. but technically this will be a confusing name. how do you refer to the underlying COM-like WinRT funtions in COMBASE.DLL etc ?

Power to the common sense !

 

you're having internet problems xD

 

oh my. one more clue for these naming stuff.

the 'Jupiter Window' is now called 'WinRT UI Window' in 7989 !! so Jupiter == WinRT UI ?

and, the letters in 'Jupiter' can be reordered to be something like 'JepRT UI', but this is just nonsese.

 

Yep, it works, at least for single values, haven't tried collections (ItemsSource).

 

Speaking of naming: there's a new service called Broker Infrastructure and the description of the service is this:

"Coordinates execution of background work for WinRT applications."

 

System.Runtime.WindowsRuntime contains a bunch of async related extensions. GetAwaiter included. So I guess C#'s await will work with WinRT's IAsyncInfo? Cool!

 

You need to login to view this posts content.

 

In C++ data binding can be implemented by using an InMemoryPropertyStore (there may be other ways too, like implementing ICustomPropertyProvider but I haven't tried). Something like this:

Code:

IPropertyValue *propVal;
hr = factory->CreateDouble(42.3, &propVal);
void *propName;
hr = WinCreateString(L"foo", wcslen(L"foo"), &propName);
bool succees;
hr = store->Insert(propName, propVal, &succees);
hr = page->SetValue(dataContextProp, store);

PS: I got the InMemoryPropertyStore idea from the PDF reader. Speaking of it, the XAML files used by the PDF reader have been mentioned already but I'm not sure people realized what happened between the current leaked build and the previous one: they moved the reader from the old DirectUI (dui70.dll) to the new DirectUI (DirectUI.dll)

 

hahaha, idk bout that

 

You need to login to view this posts content.