Hi,
This is a tricky one to explain, so I'll try my hardest with diagrams.
Assume you've got a very big grid, with say, 4 levels of parent/child bands.
Now when scrolling down, the parent level (red and blue) is out of view, leaving the items shown in the final child band.
What I want, is when the top row is in the 4th band, fix the parent (red) band rows to the top of the grid, almost like a "floating" row. The sibling rows of the parent bands still appear to scroll, and the "top floating" band gets replaced when the set of topmost rows hits the next band.
I'm sure there's a better name for this, and a better explanation!
Thanks, Tom
Hi Tom,
That's an excellent description and I understand exactly what you mean. But unfortunately, the answer is no, the WinGrid does not have this functionality.
Thanks Mike!
I have now implemented a contextual helper which runs on AfterRowRegionScroll, it examines the FirstRow of the scroll region, then recursively set the context based upon the FirstRow's level. This works very well, but I've noticed when scrolling with the mousewheel (having anything in the AfterRowRegionScroll event that updates the UI), stops the grid from scrolling smoothly.
This does not happen when grabbing the scroll bar thumb and moving it up and down (it updates the screen immediately).
I've used SuspendLayout etc (I'm very familiar with these types of problems), but I'm thinking the grid fires AfterRowRegionScroll a *lot* more when using the mouse delta?
UPDATE: I've just logged the ScrollPosition to the debug window. When using the Mouse Wheel, it sets the scroll position sequentially, irregardless of it's position, so 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 etc. When using the thumb from the scrollbar, it jumps, so 1, 5, 7, 10, meaning my UI is doing a lot less work!
Not sure how to solve this :|
Here's some code for Mike and anyone else that's interested:
UPDATE: Formatted: http://pastebin.com/UnPNv25T
Ahh Mike you underestimate me! In reality, we're talking microseconds of delay, I'm pretty sure nobody except me would notice... I've written the code to be as fast and light as humanely possible, there is only about 6 lines of code. It'd take a long time to knock a sample project together for this.
All the code does it take the FirstRow of the grid, and check the parent rows, then the "context" is written to 4 labels. It must be done for each scroll, to work out where the user is in the grid. I can't put any screenshots in, but imagine that row 1 indicates a Business Code, row 2 a Company, row 3 an Account Code and row 4 a Purchase Order code, then the 5th band shows a list of products. It whips up that hierarchy and presents it in some labels at the top of the screen. No matter where the user is in the scroll region, the context of where they are is visible at the top (in the labels).
To fix this (tomorrow, it's 10pm) I'm going to try to avoid doing the update if a mouse scroll is detected (Delta <> 0), fire off a new thread, wait 50 milliseconds, then run the context update code on the UI thread. This way I avoid blocking the UI thread due to the fine granularity of the MouseWheel, allowing the grid to scroll.
I'll let you know how I get on in the morning!
UPDATE: I've just done it, I can't test it properly over vpn and the laptop scroll wheel isn't exactly very good, but I think it works!
Tom
The mouse wheel will scroll a number of rows based on what the driver settings dictate. So you must have your mouse driver set to scroll one row at a time.
If this is slowing down our scrolling, then the code in your AfterRowRegionScroll must not be very efficient. So the best thing to do would be to try to make that code as fast and efficient as possible.
But why are you using AfterRowRegionScroll, though? It seems to me that it would be a lot more efficient to only build the context when you need it (right before you are about the set the DataSource), not maintain it continuously all the time.