I am working on reading up on Silverlight 4 and wanted to know what are the most commonly used functions of Silverlight (so I can put a stronger emphasis on them) as opposed to features that are rarely used.
Here you can find five great features of silverlight 4.0.
Short preview:
Webcam and Microphone
WebBrowser & HTMLBrush
Full Trust in Out of browser
Printing
RichText edit
Related
I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
What are the differences between these two programming choices
I know that the following features are supported by only HTML/Javascript
1. Flyout control
2. Header Menu
3. Rating Control
Do they have any other difference in terms of controls, integrations, connections, deployment?
html/javascript
html5 and js are open web standards. That's why they work (and act) in nearly every browser the same way. That is the reason why you can develop html5 applications for Mac OS and port it without many extra coding to Windows.
Microsoft however wants to have as many Apps inside the market as possible, that's why they made confession to the web developer and implemented a native looking support to html and Javascript. But there are a lot of Javascript functions, that are only supported by IE10 (in fact, nearly every function you can find in the WinJS-File). If you want to port Win 8 Application to any other Operation System, you have to review your code.
A good example for this is the click-eventhandler in WinJS, which has a event.pointerId to identify multitouch. This is a good easy way but not standard.
XAML/C# or VB
XAML is .NET and so it is fixed to this Framework. You cannot easily port a XAML Application to a mac os. Therefor XAML and C# is very good implemented into Visual Studio (Intellisense,Blend and Design-Views) and has some nice features like LINQ and DataBinding. Also the MVVM pattern allows to split up designers and programmers. In my opinion the documentation on msdn is better for XAML and C# than for Html5 and JS. For games there is also a DirectX implementation which is a better choice because of higher performance.
What to choose?
The decision which way to program is really hard. The following Questions should help:
Which programming language are you more familiar with?
IF OOP -> C# and XAML
IF web and prototype based languages -> HTML and JS
Which type of application will you code?
If it's fixed to Win 8 -> XAML and C#
If it should run on more than one platform -> HTML and JS
Do you like Visual Studio?
If yes -> use XAML and C#
If no -> use HTML and JS, you can than
first develop the app with your common IDE and later import it into
visual studio to create the application.
The new Metro style / WinRT apps in Windows 8 have certain restrictions as to which APIs you can call. Also, you have to use asyncronous techniques and your app has to be pauseable, etc.. I'm wondering how, and if all of this is enforced.
Are the new Metro apps simply execuable programs, or are they something else (e.g. more like COM controls, with a set of defined interfaces)? How are the API restrictions enforced, at compilation, at runtime (via sandboxing etc.) or just via Windows Store policy (similar to the situation in iOS)? If I was feeling devious, could I e.g. get a handle to the screen and manipulate the interface, add floating windows on top, launch something in the background, or otherwise break out of the confines of Metro?
One reason I'm asking is that I'm looking into creating a WinRT library for Python, so that one could use it for writing Metro apps. However, the Python core obviously uses a lot of non-WinRT API calls, so this might be doomed from the beginning. I'd also like to get a feel for the anatomy of Metro apps in general.
Edit: According to this thread, you have all the functions of the C runtime available. It seems like you can compile stuff that calls forbidden functions, but the "application verifier" complains. I'm wondering if you could just run such a hybrid app, if you don't care about the Store (and maybe make it Store compatible later by writing workarounds for the forbidden functions)...
There are (at least) two separate sets of technical restrictions on what a Metro style Windows Store app can do.
The first is a set of security restrictions: Windows Store apps run with low privileges, and thus are limited in how they are permitted to interact with the rest of the system. For example, a Windows Store app cannot access arbitrary locations in the filesystem, it can only access files in a predefined set of locations, and files to which the system expressly gives access. You cannot violate these security restrictions (if you could, that would be a rather problematic operating system bug).
The second set of restrictions is the API partitioning. Windows Store apps are only permitted to call system functions that are present in the App Partition. The documentation for each system function on MSDN specifies whether the function is present in the App Partition. You can also find out by looking in the header file that defines the function: functions are conditionally defined depending on the API partition targeted by the project: the WINAPI_FAMILY macro controls this (see winapifamily.h in the Windows SDK for more information).
If you call an "unapproved" function, the results are undefined. It might appear to work; it might fail catastrophically. It might appear to work fine today and fail catastrophically tomorrow (or after a Windows update is applied, or with the next version of Windows).
The API partitioning is enforced in various ways. The headers are constructed such that it is difficult to call an unapproved function. If you define the function yourself or change the WINAPI_FAMILY, your app will fail the Windows App Certification Kit (WACK) process. My understanding is that the CLR prohibits calls to unapproved .NET functionality at runtime, though I am less familiar with the .NET restrictions. In any case, my understanding is that if your app calls an unapproved function, you cannot submit it to the store, per the "Windows 8 app certification requirements" (please read those requirements yourself, though; I have not read them in detail and I certainly can't interpret them for you).
If you don't care about submitting your application to the Windows Store or just want to write some test apps or play with WinRT, then there's nothing stopping you from trying to call unapproved functions. For example, I find it is useful to create a console window for debugging purposes. That appears to work fine, and I don't much care that it fails Windows Store certification since it's for debugging and testing only.
They aren't standard executables. You're restricted to a subset of .Net 4.5 to create the applications which doesn't let you (or rather, makes it extremely difficult to) do anything that MS don't want Metro apps doing. They're pretty heavily sandboxed as well.
You have a limited part of the .net api available:
The .NET Framework provides a subset of managed types that you can use
to create Metro style apps for Windows using C# or Visual Basic. This
subset of managed types is called the .NET for Windows Store apps and
enables .NET Framework developers to create Metro style apps within a
familiar programming framework. Any types that are not related to
developing Metro style apps are not included in the subset.
You use
these managed types with types from the Windows Runtime API to create
Metro style apps. Typically, you won't notice any differences between
using the managed types and the Windows Runtime types except that the
managed types reside in namespaces that start with System, and the
Windows Runtime types reside in namespaces that start with Windows.
Together, the .NET for Windows Store apps and the Windows Runtime
provide the complete set of types and members available for developing
Metro style apps with C# or Visual Basic.
There are app store requirements.
3.1 You must use only the Metro style APIs to implement the features of your Metro style app We describe these APIs in the Metro style apps
API reference. Your app may only depend on software listed in the
Windows Store.
Apps are sandboxed.
In short, you must you the api provided.
We can’t just leave our customers that are not able to upgrade to windows 8 for a long time in the larch. However there is demand for a “tablet”/”touch” version of our app.
So how can we support both touch with Metro on Windows 8 and our current customers from a single code base?
When WPF come out, after a lot of “Pushing” Microsoft saw since and make it work on Windows XP – has anything like this been talked about for WinRT.
(I am not expecting any solution to work on XP, as XP support is being wound down.)
See Also: Can the ARM version of Windows 8 only run Metro (WinRt) style apps?
The best answer is that you do not want the same application to run on Windows 7 and Windows 8 Metro style. The UI that works best for mouse and keyboards (windows 7) will not work well for a touch-first presentation and visa versa. It is important to re-imagine the UI for the two different worlds.
That said, you have 2 options if you want to share a lot of the code:
1) Write it largely in JavaScript/HTML5. This will let you re-use many of the assets (especially the business logic parts).
2) Write it in (desktop) Silverlight. The Silverlight XAML is closest to Windows XAML. WPF is further away and will require more re-work later.
In either case, you should look at and follow the principles used when writing cross-platform code. Understand the platform dependencies and isolate them behind indirection boundaries. You want to localize all of the code that will have to change. For instance, you don't want calls to the .Net System.IO.File APIs which you know will have to change to Windows.System.Storage calls being scattered throughout your code. Instead, you want it localized in one function that can be modified later.
The only way I can think of is to implement your application in HTML5/CSS3/JS, and avoid using WinRT APIs inasmuch as possible - this may be feasible depending on what, exactly, your app needs to do (e.g. portable 2D graphics is easy with HTML5 canvas).
Then, for Win8, you'll package this as Metro web app. For Win7 and below, you write a simple app that embeds your browser of choice (not IE9, since it doesn't work on XP - so Firefox or Chrome) with all chrome hidden, and loads your HTML5 app inside that embedded browser.
As others have noted, you would not want to have exactly the same application working in Win8 Metro and Win7 / Vista Desktop. If you structure your application properly, using a suitabel design pattern, it is possible to share quite a bit of code between the various version that you would require. For the Win8 version, you will be using WinRT, for Win7 / Vista you have a choice of Silverlight or WPF.
I have published a couple of articles that demonsrate how this can be done, they include quite a bit of code as well:
XAMLFinance – A Cross-platform WPF, Silverlight & WP7 Application - while this article does not cover Win8, it does share code from WPF to Windows Phone 7, which is a very similar problem.
TweetSearch – A Cross platform Metro UI WinRT and Silverlight Application - this article shows how to use the same techniques to share code between WinRT and Silverlight
It is unlikely that we'll see Microsoft push the Metro-style
application framework back to past releases due to the level of
re-architecting that went into Windows 8.
I agree with Zac on this point. It appears Microsoft is definitely pushing both the technology and usability forward with the introduction of Windows 8 (and Windows Runtime).
The Metro UI is a different UI paradigm. If your using the current
Win32 controls (which includes WPF controls), your application will
look really dated in Metro. The only way to fix that is to
re-implement the UI (your View classes in an MVVM design) using Metro
controls. However, C# and majority of the .NET APIs are first class
citizens in this new environment. The rest of your application should
be fine.
As you already have what I assume a rather large application your best solution would be separate your view from your model-viewmodel. Then you can continue to develop both Windows 8 Metro full-screen touch-friendly awesome interfaces and the "classic" window interface (what we have done for the last x number of years). With good separation, design, and an excellent source control solution (i.e. Perforce) you will able to share a lot of the code base.
In addition to the answers given to your recent question on Windows Runtime Bill Wagner (one of the many C# bloggers that I follow) has posted summary on WinRT and managed languages conference sessions; it is an good read and recommended if you have a few minutes. One of the things that his summary clarified (in the FAQ at the end) was that the future of .NET as the branding for the framework we use is going to be replaced with Windows Runtime.
Another piece from Bill's blog post:
Some of the .NET APIs are changing for WinRT. I don’t have an
exhaustive list, and I’m not sure there is one yet. Other APIs are not
exposed via WinRT. (They are still available as .net APIs, just not as
Metro / WinRT APIs.)
It is unlikely that we'll see Microsoft push the Metro-style application framework back to past releases due to the level of re-architecting that went into Windows 8.
Like Pavel said, if you kept your application from using as much of the WinRT libraries as possible, it is possible but then again, you're now building a regular web app.
Does anyone know how to display DirectShow video in HTML container (e.h. DIV) instead of separate pop-up-like window.
Already I did all the things needed to run custom Rendering Behavior, it includes all interfaces and events handling, but cannot find anything related with my problem neither in the Internet nor in books I have.
Anyone can give me a hint what I need to do?
P.S.
MSDN articles mention only DirectDraw and Direct3D when setting IFlags on IHTMLPainter - but maybe it's a wrong place I'm looking for :-)
Regards.
In general, this is sort of a messy topic. As far as I know, your options are a custom activex control (yuck...in general, this approach is a logistical nightmare) or leveraging an existing player like Silverlight or Flash.
Silverlight doesn't give you control on a DirectShow level, but it does have additional support through the MediaStreamSource that may meet your needs. And once your audio/video is in Silverlight, you have all sorts of options for advanced overlays and interface elements.
I won't comment on Silverlight, as I have no experience of it, but I wouldn't agree with kidjan's summary of using an ActiveX control.
A custom ActiveX control has served our company well for many uses - including native apps, managed apps, web pages ...
The beauty of using an ActiveX control is that you have total control over the code in your player, stream authentication mechanisms, rendering capabilities etc.
I wrote an entire player in less than a month (network code included), then wrapped it in a COM control in less than a week.
Be under no illusion though, DirectShow and COM programming isn't easy. It's all about trade off - a Flash or Silverlight solution will probably get you going quickly. An ActiveX ctrl will give you total control.
I also read that HTML5 standard will include support for embedding video content(!) Might be worth looking into, although I don't know how many browsers support the (emerging) standard.