I am replacing my home grown 'Transposed UltraGrid w/header section on a data repeater' with a 'Card Spaced UltraGrid w/header section on a data repeater'. I am very close but there is an 'annoying' behavior I can't seem to find addressed in the IG model. Anyways, here is the symptom. I have given the users the ability to scroll the individual Card Spaced (single row) grids horizontally. So the user scrolls the grid on one Data Repeater item over to the records for October then decide to look at October on a different Data Repeater 'row' and as soon as they click in that data repeater 'row' the grid on the previous 'row' resets back to January.
Can I stop this from happening?
I seem to remember that there were a couple properties of the WinGrid that were specific to the VB Data Repeater control (I spotted them when the app was being developed a couple years ago and have since 'lost them'). Perhaps they are something I need to look at. Can you point me to where I saw those, too?
Thanks in advance.
Hi,
I'm afraid I don't understand your description of the issue. Could you post a small sample project or maybe some screen shots so I can see what you mean?
Mitchster2 said:I seem to remember that there were a couple properties of the WinGrid that were specific to the VB Data Repeater control
There are no such properties that I am aware of. The grid has no knowledge of, nor connection to, the DataRepeater - at least not directly.
Well, I knew I saw something about a DataRepeater in there...
InitializeDataRepeaterClone (Inherited from Infragistics.Win.UltraControlBase)
and I read about some problems people had with 'mismatching' but honestly ... it took some work to understand the DataRepeater. It uses an item template and then clones the templates to create the items but then it sometimes re-uses them and ... well, it is a little raggedy around the edges. One secret that took some experimenting to get correct is that many (but not all) controls require that their native events (like UltraGrid's InitializeLayout and AfterCellUpdate event) need to be wired up with an AddEvent Handler riff in the repeater's ItemCloned event.
That said we have an enterprise app up and running that uses this control exensively.
Each Data Repeater item (think of it as a panel) has two columns. The first is a header identifying a particular piece. The second column has an UltraGrid which lists all the instances when that piece is needed (by date). Up until about a week ago that was a transposed grid where I was doing all the footwork to make the grid behave like an Ultra Grid in Card Space mode. Each time a Data Repeater item performs it's DrawItem event I LINQ filter my child datatable and bind.
Everything was cool, but we had upgraded the IG package and I decided to give the Card Space feature another go. It is working swimmingly.
The original implementation had some cool code that allowed me to scroll the whole details section (across all Data Repeaters at once) with some arrow keys. It even had some code to only scroll as far as need to get the last set so the user would never be stuck with like one record on the last details screen they scroll to.
Now that I am using the Card Space I have set each Data Repeater item to all have their own horizontal scrollbars for their own grid.
So my user is looking at part A and scrolls the grid on part A's Ultra grid over to show some of the records not currently visible.
Then they decide to look at Part B in the repeater panel just below Part A's.
As sonn as they change the focus away from Part A's panel, the UltraGrid zooms back to it's original position at the first record.
In my original home grown method they could flip through those details like a book but I would be satisfied to just be able to give them the ability to scroll the details grids individually but those individual grids on the repeaters need to persist their scrolled positon when they lose focus.
It would be a big pain to send a sample project ... I guess I could do a wash out against a screenshot... but I am hoping I have explained well enough.
Thanks, Mike.