![]() NET platform and adds the following features to its ActiveX predecessor: 10Tec WinForms grid was rewritten from scratch to be a native component on the. It might also be a good idea for you to load your image from the file only once and then keep it in memory so you can re-use it, rather than loading it from a file every time you need it.IGrid.NET is a WinForms software component based on the successful ideology of iGrid ActiveX grid control. There's a section on re-using appearances that may help. If that's the case, you might want to take a look at the WinGrid Performance Guide. You probably have a small set of images and you apply the same image to many cells. How many images do you have? Typically, an application will not have a different image for every cell. There are a number of ways you could speed things up, but without knowing more about exactly what you are doing now and what's causing the slowdown, it's hard to give you any more specific advice. If you are already using LoadOnDemand, then only the rows in the grid that are in view will be loaded and InitializeRow will only fire for those rows, so it seems very unlikely that you would have a performance problem in that case. Are you saying that you are already using LoadOnDemand? Or are you considering that as a possible solution to the image problem? Having said that, I'm not sure exactly what the situation is here. It order to use threads, you have to marshal all communication between those threads and in the case of DataBinding, you are not in control of the communication between the grid, the BindingManager, and the DataSource, so it's not possible to do proper marshaling. I would very strongly advise you against attempting to use a separate thread anywhere near the WinGrid or any bound control. So you may also want to try commenting out any event handler code for your grid (and possibly other controls on the form) to see if you can narrow it down that way. This code could be triggering an event and that event handler code could be the cause. The flickering may not be caused directly by this code, of course. See if it gets hit and if it does, you can look at the call stack and that might give you a clue as to what's forcing the grid to paint.Ģ) Take a look at the code you are using in between BeginUpdate and EndUpdate and try commenting out parts of it to see if you can narrow down the code that is causing the flicker. If you want to try to track it down, then there are a couple of approaches you could try.ġ) Immediately before, or perhaps after, you call BeginUpdate, hook the Paint event of the grid and put a breakpoint in the event. ![]() It depends what exactly is happening in between the BeginUpdate and EndUpdate statements. Tracking this down will be probably be pretty difficult. For example, when you resize a form, some O/S's will force the controls on that form to paint and others will not. ![]() ![]() There are some known differences in the way Windows XP handles painting under certain conditions. So my guess is that something in Windows XP is forcibly invalidating and re-painting the grid while you are inside your BeginUpdate/EndUpdate block. If something invalidates the grid and forces the grid to repaint - like if you called the Refresh method, for example, then the grid would be painted and simply skip it's own internal painting logic and it would end up painting in solid block. When you call BeginUpdate on the grid, this tells the grid not to paint itself.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |