Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Dangling Datasession after Report
Message
From
05/03/2008 09:12:04
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
 
 
To
05/03/2008 08:59:55
General information
Forum:
Visual FoxPro
Category:
Reports & Report designer
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows XP SP2
Miscellaneous
Thread ID:
01298809
Message ID:
01298866
Views:
24
Sergio,

I think we talk more or less the same thing.
To me it looks like we could not express / read fine enough in english.

Never mind

Agnes

BTW:
The dangling datasession was not there because of an error (normaly the app would stop anyway), it was just because of bad reset.

>>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 :)
>
>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 error happens for any reason, and there you are 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 :)
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord

Weeks of programming can save you hours of planning.

Off

There is no place like [::1]
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform