Here's what we're going to start today, and finish next week: We're going to replace the "Protocol" and "Method" lists with a TabControl which will have two pages. One named Instance, the other named Class.
With this, we'll be able to switch back and forth between seeing the Instance methods and the Class methods. But to start, we have to start. Today we'll add the TabControl itself, then add two tab pages, one each for the Instance and Class views.
To start, we'll just add the TabControl itself. We really have to go and re-edit our our createInterface method because we don't want the Protocol and Method lists in the main window anymore... they'll be hosted later in the TabControl tab pages. And once we do that, we have to basically comment out our hookupInterface method, because otherwise it'll do stuff we don't want it to do for now. We'll hook up everything as we move along.
First, I took all of the ListBox code and factored it out into it's own method for now, named addProtocolAndMethodPanes. I added my TabControl to the end of the createInterface method:
The above is published as version 1.15 in the Package named "PollockBlog" on the Cincom public repository.
If we open it now (ClassHierarchyBrowser open), we get a fairly useless looking thing. We can resize the individual panes, but the TabControl has no tabs, and no matter what we select in the Class tree, nothing happens.
Don't forget... use the newest version of Pollock from the Cincom Repository: Version 5.32
In Pollock, there are several ways to add Tab pages to a TabControl. For now we'll just concern ourselves with the ones that are 100% code... those that don't depend on any spec objects. The API we'll be using is:
It should be pretty obvious what "aStringOrText" is, but we haven't yet talked about the Form pane. In Wrapper, there is this thing called a "SubCanvas" in which you can host a whole "sub user interface" and a bunch of other things... but the Pollock Form is really only a simpler cousin to the "SubCanvas" so let's not compare them here.
The Form is concepturally very much like a UserInterfaceWindow, except without any window borders or buttons or title bar or support for menu bars or toolbars, and not able to open itself.... Hmmm, so much for being "Like" a window.... But, really folks, thinking of it as a "Sub-Window" does work... It can hold other panes, and also able to be reused and added multiple times to a Window or another Form.
In our case, we'll create two Forms. Will give each one two list boxes (one for Protocol one for methods), and then pass them in, one at a time to the #addPage:label: method. Here's how we'll change the #createInterface method:
Note, I'm using the same form twice. In fact, as we see below, I'm really creating two instances of the same form... but they'll have the same widgets, with the same IDs. We'll show how that works next week. For now, we have to add our protocolAndMethodListForm method:
Before I go on and explain some of the interesting things, let's finish up the GUI portion of this week's work. If you open our ClassHierarchyBrowser now, you'll see that while nothing is hooked up, the TabControl has no active page. This is how it works by default. So, to make everything pretty, we'll create our on runInterface method... the last method called in a UserInterface's startup sequence, and add a bit of code to make it activate the first tab:
runInterface
| result |
result := super runInterface.
(self paneAt: #Tab) showPage: 1.
^result
Now if we run the result, everything looks fine GUI wise... but of course, it is all pretty much inactive.
The above is published as version 1.16 in the Package named "PollockBlog" on the Cincom public repository.
Now some notes on the Form and Tab code up there. First, you'll notice that the ListBoxes are all laid out in FractionalFrames, but they are using left/right fractions of 0.5 and up/down fractions of 1 and 0. This is because when you lay things out in a Form, you lay them out relative to the Form itself, not according to their eventual position in the hosting window (or Form... yes, you can nest Forms in Forms indefinitely).
Next you might notice that while the ListBoxes on each form have the same IDs, I was still able to put a ResizingSplitter between them using their local names. This is because a ResizingSplitter only knows how to do it's thing on panes that are siblings of the ResizingSplitter itself. In this case, the two instances of the Form are in effect detached from each other. Being hosted themselves as pages in a TabControl makes them not even siblings. The only siblings each ResizingSplitter can see are those in the Form itself.
Finally, you can probably surmise that there is a simple API on the TabControl that allows you to show pages. Right now, it only works with integers. In the future, probably before Production 1 is complete, it will allow you to give pages IDs and then manipulate them by ID instead of just, in effect, the index.
That's all for today. Next week I'll fill in our currently commented out #hookupInterface method, and get the whole shebang working again
Previous Topic
