Hyperion Entertainment Message Boards

I'd like to make a small customization to the Reaction ListBrowser by subclassing
(to track the GM_GoActive messages) and as a first step I wrote a Boopsi private
class whose Dispatcher simply calls IDoSuperMethodA() for every incoming message.

I expected that using an object of my subclass would then behave exactly like the
Reaction ListBrowser. But it does not behave exactly.

This is the ListBrowser on AOS 4.1 upd 6 and public SDK 53.20.

The subclass does mirror the ListBrowser behaviour except for the use of the
V or H scrollers that are part of ListBrowser. It seems to have lost the refreshing
of the browser display itself in response to the scrollers. The first click on the scroller
usually does refresh the browser list displayed, but after that little or no refreshing
of the browser list occurs with scroller movement. (However forcing a refresh
by moving the window behind another one and then back to the front shows
the proper list display).

It sounds like this has something to do with OM_Notify. Does anyone have an
explanation?

Thanks,

Tom

In case someone finds this in a search, I'll followup myself:

I found that I could restore the display refreshing w/r/t the ListBrowser scrollers
by having my subclass explicitly call Intuition^.DoRender() whenever it receives
an OMUpdate message in the handler.

Unfortunately, other problems with my "null" subclass showed up
- A system hang whenever the column dividers were moved.
- Loss of any response of the gadget to the mouse wheel.

Considering no response and do docs, I interpret it to mean that
subclassing a Reaction gadget is not really supported - somewhat
defeating the Object Orientation of Boopsi

I'm now trying a Reaction IDCMPHook, which does seem to be
a reasonable way to get the GadgetDown.

Tom

Original question:

tbreeden wrote: I found that I could restore the display refreshing w/r/t the ListBrowser scrollers
by having my subclass explicitly call Intuition^.DoRender() whenever it receives
an OMUpdate message in the handler.

For OM_SET and OM_UPDATE messages you should check the return value from IDoSuperMethodA() and if it's non-zero you should call DoRender(). The listbrowser.gadget doesn't do this if it's called from a subclass to avoid multiple refresheses being done by itself and subclasses.