In short, yes I encounter this issue all the time (I like to create private sessions to encapsulate data usage). And there are basically two approaches that I use, both of which follow along the lines that Arquimedes describes.
1) you could replace your "goString" global variable with a "GoString()" factory which returns an object instantiated in the current datasession. I probably use this model the most since it means I don't have to fuss too much about datasessions. And I can scope the object however I want, I can use it as a property of a class or as a single-use local object.
LOCAL loString
loString = GoString()
loString.DoTheThing(myString)
2) you can pass the datasession in as an optional parameter in the method call.
DEFINE CLASS goString AS Exception
PROCEDURE DoTheThing(tcString,tnDatasession)
LOCAL lnOldSession
lnOldSession = SET('Datasession')
IF !EMPTY(tnDatasession)
SET DATASESSION TO (tnDatasession)
ENDIF
...
SET DATASESSION TO (lnOldSession)
ENDPROC
ENDDEFINE
There's no way to turn this behavior off, unfortunately
> In short, the instantiated objects "remember" what DS was active when they were instantiated, in my case this is the default global DS, let's just say DS1, because they are instantiated when the application is launching, before the user has started doing anything which would cause the application to make a new DS. If the user then opens a form which has it's own DS, let's say DS2, the code on that form will have DS2 activated at runtime but if the code on the form calls any methods on the helper objects the active DS is changed from DS2 to DS1 for the duration of that method and then back to DS2 when the code return back to the code on the form.
>
> That behaviour is not totally unexpected, I seem to recall seeing something about that on a Fox Wiki somewhere but I don't recall if it's in any of the official documentation. It's not a huge problem it just makes things awkward, if the method on the helper object is specifically trying to do something with open tables/cursors for the form, then when the code runs it'll find itself "in" the other DS and might not be able to find the expected aliases. I could identify which methods could be impacted by "wrong DS issues" and have those methods accept a new parameter to have the DS number passed in, so the method can ensure it switches to that DS but that will involve a fair amount of refactoring of existing code so it's definitely not ideal.
>
> I could knock this idea of private DSs on the head and maybe even the idea of making the MDI but that feels like a cop-out. Has anyone else had an similar issues with using global helper objects (either as global variable or properties on the _SCREEN - behaviour is the same either way) while also using private DSs? Did you tackle it by passing the DS number into routines as a parameter or did you have some other way of working around this behaviour? Or is there anyway of stopping the objects from "remembering" and "switching" DS? I get the behaviour of a form that has been set to Private Data Session remembering it's DS but these helper objects don't have any such property, they are just doing it themselves.
>
> TIA
>
> Paul