locked
WinRT C#/XAML limitations

All replies

  • I'm marking this as a discussion since it is a catalogue of features rather than a specific question. 
    Friday, November 18, 2011 3:07 AM
  • - No database support (OLEDB, SQL Server, SQLite)

    - No data exchange / sync possibility with desktop application

    Sunday, November 20, 2011 7:15 PM
  • Monday, November 21, 2011 12:59 AM
  • No traditional Web service support(Add web reference). only Wcf services are supported.

    http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/59fa422b-5604-48d9-a63f-04b404d5cc3a

     

    --Akhilesh Bhale

    Monday, November 21, 2011 4:44 AM
  • @Patrick nicely done! I don’t have more to add, your list is depressing enough J

    I appreciate that WinRT is still in developer preview phase and it will change by the time windows 8 beta is released. But the suspense and secrecy is killing me! First we were worrying if XAML will be present in Win8, now that it is there, it's almost unusable (at least for my app.)

    No database support, No FlowDocument(biggie for me), No Triggers in XAML and so forth. If Windows 8 immersive apps are supposed to shine on Tablet like form factors, then they are predominantly consumption apps. Hence warrant support for rich text, graphics and animations.

    I hope someone from MSFT is listening, we need some transparency guys.


    Sameer V.
    • Edited by Sameer.V Monday, November 21, 2011 10:13 AM
    Monday, November 21, 2011 10:13 AM
  • Missing features that disturb me currently is the ability to talk to SerialPort IO, MIDI.  I can't access the Speech API's so I guess I won't be creating SIRI on my tablet anytime soon.  I can't enumerate a list of installed fonts.
    Thursday, November 24, 2011 2:37 AM
  • All these missing pieces are worrying. Enough suspense! MS, please tell us how we will develop "real" metro applications.
    Cameron Peters
    Thursday, November 24, 2011 2:17 PM
  • At this writing there is only 344 views to this thread. It shows how few are interested in programming for Metro because MS has purposely crippled these tools.

    Why are they making it harder than it should be?

    Friday, November 25, 2011 10:39 PM
  • I'm not sure how you are correlating # views to lack of interest.  There is a lot of interest in Metro apps.  Yes, there are differences in the profile of .NET and some areas of XAML.  Some of these continue to be investigated to converge and others may not happen.  There is still plenty of 'meat' in the profile and frameworks to create compelling applications.
    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)
    Tuesday, November 29, 2011 4:21 AM
  • Tim,

    Thanks for participating in this thread.

    Of course there is lots of interest in developing metro apps.  Unfortunately, it looks like my company will be on the sidelines unless some kind of Drawing API with some version of advanced text formatting is provided. We can't deliver our product without this support.

    Hopefully some of this will show up in the Windows 8 Beta. Can you share some details?

    Best,


    Cameron Peters
    Tuesday, November 29, 2011 4:26 AM
  • @Cameron- completely agree with you, my vote is for advanced text formatting. I believe FlowDocument is one of the strongest feature of WPF and should be included in WinRT. If we want to create iPAD like experiences on WinRT, it need to have best support of graphics and Text out of the box. I hope the beta does this.

     

    Thanks

     


    Sameer V.
    • Edited by Sameer.V Tuesday, November 29, 2011 12:31 PM
    Tuesday, November 29, 2011 12:30 PM
  • @Cameron - what type of Drawing API are you looking for?  something like DirectX?

    @Sameer - would something like linked rich text containers to enable multi-column layouts be sufficient in the absence of the WPF FlowDocument?


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)
    Tuesday, November 29, 2011 6:34 PM
  • Hi Tim,

    Thanks for your reply.

    My answer is no. I'm putting finishing touches to an WPF application, to read/store/share HTML pages and eBooks. I found FlowDocuments to be great for this purpose. It's ability to host standard WPF controls(via BlockUIContainer) to play videos etc. and annotations framework makes FlowDocument almost irreplacable.

    I prefer how FlowDocument renders text, it is so much better than reading a HTML in browser. WPF Text effects etc. just makes reading an delightful experience.

    I briefly looked at WinRT, to see how easy or difficult it would be to port my app, I found RichTextFlow control to be largely inadequate for following reasons...

    1. No provision to load XAML dynamically(constructed by parsing HTML)
    2. No equivalent to Annotations. As WinRT XAML is small subset of WPF, it is really hard to implement an equivalent.
    3. Lack of Sections, Floaters and BlockUIContainer.
    4. Equivalent of FlowDocumentPageReader and FlowDocumentScrollViewer. PageReader is great for performance when loading large documents.

    I have been using iPAD for last year or so and really enjoyed apps like Flipboard and want to create similar experiences on Windows. WinRT is absolutely great on so many counts, but the limited api and lack of support for FlowDocument is a huge step backwards. I think!

    Tim, please take this message to Steven and team. :-)

    Thanks,


    Sameer V.
    Tuesday, November 29, 2011 9:22 PM
  • Tim,

    I agree with @Sameer!

    I don't need a particularly comprehensive drawing API.  What I need is the Advanced Text Formatting API from here: http://msdn.microsoft.com/en-us/library/ms754036.aspx, as well as the DrawingContext from here: http://msdn.microsoft.com/en-us/library/system.windows.media.drawingcontext.aspx

    In addition to the text, I need some way to draw lines and basic shapes. Our app reproduces government forms, and without precise positioning, would not be acceptable to them.

    We also need something like the ReachFramework so that we can send our output to the printer, or preferably, PDF.

    Thanks!


    Cameron Peters
    Wednesday, November 30, 2011 2:47 AM
  • Tim,

    Just out of curiosity, if some one needed to implement an application that renders PDF documents, how would you do it in WinRT?

    Best regards,


    Cameron Peters
    Wednesday, November 30, 2011 2:49 AM
  • Are there any plans to support those features?

    Sunday, December 04, 2011 9:07 PM
  • @Tim Hi, please, what rendering/eventing engine is behind WinRT/XAML implementation wrapped by such enhanced COM? I hoped there is Silverlight agcore or better whole "Silverlight Embedded" codebase behind such new multi-client interface. Isnt this true? It is planned finally? It seems now there is some incomplete mock written almost from scratch (something IE rendering engine based?) mapped to xaml but lacking many of crucial by-design WPF/SL internals? If so, it really looks quite strange. I already understood that vast of fools worldwide hated Silverlight buzzword without even little knowledge what it really is inside. But hope such marketing and PR driven fools arent also in your teams, as MS was till now for me almost last company which is driven by really technical needs and no by Gauss-curve controlled market. I dont want to start flames, simply some more details whats inside from you here, to be able to extrapolate progress at least will be usefull. (sorry, may be I can BING-out something, but not staarted yet today, just crossed this page and be quite lot curious about lack of interrest from both sides ...)

    thanks in advance,

    Petr


    Petr Antoš
    Saturday, December 10, 2011 5:21 AM
  • I have a requirement to do this to. Going to have to try and find some way of doing it!
    Monday, December 19, 2011 10:54 AM
  • You can't enumerate a list of installed fonts in Metro style apps? You've got to be kidding me.
    Tuesday, December 20, 2011 2:07 AM
  • @Petr - The rendering is more than Silverlight -- different model.  We don't have to rely on x-plat so we can rely on Windows subsystems.
    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)
    Wednesday, December 21, 2011 2:19 AM
  • No TreeView control. Why is this missing?

    Thursday, December 22, 2011 12:48 PM
  • Tim,

    I have been playing with the consumer preview and enjoying it. I have now started to work on my app and I'm kinda coming round to your original assertion that RichTextBlock with multi-column layout can be a good starting point.

    I'm stuck on one issue and will be grateful for any guidance. I want to be able to dynamically load XAML string(representing bunch of blocks) into RichTextBlock. I can use XamlReader but it requires XAML string to have one root-level element. So I can do one of the followings.

    1. Wrap the dynamic XAML string within <RichTextBlock> tag so that whole RichTextBlock is de-serialized, now I can insert it into the visual tree. Problem with this are, a. It just feels wrong :-) b. I will not get any events etc. on this RichTextBlock.
    2. I can de-serialized the RichTextBlock, now iterate through all the child blocks, remove it from the parent and add it to my Document viewer control.

    Both of these seem wrong. I'm wondering if there is api or trick, so I can load my dynamic XAML right into RichTextBlock?

    thanks,

    Sameer


    Sameer V.

    Tuesday, March 06, 2012 3:39 PM
  • +1 on Advanced Text Formatting and FormattedText.

    http://msdn.microsoft.com/en-us/library/ms752098.aspx

    Also, I vote for ItemContainerGenerator.StatusChanged

    http://msdn.microsoft.com/en-us/library/system.windows.controls.itemcontainergenerator.statuschanged.aspx

    Tuesday, March 06, 2012 11:29 PM
  • @Sameer - you should look at the default VS templates...they currently include a Multi column control built on these concepts.

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Wednesday, March 07, 2012 12:22 AM
  • Patrick,

    You are also missing under the Xaml heading, no support for multi-binding.   This is an absolutely key feature for projects of almost any size, and not being able to use it wastes a lot of time in workarounds.

    Stefan

    Thursday, March 08, 2012 9:41 PM
  • Where is UIElement.Effect???

    Are you saying that we wont be able to use any kind of pixel shaders in a non-DirectX Application???

    That is a step backwards...

    Also, the start screen could use some shadows and whatnot... It looks monotone right now. Big ugly-colored squares with big white icons inside = fail. Only two of my tiles display information (Mail and weather).

    Friday, March 16, 2012 4:37 AM
  • Metro bring us 20 Years back.

    Single running Apps with poor Interfaces.


    • Edited by blau34 Sunday, April 15, 2012 2:37 PM
    Sunday, April 15, 2012 2:37 PM
  • There seems to be confusion over the type and scale of applications that should be possible with Metro. Or maybe it is just me that is confused.

    There is no Start button with Windows 8 which means you have to use the new Start screen. As they make it impossible to get around seeing and interacting with the new Start screen this implies that Microsoft want you to be building everything as a Metro style application. This would be fine if it were possible to build every type of application with Metro. But at the moment that is just not the case, not even close.

    What if I am building a typical line of business application? Metro does not support use of multiple monitors. There is no OnRender/Drawing API so you can get decent performance from writing custom controls. It does not have Date and Time picker controls. You can have a fancy dandy flip control but you cannot enter a date! Seriously? This is like WPF all over again, where you need to buy a user interface library from a component vendor like Infragistics before you can write a real world application.

    At the moment Metro looks like a nice way to build small and simple apps or games for Windows tablets. This is perfectly fine but in that case stop making me switch to the Start sceeen, a jarring experience, just so I can launch Word 2010 or manipulate a photo with Photoshop. When I can build real line of business application with WinRT then you can force me into using the Start screen.

    Monday, April 16, 2012 2:30 AM
  • Consumer preview does have D2D/D3D interop support. On other hand features got cut from DP to CP. For example no more Hyperlinks in RichTextBlocks. I have to say that rich text support in metro xaml is the weakest of any modern platform.
    Monday, April 16, 2012 8:02 PM
  • @MightyDuck - RTB supports hyperlinks:

    <RichTextBlock>
                <Paragraph>
                    <Run>
                        This is a 
                    </Run>
                    <Span>
                        <InlineUIContainer><HyperlinkButton Content="test"></HyperlinkButton></InlineUIContainer>
                    </Span>
                </Paragraph>
            </RichTextBlock>


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Tuesday, April 17, 2012 12:35 AM
  • Tim,

    That is not a usable implementation of hyperlink.  That is not going to wrap with the text, so if you have a long hyperlink is going to look totally stupid, or not even work at all because potentially the hyperlink could stretch the across more than one line, in which case will be cut off. This going to make many uses of a hyperlink within the rich text box look extremely unprofessional.

    It once again highlights the concern that I have with WinRT that it is not really compatible with anything. It's got bits of WPF, bits of Silverlight, bits of .net, but not enough of any of it to be compatible with existing code bases.

    I'm trying to sell clients on building stuff for WinRT, but when there are basic things like that is that are not implemented, is very difficult.  I have a client where this would be absolutely crucial, and I'm going to have to tell him that it is not possible with WinRT to do what he wants.

    Stefan

    Tuesday, April 17, 2012 2:08 AM
  • @StefanOlson - the claim was that links couldn't be in RichTextBlock -- I was merely noting that, in fact, they can.  You note that you have a specific use case where they need to look good, wrap, etc.  My quick-and-dirty sample when rendered, yes doesn't look ideal.  However you can style the XAML however you want to control the specific look you want.  Perhaps if you had a pointer to what you are trying to achieve I can help be more specific.  But I was merely pointing out that MightyDuck indicated it wasn't in the consumer preview, but it is.


    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Tuesday, April 17, 2012 3:34 AM
  • Didn't realize that I could be misunderstood, but I digress. I was talking about Hyperlink class and not hyperlinks as a concept. Hyperlink class was present in developer preview and got nixed in consumer preview.
    Tuesday, April 17, 2012 4:25 AM
  • And that's an understatement. Just saying!

    But more seriously speaking, documents support on all .net technologies has always been poor, except for shining example of WPF. And MSFT quickly fixed that(by abandoning it) so we can have consistently bad experience across the board.

    Sorry for being sarcastic and I do feel sorry for guys working (hard) on Win8, but it is very frustrating to see constant changes in .net space and not all of them are for good.


    Sameer V.


    • Edited by Sameer.V Tuesday, April 17, 2012 8:47 AM
    Tuesday, April 17, 2012 8:40 AM
  • Don't you know that Microsoft's plan is to use component vendors. Sometimes I wonder how many of the employees at these vendors were previous Microsoft employees. To me it seems like a good tactic for the employees to make money.

    1. Create a framework but leave it incomplete.
    2. Stop developing on the framework.
    3. Start your own company or go and work for another company creating controls and adding to the framework.
    4. Abandon the framework.
    5. Start at step 1 again.

    Obviously I am complaining and not providing anything useful to this conversation but that is how I feel. At this point of time I have realized why make web pages that act like an app when I can develop real apps for Apple products.

    Friday, April 27, 2012 5:38 PM
  • @Tim:  Would you happen to know where to find a good source of documentation on the WebView?  I'm trying to use it but finding I keep running into roadblocks (compared to the traditional WebBrowser controls).  I have created some extension methods to get/set info in the DOM easier but I'm having issues with other features (for instance, some JavaScript doesn't seem to execute whether it's coming from the host page or Invoked, like "alert" which does work with IE10 Metro). 

    Tuesday, May 01, 2012 12:42 AM
  • @bpell - I'd suggest starting a new thread on that in the forums to get appropriate eyes on your specific issue.  In short, the WebView within a Metro app does have some constraints (alert is one of them).

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Tuesday, May 01, 2012 9:00 PM
  • @bpell - I'd suggest starting a new thread on that in the forums to get appropriate eyes on your specific issue.  In short, the WebView within a Metro app does have some constraints (alert is one of them).

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)


    Thanks Tim, much appreciated.  ;)
    Wednesday, May 02, 2012 1:54 AM
  • What I want:

    A fast, easy-to-use immediate mode drawing API for doing real-time charting (e.g., medical waveforms or an oscilloscope), in straight up C#.  And let us compose retained mode XAML controls on top of that drawing surface.

    It's absurd that you can use Canvas in Metro JavaScript but there's nothing for C#.  Direct2D interop is messy, and I'd prefer not to have to use C++ because the whole rest of the app will be C#.


    Tuesday, June 12, 2012 9:01 PM
  • Hi all,

    We're locking this thread since it is out of date and causing some confusion. If you have questions or comments on Release Preview features that aren't already discussed in other threads please open new ones for them.

    Thanks,
       Rob

    Thursday, June 14, 2012 2:38 AM