I've built a little WPF utility that watches a serialport and visualises monitoring information with WPF. It works fine, but a colleague just tried using it from another machine via radmin and my app is completely invisible! if you're at the machine you see it, if you view it via radmin you see the same screen but no app. Instead you see the app behind it (in this case windows explorer), but can't click on anything in the space where my app is.
Has anyone else come across this before??
It sounds like you need to upgrade to .NET 3.5 SP1.
On .Net Framework 3.5 SP1
We now remote as bitmaps in ALL cases.
The reason is that WPF 3.5 SP1 now
uses a new graphics DLL (wpfgfx.dll)
and certain changes could not be made
to Vista’s existing graphics DLL
(milcore.dll) that is also used by
DWM. Although this could be seen a
regression at first, depending on the
complexity of the application scene
(e.g. very rich scenes) this can
actually improve performance in
certain scenarios . Also, connections
with reasonably high bandwidth and
scenarios that don’t involve a lot of
animation or 3D, for instance, tend to
remote just fine via bitmaps.
Source
Checked the framework and it was already 3.5 SP1.
It's ok via RDP, so my colleague is happy. It just seems to be radmin, which I'd never used before and don't see the need for.
Related
I have requirement that we need to develop a rich UI application(similar to WPF or silverlight). The target device is having embedded OS Win CE 7. how can i achieve this, after so much R&D i got to know that
1. we have to user Silverlight for GUI and C++ as backend coding
2. we can create the MFC application using some third party SDK we will not be able to get rich UI
Also, i read that we can add components in WIN CE 7 for compact framework.
Is my above understanding correct, can someone throw some light on this?
Just to add my 2 cents to Chris and Paolo's replies, if you are not building the OS image for the target device or, at least, can't control the features it supports, your choice may be limited by the set of components that were included into the OS image provided with the device.
Windows CE is highly componentized and both the badly named "Silverlight for Windows Embedded" (XAML) and .NET Compact Framewor runtimes can be left out of the OS image to save storage space and memory.
The XAML runtime can leverage graphic acceleration (if the HW you are using provides it and the BSP includes drivers to use it, of course) and this may lead to a more responsive system, compared to a full .NET implementation.
I would also try to stay away from MFC for new implementation. The only good reason to use MFC is that you already have an UI framework that fit your needs and is based on it.
Currently on CE you can decide between an easy to design and rich UI with complex to develop and debug code-behind (XAML) or an easy to develop .NET application with an ugly windows 95-like UI that require lot of work to be "beautified". XAML in the hand may merge the best of both worlds (requiring additional cost and two heavvy runtimes on your target, but this may not be an issue if you have a powerful x86 machine or a graphic accelerated ARM Cortex).
To develop application on WEC 7 you need an SDK built from OEM that give you the target board.
If you want to develop on a Virtual PC image you need Platform Builder to use CEPC BSP and create an O.S. image and the corresponding SDK.
After that, you can develop using Silverlight only with C++ but you can use .Net Compact Framework and managed code for Windows Forms development.
Paolo.
It really, really depends on both your definition of "rich" and the graphics capability of the hardware you're targeting.
CE 7 supports the .NET Compact Framework. Many people will say that you can't do "rich" UI in the CF, but that's not really true. You can't do it with the standard controls, but if you do your own custom control drawing, you can do pretty well. Yet, it's a lot of work, but it can be done. The limitations here are in alphablending (not fun to get working) and animation (also not fun), but with dedication you can work around many issues.
CE 7.0 also supports "Silverlight for Windows Embedded" (a.k.a. SWE). First thing to know there is that it's really not Silverlight. It's a XAML rendering engine, but any other Silverlight assets you might have won't work with it.
SWE supports only C++, though since it is COM based, it can be wrapped in CF classes and then used from managed code. I've seen a couple of companies do this, and one even offers it as a product.
MFC is available, but since MFC was crap even 10 years ago, I definitely wouldn't use it today. If you want to use C++ but not SWE, there are better options than MFC. STL and WTL come to mind for windowing apps.
I want to create a WPF program with some nice effects (especially enterance and exit effects) for some text inside application.
I know transitionals library, but it doesn't have professional effects! (and some professional ones in that library are slow and laggy...)
Actually, I want some effects like effects in Microsoft Powerpoint 2010...
Is there any library or something to have such effects?
Yes - there are several pixel shader style effects libraries. WPFFx is probably the most widely known one at http://wpffx.codeplex.com/.
Note: the site says "This requires .NET framework 3.5 SP1 and requires Direct X SDK at compile time.. (to build the PS files)." You will need to verify it works if you are running a later version of .NET.
I want to start silverlight development inside an application which developed by WPF.
Actually we want to add silverlight featuretoan existing WPF project. what should we consider and how todo this
I saw Getting started with Silverlight development and it was not my answer
I mark this as a Community Wiki.
Please clarify your intent. What do you mean by a Silverlight feature ?
Silverlight is a subset of WPF, but is intended for a Web application (i.e. running inside a Web browser, using the .NET framework provided by the browser plug-in), while WPF is meant for a desktop application (i.e. running outside of a browser, using the full .NET present on the disk).
(there is the notion of running WPF inside the browser, but that is still using the full .NET framework).
"Adding" Silverlight to WPF doesn't make much sense because you can accomplish whatever you need to do in regular WPF for the most part. If you already have a WPF application you are enforcing windows and the full .NET client run time so you are going to get any deployment benefits.
I assume what you may be considering (since you mentioned XBAP) is to re-write or recompile your current WPF XBAP application into a Silverlight application? This way you get cross platform web deployment with the full Client run time requirement.
If this is the case then you would not be "adding" to your existing solution. It would be more an exercise in porting the existing application over to Silverlight. With SL3 this is less painful then before (and if SL 4 is an option it will be an even better experience).
My first step would be to simply create a new Silverlight application and begin moving your code over and seeing how far you get.
I have to make an application that runs on both Windows (XP/Vista) and Windows Mobile. The graphics interface must be scalable (for different resolutions) and the controls must be custom (like the ones usually found on music apps).
SVG was my instant choice but the lack of support on Windows Mobile pretty much kill my time budget. I've tried to evaluate WMF and it seems the right answer but i don't really like it.
I was thinking about WPF/XAML but i don't know what are the differences between Windows and Windows Mobile.
The project must be in C# or C++ and it's a commercial project (thus no GPLed libraries).
What would be the best choice? What ma I overlooking?
WinForms has limited support for scaling:
http://sellsbrothers.com/writing/winformsAutoScaling.htm
You may also want to look at "anchor" and "docking":
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6165908.html
Combined together you should be able to create a UI that works for both desktop and mobile.
You can do scaling UI in .NET compact framework, like Erwin said with docking and achoring. In the windows mobile applications i have written i do normaly have to write some custom code that deals with things like Font scaling ( Touch founds might need bigger Font then system default if the text should be clickable).
I dont think your going to get it to scale picture correctly without code, i found some question releated that on this site. In my experience i write 99.9% of my code so it runs fine on both windows and windows mobile, but i do make a different UI for windows mobile.
If normaly write code in .NET 2.0 / .NET 2.0 Compact Framework, but if your you dont care about having to install .NET 3 then it should be better ( .NET 2 is wider spread out then .NET 3 )
Another option is the Qt library which is written in C++. It is LGPL which means that it can be used in commercial products without having to release your sources (except for changes to the library itself). If for some reason that isn't good enough they also sell commercial licenses.
It runs on Windows and Windows Mobile. As a bonus if you do a reasonable job of programming (and assuming everything else you're doing coding wise supports it) your application can also be run on Mac OSX, Linux and S60.
It has support for Scalable Vector Graphics, a Canvas with full widget support and a bunch of other nifty features as well! I'd suggest checking out the documentation and seeing if it has everything you need.
Silverlight?
I have heard that WPF primitives will not be supported by remote desktop on windows XP. The implication of this is that if you run a WPF application on a vista machine and display it on an XP machine (via remote desktop) the display will be sent as a compressed bitmap.
This issue is resolved in Vista-Vista comunication via DirectX 11 (?) but this will not be made available on XP. There is obviously a performance hit here, I would like to understand it before making any inroads into developing applications to WPF.
Some information on this topic can be found here:
http://blogs.msdn.com/tims/archive/2007/01/05/comparing-wpf-on-windows-vista-v-windows-xp.aspx
See comment from the above link (quote):
To SpongeJim's question, this is done by the MIL (media integration layer), which is the underlying core of WPF that handles composition. On a Vista/Vista remote desktop connection, the MIL primitives are remoted and then reconstituted. On other combinations (e.g. 2003/XP), what gets remoted is bitmaps, which is obviously far more bandwidth-intensive. More depth on this topic can be found on Greg Schechter's blog, and in this entry in particular: http://blogs.msdn.com/greg_schechter/archive/2006/06/09/623566.aspx
Does anyone have any experience or more up to date information on this issue?
As of .NET 3.5 SP1, all WPF graphics are remoted as bitmaps, even on Vista-to-Vista communication. From http://blogs.msdn.com/jgoldb/archive/2008/05/15/what-s-new-for-performance-in-wpf-in-net-3-5-sp1.aspx:
We now remote as bitmaps in ALL cases.
The reason is that WPF 3.5 SP1 now
uses a new graphics DLL (wpfgfx.dll)
and certain changes could not be made
to Vista’s existing graphics DLL
(milcore.dll) that is also used by
DWM.
As other commenters have noted, the performance will greatly depend on the design of your application’s UI. The potential upshot is that you only have to test in one scenario; remoting performance should now be the same regardless of the client or server.
We have had no problems using both Remote Admin and Bomgar for remoting once those apps were updated to work with WPF. We've tested XP to XP, XP to Vista, Vista to XP, and Vista to Vista. We'd initially only had problems with tooltips and combo-box drop downs/popups. For the last six months or so, things have been fine.
I just tested remoting into a Vista VM from my XP desktop and our app looked great (if running a bit slow, but it is a VM...) I switched to low quality 8-bit color and the performance problems almost completely went away. The gradiation, etc, was lost on our window background, etc, but it was definitely still usable.
I don't think you should have any functional problems, and only minor performance issues.
i guess this depends on your wpf app.
if you have lots of gradients, animations, brushes, etc...your app will definitely run slower over the wire...