Replacing ABT notebook with Windows tabstrip

[Bob Whitefield]

I'm trying to find a way to replace a portable notebook control (AbtPortablePMNotebookView or AbtPortableWinNotebookView) with a native Windows tabstrip (AbtCwTabStripView).

Ideally morphing into the native control would be supported. Has anyone modified AbtNoteBookView>>abtMorphMapAt: to support AbtCwTabStripView, and if not, is that something I could/should pursue? Is the morphing mechanism documented anywhere?

I could easily make the required changes by editing #abtBuildInternals but the composition editor seems to be a one-way street. I first tried filing out the class with an edited #abtBuildInternals, and filing it back in, but then CE showed only a blank window. Is generating archival code and then editing that worth pursuing?

<curmudgeon>
I've built tabstrips at the common widgets level, but have little experience with the arcana of VA parts. Just curious: what purpose does #abtBuildInternals serve--is it there simply to taunt me? It's frustrating not having all code available for editing--I seem to recall that being a fundamental principle of the Smalltalk language.
</curmudgeon>

The only other option I see is manually recreating the GUIs, a tedious process given the number of notebooks, tabs and connections involved. Am I missing something obvious?

Any suggestions?

Thanks,
Bob

[tc]

Hello,

I'm having trouble following, did you create AbtCwTabStripView? I ask that because I do not see it in my image.

I threw a win notebook on a window in the composition editor and looked at the abtBuildInternals to see what is generated. It used two classes:

AbtPortableWINNotebookView
AbtPortableNotebookPageView

. . . when you say you edited the abtBuildInternals method, what did you change those classes into?

--tc

[Bob Whitefield]

Taylor, thanks for the quick reply. You need to load feature VA: Windows Controls to get class AbtCwTabStripView.

In the abtBuildInternals method, I replaced AbtPortableWINNotebookView with AbtCwTabStripView, AbtPortableNotebookPageView with AbtCwTabView, and methods pageLabel:/tabLabel: with labelString:. Changes were also required for page change events in the notebook page classes.

Bob

[tc]

Hello,

I see what you did/doing. If you were to change abtBuildInternals, how many methods would need to change total?

--tc

[jtuchel]

Bob,

I am not aware of any documentation of abtMorphMapAt: or AbtIsomorphicFeatureMap and AbtIsomorphicClassMap.
You will probably not find any more than what you can learn by reading AbtPartBuilderMorphSubparts>>#primitiveExecute...

I see some possible probloms with what you want to do - although I'd like to see a solution for this as well, especially for projects which plan to ship on Vista in the near future...

AbtPortableNotebook supports some events that are being used quite a lot like #aboutToBeSwitchedTo and friends. These are not supported by TabStrips. So no matter if you use abtBuildInternals or the (undocumented) Morphing support, you'll have to find solutions for these differences as well.

The better solution would surely be if Instantiations made AbtPortableNotebookView a wrapper around more or less native notebook implementations, including Tab Strips on Windows, handling these differences by delegating to the real parts. In my naive picture of the AbtLayer and with my understanding of VA Smalltalk's GUI philosophy, that would be what AbtPortableNotebookView should be all about.

Let's call my posting an official feature request

Joachim

[Bob Whitefield]

Taylor,

If you were to change abtBuildInternals, how many methods would need to change total?

Not sure exactly what you're asking, these are the changes I see:

classes
AbtPortableWINNotebookView -> AbtCwTabStripView
AbtPortableNotebookPageView -> AbtCwTabView

page/tab methods
tabLabel: -> labelString:
pageLabel: -> (not available, omit)

notebook/tabstrip events
currentPage -> currentTab
aboutToChangePages -> (not available, omit)


Joachim,

I agree entirely that native Windows widgets should be wrappered properly, but that's a tall order, I was looking for something much simpler.

<soapbox>
It's possible to create GUIs in VA Smalltalk that avoid all the OS/2-era controls, but it's a lot of work, fighting the tool all the way. And sadly, there is no alternative to EwTableList. Support for the native Windows table control, ListView, is at the top of my wish list. I have extended EwTableList many times to add sorting and filtering controls, make its appearance better match XP, etc. If ListView was supported, we would get those features for free and wouldn't have to keep chasing Microsoft's fashion trends in widget appearance.
</soapbox>

Having said that, all I want right now is a way to replace portable table controls that doesn't require me to recreate each GUI manually. If I was working at the Common Widgets level, or using WindowBuilder, I could modify the code directly, but VA parts don't seem to allow that.

As for the absence of some events on CwTabStripView, I can easily work around that, it's the bulk of GUI creation I'm trying to avoid redoing manually.

Thanks,
Bob

[benvandijk]

Hi Bob,

The abtBuildInternals method is generated every time you save changes in the composition editor. It is used in a runtime image to build the gui and also in the development image when you use the "Test" button. The composition editor uses objects to show the gui.

You can use the "generate archival code" menu option in the composition editor to generate methods containing all info needed to build the objects.
Those methods can be changed and you can rebuild the object from the changed methods.

The archival methods and the rebuild methods are of course written in smalltalk so you can automate the process of changing notebooks to tab strips.

If you do so, i would be interested in the piece of code. I can envisage use of it in the future in our environment.

Greetings, Ben

[Bob Whitefield]

Ben,

Thanks for your reply, and sorry I didn't see it until now.

I found an old usenet post by Eric Clayberg that also provided the explanation you gave. This approach works, but is a huge pain.

My client decided not to convert their tab controls right now, so this is on the back burner now. When I need to do it in volume, I'll probably try writing the morphing code, if it's not a supported feature by then.

Bob