a lurker here, but time for my own question.
The question applies to this code: http://pastebin.com/dQKnSSpY I posted it on pastebin because it'll mess up this page otherwise :)
my question is why the GUI is quite lagging when I run this GUI. I've already tried several things, including DoubleBuffering, a seperate workerthread for adding the Controls and using BindingSource.
Nothing helped yet. I'm feeling a bit dumb, because usually my C# skills are okayish. (quite new to Windows Forms)
thanks in advance
I think your problem lies in the fact that you are creating controls inside Paint event. I'm little rusty now in Windows Forms, but i think Paint event is called when the control needs to redraw itself and that is controlled by the OS with WM_PAINT message. And that can happen frequently. Maybe you should try to add controls in the Form constructor and not in the Paint event.
It is a very simple change but it may help:
http://pastebin.com/FnXJCAUE
I took the Screen.PrimaryScreen.WorkingArea calculations out of your GUI updates and replaced them with a constant Integer that is calculated only once at the initialisation of GUI Class. This should help reduce the number of calculations performed each GUI draw and so speed up drawing in general, elsewise I didn't see anything immediately obvious in the code that would slow things down.
Related
There is a form. On the form there is a pictureBox docked on all form's surface.
When app starts, for a second a form with white surface is displayed, then
the picture is shown.
how can i get rid of that 1s white form?
Sounds like you are doing something time consuming in form_Shown event. Call Form's Refresh() method as the first thing in form shown -event and it will first draw the form, then do the time consuming things
You have not stated when you are loading the picturebox with your image. But I would try making your picturebox visible at the end of your Form_Load event or in your Form_Shown event.
Sounds more like a threading problem to me. I guess that your UI thread is doing too much work and cannot update the UI often enough.
Do all of the following:
Make sure loading and processing any data (including the images) is NOT located in the constructors.
Move that code into the appropriate FormLoad() event handler methods.
Implement loading of the images so that it runs a separate thread.
You can find some advice in this MSDN article: Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads
If you are working in a .NET 4.x version, you can also use the Task Parallel Library to make working with multiple threads easier.
The upcoming .NET 4.5 also offers the even more comfortable await and asyc keywords: Asynchronous Programming with Async and Await.
In an application that I'm writing I have to load a lot of data in a listview after I push a certain button. Because this might take a while, I want to show a simple loading-screen to the user.
I did this by creating a very simple form with 1 label on it. I do a Form.Show() before I start fetching the data, and a Form.Close() once it's finished. This works partially: I get the loading screen, it closes at the right time, but as you can see the label isn't displayed.
I know I should program this loagind screen-problem with the help of a BackgroundWorker, but I'm not a very experienced C# programmer so if I could just somehow force the label to display I would be more than happy.
Is it possible to force this label to display immediately, or do I have to find another solution?
The UI Message pump has no time to update the label / refresh the screen since the loading process takes up all resources.
You can try to force the update of the label, by calling Application.DoEvents(). Although, using 'Application.DoEvents' is imho a 'code-smell', and thus indicates that the design is not that good. So, it should be avoided.
Therefore, using DoEvents is surely not the best solution to this problem. It is merely a symptom-fix.
You've mentionned the best solution already yourself: use another thread to load all the data. (You can indeed use a BackGroundWorker for this purpose, since this will abstract away a lot of plumbing code).
BackgroudWorker is very easy to use , even c# is very powerful and simple langugage
See Here
i am almost sure that , you would not need any more help with BackGroundWorker but if you have any query , you canm always post on SO ?? Collabartive Intelligence is what SO is?
I am working on application which uses a DataGridView control. Since there is a lot of data I use the VirtualMode to use paging, but even with this feature this take a while to update DataGridView. So I created a control which spins and entertain an user. Unfortunately there are some issues with this solution, namely when the entertainment control spins the UI Thread does handle any of requests from it because it's so busy with this DataGridView.
What should I do to access the UI Thread even if it is so busy?
How do you do to "entertain" an user when you use the DataGridView or is there any main to prevent UI Thread from blocking by DataGridView?
btw. I know that Application.DoEvents probably could help, but I prefer not to use it.
Drop the priority of the DataGridView thread relative to the UI one or just throw in the occasional Thread.Sleep in the DGV data load function.
Combined with a little tuning of your page sizes that should sort it.
I'm not sure what your implementation looks like, so forgive me if you already know this: Setting the VirtualMode property to "true" doesn't make the DataGridView automatically populate itself via just-in-time loading. Rather, it just gives you as the developer the ability to do so. If you're using virtual mode but still populating the entire thing at once, then you really aren't gaining anything. Instead you'll have to implement your own paging algorithm. This is actually pretty easy to do. Please take a look at this MSDN topic for an example. Hopefully that helps!
I wasn't sure how to write topic correctly but lemme describe what problem I have. On my old laptop when i was jumping between code and big WinForm GUI it took sometimes a lot of time before i could even do things within designer. Today I've changed my laptop to newer one and it still has some delays when "redrawing/rebuilding" winform gui.
Is there a way to prevent it to do that? I mean nothing in GUI changes so why would it need to redraw the gui again and again :/
Unfortunately no it is not possible to stop this behavior.
Before leaving the code view and going to the design view, save and do a build (F6). Often enough (but not always) the design view will not be redrawn.
I have a piece of software that has worked fine on many machines, althoughon one machine there is a problem that appears to occur occasionaly, the MenuStrip and the ToolStrip both appear as a blank white background with a red cross over it, as a custom control would if you created a null object. This doesn't happen whilst I am debugging and I don't know how to make the problem re-occur, but it does happen. I was wondering if anyone knew what could be the problem?
Would it be the version of the .NET framework?
Thanks
This is a common occurrence when there's a GDI+ problem ("The Red X of Death"). Are you doing any custom drawing in OnPaint? Or perhaps there's a graphic resource or a glyph which is corrupt or being improperly disposed of.
Edit: I've re-read your question. You seem to have this only on one of the machines. I've googled around a bit for this, and I stumbled upon this old thread. The post at the bottom suggests that there might be an issue with Virtual Memory turned off:
We did manage to solve this - we were
seeing the problem on a device running
XP embedded. The XPe image developer
had turned off Virtual Memory and as
soon as we turned it on the problem
went away. I believe it is just a
symptom of the system running out of
memory to display the graphics (maybe
particularly if you use a lot of
double buffering)
Hope that helps.
Sounds like a symptom of an Out Of Memory Exception to me.
Edit:
Which can sometimes lead onto a System.InvalidOperationException: BufferedGraphicsContext
Are you trying to update the GUI controls from a thread other than the GUI thread? Combine the cross thread operation with an exception handler that swallowed everything and we had the behavior you describe (on a grid control, not a menustrip bar) on an app I was maintaining.
Definitively sounds like a cross-thread problem.
Make sure you use Invoke when accessing controls and/or firing events from a thread that is not the main UI thread.
Seeing this happen on just one computer of more than a 1000 that have our prouducts.
On that one computer I am seeing a .NET 3.5 program occassionally show the red X on its datagrid. And another far simpler .NET 2.0 program got the red X on its menuStrip. I only have source code for the simpler program but I can say that there isn't any user code at all which affects that component. No cross-thread stuff because nothing updates it. It's contents are set at development time with one item added to it at program load. The Red X failure was well after program load.
I was very surprised to see the problem across two different frameworks and on one program that has no data bindings. I am very wishfully hoping that the computer has its virtual memory turned off.
If it isn't that then any guidance on system parts that are shared across .NET 2.0 and .NET 3.5 would be appreciated.
Update: The user with the problem retired the computer and replaced it (which solved the problem)