Well it’s been a mixed week but on the whole progress has been made. I’m still suffering the fall out from rebuilding both the PC and laptop. It’s suprising how much little apps need to be installed to get the systems back to the way they were.
On the development side the week started slow as there were errands to be run on Monday that meant there was little development but Tuesday saw the customization of context menus implemented.
New in Modellers Assistant is the use of context menus over various controls and tabs to allow for customised menus that are applicable to the area of focus. This serves several purposes – the interface is kept cleaner as the number of disctracting buttons are reduced, the menus are customised to delivering functionality that is focused to the control or tab and not as a general feature, as there is a reduction in button to do something then there is more space for the controls that are of interest.
The issue that I had with the context menus is that I wasn’t satisfied with the default way they were displayed. As I have a number of context menus in the application then I wanted to have a title on each one to give visual feed back as to what the menu was for. Now most controls can be customized by using the ownerdraw property to inherite the base control and then customize the areas that are applicable to you but not the context menu, it uses a renderer to allow for customization of certain areas of the control. This meant developing a custom renderer for each of the context menus to get the look and feel that I wanted.
With that implemented I moved on to developing some of the other functionality and then I spotted a problem with the listview control. The listviews are a key control in the application as they display the data that is in the project, stock, and shopping lists, as well as some other data in other tabs. The listview is a convenient control that can display the data in a spreadsheet style list keeping things neat and tidy. Now I know that the listview suffers a performance problem with large amounts of data but the performance is acceptable for my purposes.
The problem appears when scrolling the listview. If the listview is scrolled with the navigation keys (page up, page down, cursors keys), or a mouse wheel, or the scrollbar slider then there is no problem. But if the scrolling is done by the scrollbar up and down arrow icons or the scrollbar background (are either side of the scrollbar slider) then the listview display is corrupted as the grid lines are drawn over the text or not drawn at all. This only happens on XP with .NET framework 2.0, with themes enabled on the application, and gridlines showing in details view. The problem doesn’t happen on XP Home edition but only on XP Proffesional. The problem lies with the way the operating system handles the control and Microsoft ain’t fixed it yet and there is no indication as to when it will be fixed.
The solution? Well there isn’t one as there is now way to override the drawing of the grid lines by ownerdrawing the control. So it’s either write a new listview from scratch (which is a bit beyond me at present), use someone elses listview control (which may not give me what I want or give me problems in licensing issues), or use the datagridview control as a replacement.
I’ve opted for the later as the datagridview is a new control in .NET 2.0 and is a replacement to the old datagrid control. The datagridview control is more customisable and flexible than the old datagrid control. With a little extra code I have managed to get the datagridview control to display the data is same manner as the listview control and handle in the same way. The datagridview is also designed to handle lots of data so the performance is better than the listview control in the long run.
I’m currently replacing the listviews with datagridviews. I have 9 listviews to replace and have done 3 by the end of yesterday. The weekend should see all the listviews replaced.
Whilst implementing the context menus and datagridview, the testing process revealed some bugs which have been resolved.
June 22, 2007 at 1:37 pm
I’ve got the same problem over here (Brazil) and I’ve used the same solution. But I would like to ask how are you databinding to the DataGridView? I’m using lots of strong-typed lists since we can databind to IList, did you’ve done it some other way? Are you creating DataTables for your runtime databinding?
Regards,
June 22, 2007 at 4:56 pm
Hi Felipe
I don’t use databinding at all within my program for several reasons:
I want to have full control of when and how the data is changed and updated.
I want to perform some data validation to create different row colours in the datagridview depending upon the state of the data.
Much of the data is not directly editted by the user and so I find it easier to control the datatable updates manually.
In general I populate a datagrid view via a datareader that loops through each record of the table. This allows me to perform the data validation and set the different row colours for the data state.
I also create a datatable for the data that gets update when the data is changed and this is re-filled when the update has been completed. Where a single item is updated (i.e. one cell) then I use an SQL call to update the table directly and then refill the dataset and datatable back.
As my datagridviews are not displaying thousands of records performance appears to be satisfactory.
Whilst I appreciate that the way I have done things is not the most efficient or speediest ways they do work. I would like to point out that I’m not a professional programmer but I have been programming a number of years for myself.
Should my program start to become slow when populating the datagridviews then I shall have to look for alternative ways of doing things but this will probably come as I become more experienced with the change of programming in the .NET framework and data access in the pre .NET framework era.
Hope this helps you.