After toying a little with the new Silverlight 4 camera features, and being really disappointed that these were not included in WPF, I looked at the Silverlight assemblies and found that they more or less delegate all work to agcore.dll.
Do you think it is a good idea to package agcore.dll with my WPF application, and copy/paste or rewrite all classes concerning cameras to WPF, to get these nice features there?
That particular approach isn't likely to work, unfortunately. There's a lot more to getting C# code to work with Silverlight than just referencing the appropriate DLL. Silverlight is actually a completely different implementation of the CLR, so you can't just call into agcore.dll from a WPF app and have it run.
If you need Silverlight features in your app, I can think of two ways to get them: (1) you could conceivably host a completely separate instance of Silverlight inside a browser control in your WPF app, though communication with that Silverlight instance becomes complicated (though not impossible); or (2) you could write your entire app in Silverlight OOB (Out-of-browser)/trusted mode.
You can try VideoCaptureElement in my WPF MediaKit. It will show a webcam in WPF. It does have a different API than the Silverlight webcam API, but it should have just as many features.
Related
I will be developing an interactive application, involving multitouch, several layers of large bitmaps, and video playback. The screen resolution will be fairly large (1920x1280).
For several years, I have developed interactives in Flash, iOS, and OS X Cocoa. However, this project must run on a Windows box, so iOS & Cocoa are impossible. Also, I'm concerned about performance in Flash, since there may be 3 videos playing simultaneously, and large bitmaps moving around.
I know little about the technologies available on Windows. I'm investigating Silverlight, C#, Unity, Processing, and Java. If anyone can offer advice, it will be greatly appreciated.
You seem to be investigating several technologies on different levels:
C# and Java are programming languages. What you prefer may depend on your existing skills, but C# is from Microsoft so chances are that you will experience less friction using this language if you develop for Windows. Picking the right programming language is an important decision.
Silverlight is a "technology stack" from Microsoft. It enables you to develop XAML based applications that run in the browser. Compared to the native WPF stack it is less powerful. Choosing Silverlight, WPF or another technology stack like Processing.js is an important decision.
Unity is a dependency injection container from Microsoft. You can use this or any other suitable container if you like. Or none at all. You don't really have to think about this until you have made some of the more important decisions about your project.
Personally, I don't have experience with the type of application you describe, but I would go with C# and WPF. WPF has some support for multitouch on Windows, and only if it isn't adequate for your requirements you need to to go native and develop in say C++ which tends to require more work.
Multitouch in Windows 8 has been redesigned but unless you want to develop for a yet to be release operating system this is not an option.
Use Visual C++ if you like to create a LAN based Application, C++ is known for it's power and you could have many resources that could help you in developing this application. If you're going to create this application for web Use ASP.net(C#) C# is known for its flexibility and class libraries dedicated for web and client appilcation i also advice the use of WPF and Silverlight applications.
I suggest you have a look at Windows 8 and Metro Apps. Here is a link to start with this: The Microsoft BUILD conference, Windows 8, and the new UX Challenge. C# (.NET languages in fact), HTML5 and XAML are clearly the direction. Native C++ is back in town with WinRT. Silverlight is now in the gray area :-)
Even if you don't use Windows 8, it will give you a good overview of multitouch future in the Windows space.
I am used to WPF Development. But recently, i am assigned to Windows Forms projects. Fortunately, application framework supports pluggable architecture and that's why i feel i can develop plugin in WPF.
If we safely assume that framework doesn't need more than a interface to detect a plugin, I have following questions:
First of all, is it a good idea to develop WPF plugin for the given scenario?
Are there any guidelines available which i should follow? Any Examples?
Will it be a good idea to design some abstraction layer specially for WPF plugins rather than depending on interface?
Thanks in advance.
Yeah, we have huge project called "Plugins" which is basically WPF App/Windows loaded via additional app domain.
I think in your case depends if you Windows Forms are in .NET 2 or .NET3.5. If it is .NET 3.5 then you dont need additional app domain to load .NET 3.5 with WPF.
If you are already in .NET 3.5 with your WinForms, then you can use ElementHost to host your WPF inside WinForms.
Apart from few glitches (like not repainting the form sometimes), it went quite smoothly in our case
As to your Qs:
Usually it is better to do everything in WPF, but do u have a choice ? (I dont think so)
Lookup an example on WPF ElementHost
Well, I would use MVVM with WPF so that later on you can chnage the UI bit (maybe Silverlight or Win8 metro) without chnaging much of the business layer logic
I want to write a desktop gadget that will group icons on my desktop (using c# & WPF).
It will be a docked window that I can drag icons to it and they will stay their. Also there can be couple of this windows.
Where do I begin?
**I saw all the post here about it but I got lost. Please direct me to examples and explanation pages.
To expand on cevik's answer:
You cannot create WPF applications as gadgets BUT you have two options (which aren't as bad as you'd expect).
The reason is that widgets are composed mainly of web pages (HTML) and not executable (*.exe).
The problem of course is that WPF will only work with & produce executables.
First option - Windows API:
When I said you can't what I really meant is you can't use the Windows Vista/7 gadget platform to make your widgets.
However, you can always achieve a similar effect by using the Windows API.
The Windows API will let you do stuff to windows such as making them always on the background of other programs, which sounds to me like ~80% there (The rest would be stuff like making sure your window doesn't get re-sized or minimized, etc.).
Just as a note, the function you'd be looking for to make the window behind all other windows would be SetWindowPos (specifically the second parameter).
However make sure there isn't a library which already implements these stuff because it can be rather difficult (and consist of A LOT of surprises).
Second option - Silverlight
silverlight can be perceived as WPF for the web.
That obviously solves our problem.
However there is a cost to it, as expected.
Silverlight doesn't have all the features WPF has (possibly not all of the .NET framework as-well, not sure about that as I'm not really using it).
However it should be more than enough to get you by so you should definitely check it out.
Once you have your Silverlight application (and webpage) you'll have to create a manifest & install the gadget to your desktop. See here how to do so.
Maybe this will help you.
Template to easily get started on developing a Sideber Gadget using Silverlight 3.0 or 4.0 controls in C#.
Windows API
So i know that the WinForms touches on the Windows API a little, but frankly its horrible. ESPECIALLY with the layered windows and flickering. So i was wondering if anyone has wrote partial, or full wrappers for the Windows API.Im particularly interested in the Layered Window aspect, but really any part of the API is a good place to start.
Update: I found the Windows API Code Pack here: http://code.msdn.microsoft.com/WindowsAPICodePack but it seems that it doesnt wrap Layered Windows? Am i correct in assuming this?
Native API (Windows)
Ive heard a little bit about the Native API, but im not quite sure what it is for? what features does it provide? would it be a good idea to look into?
Summary (Questions in a nutshell)
Does anyone know of an existing (partial or full) wrapper of the Windows API?
If the answer is no to question one, where would be a good resource to learn about it myself, and potentially write my own?
An explanation of the Native API? What does it do? Can I use it to make applications better? Can I even USE it at all?
An answer to any of those is highly appreciated :) thanks
You could start at PInvoke.NET.
The LayeredWindows actually work better in WinForms than windows.
The native windows controls don't even have the alpha channel support of the WinForms analogues, so native windows flicker, and require massive amounts of subclassing to override the painting to use alpha compatible routines.
You would be better off going to WPF. The windows team has not treated the native control's well at all, going so far as to remove support for a style (WS_EX_COMPOSITED) if aero glass is enabled which, given the way that windows controls paint, effectivly made it impossible for any application to paint flicker free if it uses child window's as controls.
WPF "draws" windows controls, but does not use discrete (native) child windows to represent individual controls. This gives it control over when and how its window surface is rendered.
The Windows API is huge. There is a ton of stuff in it. Windows Forms is a wrapper of parts of it. WPF is a wrapper of parts of it. Parts of the Base Class Libraries (eg System.IO.*) are wrappers of parts of it. The Code Pack is a wrapper specifically of things that were new in Vista and Windows 7 and not in Windows Forms or WPF.
Have you looked into WPF? Combined with P/Invoke of specific API functions, it might take you a long way towards where you want to be.
I have a project that i started as a WinForms application as that was the format i was confortable with at the time. I have since started dabbling in WPF an introduced some WPF UserControls (mainly grids) into my project and absolutely love them.
The question i have is, is there any real advantage to me changing the UI Project of my solution into a purely WPF project, and get rid of any WinForms?
I am fully aware that each format suits a certain environment, and you wouldnt be able to give a definitive answer without knowing more of the details, but i would like to know peoples opinions, and if anyone has done a silimar thing of converting an existing WinForms App into a WPF frontend, and any observations they made in doing so.
Thanks
Underlying the new features in WPF is a powerful new infrastructure based on DirectX, the hardware-accelerated graphics API that’s commonly used in cutting-edge computer games. This means that you can use rich graphical effects without incurring the performance overhead that you’d suffer with Windows Forms. In fact, you even get advanced features such as support for video files and 3-D content. Using these features (and a good design tool), it’s possible to create eye-popping user interfaces and visual effects that would have been all but impossible with Windows Forms.
WPF enhances features that appeal directly to business developers, including a vastly improved data binding model, a new set of classes for printing content and managing print queues, and a document feature for displaying large amounts of formatted text.
But if you’ve done a substantial amount of work creating a Windows Forms application, you don’t need to migrate it wholesale to WPF to get access to new features such as animation. Instead, you can add WPF content to your existing Windows Forms application, or you can create a WPF application that incorporates your legacy Windows Forms content.
Reference: Pro WPF in C# 2008: Windows Presentation Foundation with .NET 3.5, Second Edition