variable declared as "shared friend" in VB.NET.
That's where you're wrong. public variables are variables with a global
scope.
As I read id I assume that you've compiled the VFP DLL ad a MT DLL?
That is generaly a good idea in aspect of performance, but this is actually
creating the problem you have. when you compile the dll as a single threaded
DLL, each instance of the COM-objects has its own VFP environment thus
giving you the behaviour you expect BUT in my opinion that's not the way you
want to do it because this can give you big problems in scalability and
performance.
A better way to make your COM-object have it's local 'public' variables
(like a 'shared friend') is to use a property on the COM-object.
> I cannot change the way our VFP "public" variable is accessed (ie.
> THIS.gcString), but I can change the way it is declared (ie. some way
> of declaring it with the .NET equivalent of "friend", but not
> "shared".)
> Hi Brian,
> There are a couple of things that strike me in your post, but first to give
[quoted text clipped - 4 lines]
> That's where you're wrong. public variables are variables with a global
> scope.
I assumed it was "shared friend" because when I compiled the VFP DLL
twice, as projects with different names, (and therefore in different
INTEROP namespaces), there was no overlap. But, I think that may just
be a difference in our view of what constitutes an environment and is
not that important.
> As I read id I assume that you've compiled the VFP DLL as a MT DLL?
> That is generaly a good idea in aspect of performance, but this is actually
[quoted text clipped - 3 lines]
> want to do it because this can give you big problems in scalability and
> performance.
Actually, the VFP _IS_ compiled as a Single-Threaded DLL, which still
is giving us the overlapping environment problems.
> A better way to make your COM-object have it's local 'public' variables
> (like a 'shared friend') is to use a property on the COM-object.
[quoted text clipped - 13 lines]
> it?) it's a good idea to use it as a baseclass for your OLEPUBLIC classes
> because it gives each object it's own datasession.
I think instantiating the class as derived from the VFP Session class
is the way to go (at least with regard to keeping cursors from
overlapping). But, we still have a problem with global. What we have
decided to do to get around that is declare them instead as "PRIVATE"
which is available in methods called from whatever method the
"PRIVATE" variable is declared. Of course, this will involve some
rewriting of our higher level functions, but is much more desirable
than rewriting all of our code to use properties. (We have many other
classes insantiated that refer to several PUBLIC variables and it
would be a MAJOR undertaking to change them all to receive properties,
something I did not show in the simplified example I included).
I DO wonder why the Single-Threaded DLL seems to share a session
between the VFP objects instantiated in different (STA) threads.
> HTH,
> Sietse Wijnker
Brian Levitan - 28 Jun 2004 20:33 GMT
> > As I read id I assume that you've compiled the VFP DLL as a MT DLL?
> > That is generaly a good idea in aspect of performance, but this is actually
[quoted text clipped - 6 lines]
> Actually, the VFP _IS_ compiled as a Single-Threaded DLL, which still
> is giving us the overlapping environment problems.
...
> I DO wonder why the Single-Threaded DLL seems to share a session
> between the VFP objects instantiated in different (STA) threads.
After much further testing. I've observed that EXACT OPPOSITE
EFFECT that regarding the environments of Multi-Threaded vs.
Single-Threaded DLLs. That is, MT DLLs have a separate environment
for each instance declared in .NET (and therefore no PUBLIC var
overlap), Single-Threaded DLLs HAVE overlap. All I had to do to get
my app working was work through a few other MT DLL issues.
The session variable stuff did work though. (Not that we will need
it for an MT DLL).