Caching the contents of tab controls
Locked
Caching the contents of tab controls
 
|
Re: Caching the contents of tab controls
|
|
Re: Caching the contents of tab controls
|
|
Re: Caching the contents of tab controls
|
|
In reply to this post by Carl Gundel
On Jun 16, 2011, at 6:59 PM, Carl Gundel wrote:
> Is there a simple way to cache the contents of each tab in a tab control so that I do not have to recreate them over and over? I am trying to create a tabbed source editor, and I need the contents, scroll position and selection of each text editor to persist when I switch back and forth between each tab. TabControl is not well set up to do this, IMO. Everytime you change the client: of the tabControl subcanvas, it's going to do a full release of your current view tree below the canvas. And now you're stuck with the ugly problem of recreating it. What makes it harder, is that your model doesn't have all the state you'd like to preserve. In the case of a tabbed set of text editors, your individual app models may capture things like the text, but it won't capture the current cursor position, the scroll, the selection range, etc. You'll have to write code to capture it all yourself. Or... we can quit pretending that the app model gives us very good model/ui separation (after all, if it did, we wouldn't need to have our app models hold on to something analogous of a C linker to get at the objects produced and then write code left and right like "(self widgetAt: #blah) component component etc"), and realize that the widgets have meaningful state, and throwing them all away, rebuilding is not what we always want. PartPort was introduced to the system to try and get around this problem. It's basically a dynamic view cache, with the idea that at any time, one and only one of its dynamically created child views is the "active" one. In this way, we can build all the views for a given tabset, and then just swap which one is active. In the case of a TabControl, rather than swapping clients on the subcanvas, I add a single PartPort child to the subcanvas (the subcanvas is just a standard CompositePart). And then I let that PartPort instance do all the work. The bottom half of the RB is managed this way since 7.5.1 (or was it 7.6?). It gets rid of a whole bunch of ugly code. In your case carl, the one tricky part, is that a click on the tab control, defocuses the current text editor, and a new one shows up. But text editors don't show their selectionRange unless they're focused. So you have to arrange for the tab switch to refocus the newly activated texteditor. I wrote a quick and dirty example of this and have attached it as a filein. I did it from a recent 7.8 build. It might work in 7.7.1 or earlier. YMMV. -- Travis Griggs Objologist "I did not have time to write you a short program, so I wrote you a long one instead." _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
ForCarl.st (4K)
Re: Caching the contents of tab controls
|
|
Re: Caching the contents of tab controls
|
|
Re: Caching the contents of tab controls
|
|
| Free forum by Nabble | Edit this page |