>Sergio,
>this is what my update was about.
>
>But there is reason for the way it it. The methods in the listener are called over and over (imagine a 2000 page report that is 75% black). So calling this and that what could be done strait will considerable slow down.
>Anyway, I say that one need to know what one is doing. (I found some code where somebody didn't know just in the morning. ::))
>
>Personaly, I didn't see why they need those extra datasession, it would be much simpler and faster if they would stay within the one with the data. But again, there might be reason I do not see now.

You might have got me wrong Agnes :)

Aldough I never do it, I have no problem with ad-hoc changing session grabbing some info and then immediately returning back to original session. In listener case it could be that this sort of activity is going on lower level from within engine
(Hence having methods like .setFRXDataSession() and .ResetDataSession()) then in a subclassing you are really on a sort of 'thin ice' if anything goes wrong. Somewehere inside current session got changed, then boom some event happen and,or error occur, and there you are left in limbo with dangling datasession.

As for possible overhead;
There is already an extra data session having frx table open, it is just that is not created as accesible object (Session Object) making exchange of info between sessions 'safe' as ordinary object to object communication is.
Additional accesible session object with frx data might look like overhead
but would provide additional level of insulation here and made listeners subclassing more safe.

Again just my opinion :)

>
>But if you realy didn't like it, feel free to rewrite. ::)

Good that at least listener is now an object, so you can at least have some say in it. Unlike before when RE was monolitic black box.

>If you didn't have time to it, check the chatter forum. Some people there working not to there capacity.

This is beyond OP problem, so it is deviation to thread
or chatter if you want. I hope I don't get into trouble <vbg>
I am kiddin' of course :)