I have a problem with Visual Studio 2010. It happens when I scroll down/up, for example, in properties window. Its content becomes blurry for milliseconds.
It also happens in my own WPF applications when I use a “ScrollViewer”.
Does anybody know how to solve it?
In your own WPF applications it is possible to constrain scroll offsets to device pixels by using a custom IScrollInfo implementation. This is easy enough to do. Note that you will have to get the actual screen DPI to do the calculation.
In Visual Studio there is no "reasonable" way to fix it. Obviously you could hack up the VS.NET executables to include your own IScrollInfo implementation, but I wouldn't recommend it!!
Just about the only way to avoid the problem is to avoid WPF entirely. As nice as it is in some ways, it still1 doesn't get text entirely correct. And yes, WPF is the source of the problem in Visual Studio -- as of VS 2010 they switched parts of it to use WPF.
1"still", in this case referring to the fact that it used to be even worse. As of .NET 4.0 they've fixed some of the most egregious problems, but (as you've seen) it's still not really right.
I had the same problem. There is actually a way to fix this while scrolling.
Just add those 3 attributes to your content control:
SnapsToDevicePixels="True" UseLayoutRounding="True" TextOptions.TextFormattingMode="Display"
Just note that the text might not look as smooth as it should while scrolling (instantly goes away once you stop scrolling though)
Related
We are starting a WPF project that will use Prism 4.
We have a designer who will design the screens using Blend / Sketchflow.
We had originally thought of using the xaml that Blend generated directly. However, we have been advised that this is not a good idea due to the readibility of the xaml created.
Has anyone any experience with using the xaml directly from Blend? Is this something that you would recommend or not?
We had originally thought of using the xaml that Blend generated directly. However, we have been advised that this is not a good idea due to the readibility of the xaml created.
It completely depends. Blend, especially newer versions, does a fairly good job of creating reasonable xaml.
That being said, it's still a designer - most designers don't write the same code you would when writing by hand. It's often still useful to "clean up" the designed code as you're working, so understanding what Blend is doing can be helpful.
That being said, there is no problem with using Blend's xaml directly, especially if you don't need/want to hand edit it to add additional functionality, or work with it outside of Blend at all.
One thing I've noticed about using Blend is the Margin it uses, and in general, how fast Blend can mess up the layout of your views.
Let me give you an example, when you place let's say, a Button on your initial Grid, unless you specify rows/columns explicitely, Blend will just put a Margin to set your Button's place.
This is awful.
Now using Blend/Sketchflow is not a bad idea, but your designer will absolutely have to learn a bit of programmation logic, at least the layout things. And if he's going to re-style UIElement from scratch, he's in for a rollercoaster of a learning curve...
Following on from this question, I understand that Visual Studio 2008 doesn't accurately render Designs made on Expression Blend. The additional problem I have is, the View of the Window doesn't match with the Design shown on Blend. I am using Expression Blend 2.0, and Visual Studio 2008(.NET 3.5). Could this have something to do with it?
The design is very simple, just some buttons placed next to each other. I understand without the XAML code, it would be difficult to address the exact problem, I just want to know the strategy to tackle such difference.
In your previous question, you failed to mention you were using version 2.0 of Blend. That's a terribly old version. It's akin to wanting to write .NET 4 code and having only VS2003 installed. If you're using VS2008, you should use Blend 3; if you're using VS2010, use Blend 4. The version mismatch is probably part of your issue. I'd need to see code (both .xaml and .xaml.cs) to figure out the rest.
My issue has been resolved. Though I am still confused as to why Blend can't render the Run time layout properly. What I found is, by putting boundary markers around each button keeps them in the same view during Run Time. Otherwise, one of the button appears to occupy much larger area than it set to. In any case, the problem at hand is too localized for someone to tackle externally.
I'm looking to extend the GridSplitter in some way to add a button which when click expands or collapses the control to one of the specified sides of the splitter.
I've found a solution that works for Silverlight 4 but I need this to work for standard WPF in .NET 3.5 which means that the GridSplitter doesn't implement the Visual State Manager stuff that is used in Shemesh's solution. Other than it won't work for WPF in .NET 3.5 I think Shemesh's solutions is probably exactly what I'm looking for with smooth animated transitions and remembering the last expanded size upon expanding from a collapsed state.
Anybody have any examples of this being done in regular WPF?
Ok, I've tinkered with the Silverlight example enough to get something working for .NET 3.5 SP1 and the WPF Toolkit February release for the Visual State Manager stuff. Below you can find the two main source files that I've fixed, refactored, and reorganized quite a bit.
The solution is to big to post on StackOverflow so please see my blog post that has the code snippets you will need.
Would it be practical to create WPF applications without ever touching Visual Studio (or any other IDEs)? As in, coding and compiling completely within Vim and the command-line? What resources would you recommend for someone trying to do so?
It would be possible, since basically WPF is based on XAML - a variant of XML - and C# or VB.NET or another .NET language as its backend language.
The question really is whether that's practical and if it makes sense - I highly doubt it. WPF is all about visual design, e.g. totally without a visual designer (either the built-in one in Visual Studio, preferably the 2010 version; or some other visual designer), it seems a bit silly to want to program WPF....
As for resources - well, a least a text editor is a must, then definitely a few good books on WPF, and you could leverage the C# or VB.NET compiler that comes with the .NET framework.
I have found myself writing XAML in Notepad on a number of occasions where I needed to create a quick UI but couldn't load an IDE. It is really quite trivial, and almost - but not quite - as fast as using an IDE. The main advantages of an IDE such as Blend or VS.NET are in quickly getting things like colors and animations to be "just right."
Another occasion when I frequently write XAML or C# in a text editor is here on Stack Overflow. I only fire up Visual Studio when I need to test something out.
My main recommendations for creating WPF applications without an IDE are:
First you should make proper use of WPF's layout system, using appropriate panels and "Auto" sizing wherever possible. For example, if you want a stack of buttons with some space between them, create a <StackPanel>, and on each button add Margin="4" or whatever. This is good design anyway. Most beginning WPF programmers treat it like WinForms with no layout capability, which is a shame. WPF has a very powerful layout engine and it should be used. If it is, there will never be any need for graph paper or measurements. In addition, your UI will automatically adjust its layout if you change font sizes or objects are larger than expected.
Second you should use msbuild for your project unless it is ultra-simple. msbuild is installed along with NET Framework so it is always available. The file format is very easy to edit with a text editor, and it is much better than a batch file with the appropriate "csc" command because it allows you to use code-behind and is less error-prone when adding new source files.
Third keep a PowerShell command line window open separate from your editor, with a command that runs "msbuild" and then executes your application. To run your app, then just Alt-Tab to this window and hit uparrow, Enter. Some text editors have the ability to execute user-defined commands directly from within the editor and see the output, in which case this second window is not necessary.
Fourth keep a copy of cordbg or mdbg handy. Although an IDE is the ideal place to do your debugging, any debugger is better than none at all. You will find your problems much faster if you stop at breakpoints and examine variables than if you just keep editing code and re-running.
Fifth, use "ColorPad" or a similar application to select your colors for use. Just guessing and entering your best guess in hexadecimal just doesn't work very well.
For resources, I recommend you get the book "WPF Unleashed" and work through the examples. I would also read a lot of other people's XAML, such as can be found on CodePlex.
Possible, Yes. Practical No.
For production work, I would consider Microsoft Expression Blend 3. Then copy the XAML and paste it into the editor of your choice and compile from the command line.
You could download KAXAML . It's a free, lightweight editor. I found it good for learning about XAML and seeing how minor changes and tweaks can impact on an overall design.
XAML is plain old text so find a free editor (KAXAML), use it, and if you must, paste into your editor.
If you really want to go down this route, I'd recommend getting some graph (squared) paper and a sharp pencil.
Draw out your designs on that, read off the positions and type them into your editor of choice.
One benefit of this is that you're going to have a paper prototype to show people ;)
As James Keesey points out in his comment on marc_s's answer, your edit-compile-test cycle is going to be painful.
It's definitely possible. I'd say it's not practical, though.
To be honest, I do professional WPF development and I do it with the visual designer closed. I'm much more comfortable editing the XAML by hand, just like I write HTML. However, the benefits of an IDE go far beyond the visual designer. There's IntelliSense, debugging and a whole host of other invaluable features.
Really, I must question your motives. What are you trying to gain? Visual Studio Express editions fully support WPF development, so it can't, or shouldn't, be a cost issue.
The newest version (3.0) now supports the wpf template.
Just download it from: https://dotnet.microsoft.com/
Just type in console:
dotnet new wpf -o wpfHello
cd wpfHello
code .
Greetings :-)
I am relatively new in the WPF world and one thing I immediately noticed is how laggy the window content is drawn when you resize a window. For example if you have scrollbars at the window edges those scrollbars will be partly hidden while shrinking and have space between them and the window border when enlarging.
This even happens with an empty WPF project created in Visual Studio. What's even worse is that it also happens with the background and you can see stuff behind the window (other windows, desktop wallpaper, etc.) leak through when enlarging.
At first I thought that it's an ugly limitation of WPF seeing that native or WinForms applications resize just fine (if written properly). But when I look at Expression Blend the window background stays opaque (though the window content still lags behind). What do they do to prevent described problem and are there any ways to improve resizing to more approximate native/WinForm GUIs?
The reason of lags is nicely explained here
Are you running Vista without SP1 ? From what I have read, this was a common issue that is supposed have been fixed..
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/3960d6a6-e873-455c-9ddc-1e2dd32e090b/
I'm not seeing this behavior, myself. I develop on vista x64 sp1 and/or a virtual pc running xp x32 sp3. Wpf uses directx, could it be your video card/machine? Try running your app on a diff machine and see if you have the same results.
I have the same issue with the interface lagging while resizing. I suspect that the reason for the lag is it is resizing the underlying frame buffers in direct X which is never particularly fast. I am not sure what you can do about it though.
I've been looking for information on this issue as well. I just thought it was a windows "feature" that some intrepid microsoft programmer thought would be cool. I was hoping to be able to turn it off so that window resizes would actually follow my mouse, instead of lagging and then overshooting. Grr.