I wonder how to achieve effect of swiming tiles (like in windows phone 7, when you start arrange start menu tiles - other ones swim softly and randomly).
Someone have any ideas?
Check out the HubTile implementation in the Windows Phone toolkit, full open source is up at http://silverlight.codeplex.com/ - it has a hub tile service that manages such communication.
Related
Forgive me if this is a technical issue rather than a software-programming one, but I am having difficulty determining the probable cause here, be it the .NET Framework or something lower level, perhaps graphics hardware. Essentially, no WPF application will run on a second monitor using my Windows 10 Alienware 13 laptop. The same application, on the same monitor, running under my Windows 8 Alienware 15, will work fine. Visual Studio 2015 is a similar case, if there might be a common factor. Any experience with this sort of issue would be appreciated
For me, the issue seems to be in the hardware acceleration in WPF applications, as disabling it made it impossible to reproduce the problem (which previously I had no trouble doing using winkey+arrows to move WPF from primary to secondary screen)
The following registry edit can be used to disable hardware acceleration inside WPF applications:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics]
"DisableHWAcceleration"=dword:00000001
Sources:
https://support.microsoft.com/en-us/kb/963021
https://msdn.microsoft.com/en-us/library/aa970912.aspx
I faced the same problem with my Windows 10 and dual monitor ( laptop screen + second monitor connected by HDMI ).
The solution in my case to fix the "black window in the second monitor" was this:
Locate your graphic-card vendor configuration interface by right clicking your desktop. In this pop-up menu you will find something like "Intel graphics" or "nVidia configuration", "AMD Control center", etc...
Find the "scaling options" and change the value. I disabled the "scaling" (OFF) and the problem was fixed, so this issue is related with the auto-scaling of the windows when you move your application between screens.
Please find these screenshots as example from my computer:
Source: https://answers.microsoft.com/en-us/windows/forum/windows_10-start/dual-monitor-different-resolutions-black-program/58ec488a-b62d-4ce8-a058-5e01e2a54d9a
Disabling hardware acceleration for the application, worked for me. This can be executed at any point and works immediately. So you can call this when the wpf app is already running
RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;
Microsoft manual
I have an application written using .Net 4.5 and WPF and mainly for use in Windows 10. In this application, I have created a custom window for capturing images and videos, using leadtools (directshow) to control the camera. Everything looks great with my camera on most devices that I have tried it on except the Surface Pro 4, and that is the device that we have bought multiple of for testing the application. If the tablet is moving while I try to set the selected camera, it takes a little over 10 seconds for the cameras to actually switch. The time doesn't change much (within a 10 milliseconds) whether the tablet is moving a little at the moment I tell it to switch cameras or if I shake the tablet wildly till the 10 seconds passes and the preview starts back up. Then, if I leave my Surface Pro 4 on its stand on my desk and tell it to switch cameras, it switches cameras in less than half a second. Has anyone else seen this problem? Any idea how to fix this problem?
I need to make a multi touch application for a real state display centre. With buttons and maps and floor plans. And the application will be running on Windows 8.1 0 on a 42 inch screen. I want to know what would be the best technology to make this kind application ? Flash or WPF ?
Does Action script has events for the buttons ?
If it's going to be on Windows 8.1 can you not do it as a Metro/Modern app? The support for multi-touch will be a lot better than it is in WPF I think.
There's some information here on how you can approach different app categories.
Using the Windows 8 SDK will give you the opportunity to use JavaScript instead of C# if you find that easier too.
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.
I'm a C# developer taking my first steps in Windows Mobile development. I've installed Visual Studio 2008 SP1 and the Windows mobile 6 Pro and Standard SDK's. Now I am trying to create a simple winforms application.
The problem is that when I set the Target Platform to Windows Mobile Standard, I seem to be missing a lot of controls. For example, there is a checkbox, but there isn't even a simple button (take a look at this screenshot ). When I switch to Windows Mobile 6 Professional, I get all kinds of controls.
What could be the problem? I've already tried to repair the WM 6 standard SDK, but that did not help.
Thanks,
Adrian
That's correct. Windows Mobile Standard, also known as Smartphone, doesn't have a touchscreen. All interaction is done through the two menu action buttons. Because of this many controls, like buttons, don't make sense and are therefore filtered from the toolbox.