I am writing a text editor and right now if I type very quickly or hold down a key the typing gets very laggy. I was previously working on a winforms version of this program and there was no lag. Would it be possible for me to create a custom richtextbox control and strip out all of the unneeded properties? What would be the best way to fix my problem?
Check out the AvalonEdit open source syntax-highlighting text editor that is used in SharpDevelop. It may give you some ideas. I would also look towards .NET 4 which has been worked over big time in order to achieve big performance gains needed by Visual Studio (which uses WPF for nearly the entire shell.)
In particular, in .NET 3.5, controls did a lot of unnecessary repainting. Check out this blog post about WPF performance tips.
Related
We have an old application built on .Net 1.1 Framework and Winforms. We are planning to migrate it to the latest version of .Net.
Here are some of the questions running in my mind:
Should we go with Winforms or WPF?
We want the design and structure to the exact same as what we have now.
What kind of pitfalls can I expect when migrating?
Is there any place where I can lookup to see the process of migration?
Any other suggestions?
Should we go with Winforms or WPF?
This is a very broad question. But my answer to that would be this. Winforms designer is a painful experience and it is not as flexible as WPF by any means so if that is important to you then you should.
We want the design and structure to the exact same as what we have now.
Anything you do in Winforms you can replicate in WPF so no worries there.
What kind of pitfalls can I expect when migrating?
There are too many to name one of the most common ones for our migration was converting existing logic in the WinForms (yes it was a crappy, outsourced, legacy WinForms full of business logic) and connecting it to WPF elements. The process in and of itself is not that complicated but when you have too many intertwined pieces it can get pretty ugly.
Is there any place where I can lookup to see the process of migration?
The process of migration pretty much has to be iterative. So the way many people do it based on my research (articles, StackOverflow answers and such) is through ElementHosts.
1) Target a certain part of your WinForms that you would like to switch up to WPF and then take it out.
2) Replace it with ElementHost.
3) Then in that ElementHost you will have your newly rewritten WPF counterpart.
4) Test it out make sure that it works okay with the rest of the elements.
5) Go to step 1 until rest of the stuff on that window is replaced (You can do header, middle, footer or top, bottom any way you wish to go about replacing elements on the window it depends on your particular situation).
6) Once most of the stuff is replaced you can then combine all of those WPF User Controls into a WPF Window.
I want to create a UI for my application.
What really confuses me is how to actually do it. I know that Microsoft has introduced WPF.
I have also seen some examples, but what I am not getting is whether or not WPF a seperate language? How can I use C# with WPF?
Lets say I want the user to click on a browse button, select a file and display it's content on the UI. I want to do it using C# while WPF providing the UI, is this possible?
Any good resources for a newbie like me?
EDIT
What i didnt understand, will i use WPF for my UI or windows form for my UI while my actual code is in C# ?
I think i am being lost here ? WPF seems something else that supports c#. is that true ? i thought WPF was only for UI while the actual code would be in C# or VB.
I have taken wpf unleashed but it explains wPF and not how to use C# with it. Atleast in the starting chapters ?
I know i am being dumb here but i am really confused
Yes it is definitely possible. Take a look at this article about Mode-View-ViewModel (MVVM) from Microsoft, which is a good introduction to using Xaml (the markup language for WPF) with C#.
Since you are familar with WinForms I will explain it like this.
WinForms provides the GUI and it is similar to what WPF does.
WPF however mainly uses XAML, a markup language based on xml to design the visual elements. It is a presentation foundation on its own that could be used without XAML but it is certainly a big part of it.
When creating an application it will be either WPF or WinForms you can't combine the two (well easily anyway I know there are a few ways to get around it)
You can interact with WPF the same way you interact with WinForms elements.
You can create a Window. On there you can place a grid, where you can then place controls such as a button or textbox. Then in the code behind it is exactly the same as referencing a control in winforms. for example in the page_load function doing
txtInput.Text = "A String";
So what should you choose? (Please note I am about to give you a few things to compare I realize this hardly describes both technologies to its fullest)
WPF
Pros
- Great for visually appealing designs
- You have XAML based control over your visual elements. Meaning you can change the way your form looks by writing xaml instead of doing all through the visual studio IDE pressing buttons.
Cons
- Bit of a performance hog. It has come along way with .net 3.5 sp1 but still chews up quite a few resources
- Not as many controls built for it as WinForms, mainly because its a newer technology.
- Can become complex as syntax for binding information to controls doesn't include intellisense.
WinForms
Pros
- Familiar and well used technology so your development will be faster
- Better performance
- More controls built for it
Cons
- More effort to build a visually appealing design
- Its not new and exciting so to speak. I know we all like to learn new things :)
It is not a seperate language. WPF employs XAML, a derivative of XML, to define and link various UI elements. As in web development, both layouts and specific themes are well suited to markup, but XAML is not required for either. Indeed, all elements of WPF may be coded in a .NET language (C#, VB.NET). The XAML code can ultimately be compiled into a managed assembly in the same way all .NET languages are.
You can implement your requirement in easily WPF.
To get a hands-on in WPF start with this article, http://10rem.net/blog/2010/02/09/getting-started-with-wpf--hello-world-in-multiple-flavors
Happy coding..
WPF is part of .NET framework, so it's not related with specific programming language. Please read MSDN's "Introduction to WPF" - http://msdn.microsoft.com/en-us/library/aa970268.aspx
I have a WPF application, and it's slow.
It is NOT the rendering. Firstly, the rendering is quite simple, and secondly, I looked at it with WPF Performance Toolkit - nothing.
It is NOT in my own code. Firstly, the unit tests work fast, and secondly, if I replace all DataTemplates with blank ones, everything works fast.
So far, it looks like the slow part is template instantiation. That is, when you start the application, and open some complicated screen, it takes a lot of time. And by "a lot" I mean "a lot". Sometimes can be as much as 3-5 seconds - for example, when there's a datagrid with 100 rows. But when you go to another tab, and then go back to that same screen, it opens fast (as long as its viewmodel stays put).
This is very annoying not just because it's slow, but because I can't do anything about it. If I had some control over the slowness, I could, maybe, display some "opening, please wait" message or something...
Besides, when I look at some other WPF applications (most notably, ILSpy), they seem to work reasonably fast, despite the large amounts of data. This makes me believe that I'm probably doing something wrong. But I have no idea where to start.
Any ideas? Any classic mistakes? Any tips?
My exerience comes from working on the WPF mind mapping application NovaMind
A couple of months ago we completely rewrote our intermediate layer to solve the performance issues we had experienced. In a nutshell, creating our user controls seemed to be way to slow. Unfortunately I couldn't find a great way to profile the performance as neither the WPF Performance Suite nor commercial applications such as ANTS Profiler give you any detailed information on this part of the WPF process. (I asked this question back then)
We resorted to manually test our application by trial and error and removed parts of our user controls to see what exactly is the culprit.
In the end we solved the performance issues by completely rewriting our controls. We also cut down on the complexity of our visual tree dramatically. Before the rewrite, one of our most used user controls, when inspected with Snoop, consisted out of 61 different things, now there are only 3. Wherever possible we only added things to the visual tree on demand. (As you know in XAML even when you set things to Collapsed, they need to be created first).
Finally we were forced to write our own rich text rendering control as the built in RichtextBox is ridiculously slow and the visual tree of the RichtextBox is quite complex.
I don't know if this will apply to your situation but I would recommend that you investigate your user controls and see if they are complex. Maybe you have things that you could trim.
Low hanging fruits would be parts that are only rarely visible or can be created in a lazy manner. You could create these parts from code behind when necessary rather than having them in XAML. This should help you a lot.
Otherwise virtualization is your friend, if possible. In our case we couldn't do that unfortunately.
This sounds similar to a problem i was having. I posted the fix here: WPF UI Automation issue . Just posting for the benefit of searchers, as it took ages to resolve.
Following comment on link only answer, here is the crux of that post:
I did the following:
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB978520 (may not be required)
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB2484841 (definitely required even if you have Windows 7 / .NET 4)
Improved the code further (the validation was causing an excess of objects) - Why does WPF Style to show validation errors in ToolTip work for a TextBox but fails for a ComboBox?
It may be that only Number 3 was required, but it worked. Just posting here so people dont lose the days I lost in memory profilers etc.
User Control in your data template, is not completely bad idea but if you crave for performance then you should consider switching to lighter control. For example, having a UserControl just hosting a TextBox is very bad idea, as UserControl is made up of ContentControl, ContentControl hosts ContentPresenter and ContentPresenter will host TextBox so if you notice your Visual Tree, it has three new layer of UI Elements. Reducing Visual Tree will certainly improve the performance.
Most likely, I would suggest creating Custom Controls that may be a completely a new control having few dependency properties that can relate to data you want to present and you can have its own custom template in generic.xaml. Second, you can just simply derive a control from existing controls and redefine its default template in generic.xaml.
This approach will certainly work better as you will be reducing your Visual Tree, thus reducing Visual State Manager's job.
Changing theme or template will be slower then changing the element that hosts content. And let the element have the default template in its own generic resource dictionary.
Try moving all the resources up as
far as they'll go, preferably into
app.xaml
Check if you could use StaticResource
instead of dynamic ones, static ones
are alot faster
If possible, try using depedency
properties in your VMs, especially if
you have alot of them at once or if
they have alot of properties. That will keep wpf from having to do a bunch of reflection.
You mention you are using a DataGrid with, say, 100 rows. A likely culprit of your perf problems is that whatever datagrid you are using isn't doing virtualization, and so your visual tree is gigantic.
Normally, long startup time in WPF screens points to a large visual tree.
I'm not sure if you're using a datatemplate per row, or some 3rd party grid that binds columns, or what - but lets say you have 8 columns with controls. Depending on your grid/validation/etc, this could be a visual tree of 20-60 items per row. If you have a combobox, then each item in the dropdown may be created per row as well.
To fix this just takes watching the details, and taking measures as you go:
Use a virtualizing control as much as possible. This means using a virtualizingstackpanel inside list controls, and making sure your 3rd party controls do as well (many stock WPF controls do now by default)
Do not overuse UserControls, composite controls, etc. Adding depth adds time, and putting in extra visual tree depth in a datatemplate or other repeated area adds up fast.
If all else fails, show a simple screen and add controls through code to improve perceived performance
I'm starting my first C# project, and I want to make a "form designer" (like the one in VS).
The idea is, there will be a visual form designer with a limited toolbox, which will generate Python code (later more) to create the same form.
Problem is, I have no idea how to even get started. First of all, I have the form designer in VS: how do I make a "form-within-a-form?"
Next... I have no idea how complicated this is going to be. I suppose I could just make little boxes appear beside each control created on the form when it is clicked, for resizing, and make a textbox appear on it when double clicked or something, to change the text in it... Things like this.
So another thing I would like to know is this:
I do have programming experience in C and C++, I've done PHP for a number of years and am starting with Python as of recently. I've generated forms dynamically in VB6. Given this experience, am I in way over my head with this project?
this looks like a really good place to start. It has a pretty good example to get you started. You can even download his source (registration required).
It sounds like you're aware it's non-trivial for a C# first-timer. If you keep it pretty simple, it sounds like you're heading in the right direction (although a web-based form designer might be easier).
SharpDevelop would be an example of a full-featured IDE that can be re-purposed, but that's way over the top.
Good luck!
For most people starting out in C#, this project would be too much. With your VB6 background, you may be able to pull it off, though.
Here's a hint: the Visual Studio Windows Forms designer draws controls on its surface - by asking the controls to draw themselves.
I know about code-behind files, but what is the best real-world way of Designers that are using DreamWeaver or other Design Tools to work with Visual Studio programmers?
For example, say you have a basic website with user interface forms hitting the database... the database work is definitely done by the developer but how to tie the designed forms with the database coding or client-side logic that may involve events on controls, or other GUI related tie-ins. Are the graphic designers also controlling application flow? There seems to be a large disconnect that needs addressed - especially when it comes time to tweak the design after it's been implemented.
Use another approach like MVC, separate your design from your logic. Like this every member (designer / developer) of the team can focus on what they do best.
MVC implementations: link / link
The best way is to make sure that your designers have some knowledge of what kind of HTML they will be working with.
Every ASP.NET developer is aware of MS-HTML, that lovely nesting of HTML tables, but designers aren't. Designers have their own requirements to meet and they'll do them in the best manner possible. Sadly it's not often good for us.
I am always frustrated when I receive a design from our UI team which shows radio-buttons nicely layed out in a grid using floating div's. Then I have to shatter their dreams that no, I can't generate you that HTML (ok, I can with the use of ControlAdapters, but every time they are different designs!).
Try and have a 90%/ 10% rule, where 90% of the design is done before the ASP.NET starts and the 10% is done once the ASP.NET is completed, and done against ASP.NET generated HTML.
And make sure you're using source control! Code doesn't exist unless it's in source control! And thanks to the latest TFS PowerTools there's a lovely Windows Shell integration component so you don't need to use VS to check in and out now more :D
This may sound really cheezy, but when I was working with Dreamweaver / Visual Studio, I'd do my layouts, and then conveniently put [RADIO BUTTON HERE], [INPUT TEXT HERE], etc. in the places where my form elements/controls would go, and I'd save the page as a basic HTML document.
That way Dreamweaver wouldn't nest its own form tags in and I'd have easy to locate places to drop in my ASP.NET controls when I went to merge things in. It was easy enough to create a fresh web form page in Visual Studio and then copy and paste everything over. If for some reason I mucked things up, I'd have a basic HTML "template" to start over wtih.
Unfortunately this is an all too common problem. Dreamweaver typically doesn't write html that is friendly to a .net developer. If at all possible, get someone who can actually read, and write HTML,not just use the Dreamweaver WYSIWYG editor.
I often found that if I'm working with a designer that doesn't know html, that I actually save a lot of time be just having them mock up everything in photoshop, then give me sliced up images. I find that my writing the actual HTML in a .net friendly format saves a ton of time, instead of having to go back and forth with the designer in this situation.