On a couple of PCs here, critical ones of course, our 2-band WinGrid will react to various assorted actions by losing all of its data and columns which results in blank rows of a single column that spans the entire width of the WinGrid. One time, this disintegration of the WinGrid left a vertical scroll bar button. When scrolled down, the correct content of the WinGrid came into view from below the window, the blank single-column rows went away and the good content with data and columns snapped into place. Ususally, there is no scroll bar button available and the only way to recover is to reassign the same DataSource which will result in the correct display...which is shortly thereafter again destroyed by the most inocuous activity - a key stroke or right-mouse-button click, etc. We only suffer this behavior on 2 PCs - can't reproduce it on others. I have screen shots but don't have permission to attach them to this post.
This is why the grid has a SetDataBinding method - to allow you to set both DataMember and DataSource at once, instead of separately.
All gallant guesses, but incorrect. It is a stability issue which chokes WinGrid but is easily avoided.
Given the typical related Customer, Order and OrderEntry DataTables in myDataSet, one might want a WinGrid display composed of:
1) myWinGrid.DataMember = “Order”;
2) myWinGrid.DataSource = myDataSet;
That produces a lovely two-tiered hierarchal perspective. One might also provide an alternate perspective that focuses on just the OrderItem table thusly:
4) myWinGrid.DataMember = “”;
5) myWinGrid.DataSource = myDataSet.OrderItem;
I realize that this changes the DataBinding paradigm on the fly, but there are times when a defined DataMember is preferential and other times when no DataMember works better. But the above approach to changing a WinGrid perspective can fail.
When line 4 is executed, it widens the DataBinding scope to the entire DataSet just before executing line 5. This can cause a firestorm of DataSet, DataTable and DataBinding events, which, especially if the DataSet is of significant size and complexity, can overwhelm WinGrid. It retaliates by going blank except for single column rows that span the width of the WinGrid which causes your boss and corporate clients to question your true competence and can lead to significant loss of sleep and hair.
The solution is to prevent the DataBinding from widening in scope to the entire DataSet:
…
3) myWinGrid.DataSource = null;
It sounds like the grid is getting into a bad state where there are few enough rows that they will all fit within the available vertical space, but they are scrolled out of view, anyway.
This should never happen, but there have been some bugs in the past that caused this to occur. It's also possible that this could be caused by a timing or threading issue.
What version of the grid are you using?
Is your application using threads?
Are you using Application.DoEvents anywhere in your code?
Hello,
You could attach the screenshots in an archived file(zip) through the 'OPTIONS' tab above when you are writing your post.
I am not aware of your scenario, neither your actions and therefore do not understand the described things by you.
Do these machines differentiate from each other by the operation system or anything else? If I am not able to take a look at such sample I can only try to make a guess out of some screenshots.