What I don't get about subs is TYPE is handled differently with SHARED than variables or strings. There is no reference to this in the Wiki about SUBs.
What you're seeing is what we've come to expect from any BASIC, Pete: Confusion over multiple variable types with the same name.
Take a look at the following, for example:
a = 3
Example
PRINT a
'And see the difference of the above, with what's below:
a$ = "Pete"
Example
PRINT a$
SUB Example
SHARED a AS STRING
a = "Hello World, " + a
END SUBIf you notice, SUB Example has a shared variable -- a. The main program also has a variable named a -- but it's a SINGLE and not a STRING, such as we defined our sub to use... We also have a$, which is the string variable a -- and it's the variable we're sharing information back and forth between the SUB and the main module with.
If we remove the second half of that code, the program STILL works as expected:
a = 3
Example
PRINT a
SUB Example
SHARED a AS STRING
a = "Hello World, " + a
END SUB
There's NO variable "a" in the code which is defined as a STRING, so even though we're changing it in the SUB, and sharing it in the main module, we're not doing a dang thing with it.
Want proof? Look at the following:
a = 3
Example
PRINT a
'And see the difference of the above, with what's below:
a$ = a$ + "Pete"
Example
PRINT a$
SUB Example
SHARED a AS STRING
a = "Hello World, " + a
END SUBThe first call to Example sets a$ to become "Hello World, " -- even though the main module hasn't had a single reference to a$ so far. The second call to the sub adds another "Hello World, " to the front of that string, and then adds a "Pete" to the end of it.
The value *IS* being shared -- even if we're not interacting with it, in the main program.
And how does this relate to what you're saying with TYPE?
It's the same thing; though with a minute twist.
Foo.x = 3
Foo.y = 4
PRINT Foo.x, Foo.y
Now,
What TYPE is Foo.x and Foo.y in the above??Being undefined as anything, they're both SINGLE type variables.
Foo.x = 3
Foo.y = 4
PRINT Foo.x, Foo.y
Example
PRINT Foo.x, Foo.y
SUB Example
TYPE FooType
x AS INTEGER
y AS INTEGER
END TYPE
SHARED Foo AS FooType
Foo.x = Foo.x + 10
Foo.y = Foo.y + 10
END SUB
And with the above, what TYPE is Foo.x and Foo.y?
In the main module, they're undefined, so they're *still* both SINGLE variables, while in the SUB, Foo is declared as a FooType and restricts them to being elements which belong to Foo.
IF you want to be certain that the information in Foo (from the SUB) is still there and available in the main module, look at the following example:
Foo.x = 3
Foo.y = 4
Example
M
= _MEM(O
, 4) 'A memblock starting at the offset for Foo from the SUB, and holding the next 4 bytes.
O
= _OFFSET(Foo
) 'The offset as to where our SUB is storing Foo at in memory. Foo.x = 123
Foo.y = 456
Notice that Foo.x and Foo.y in the main module never change -- we don't define them as being anything special, so they default to both being SINGLE variables. In the SUB, Foo is defined as being a FooType, so its values aren't going to match those of the SINGLEs in the main routine. The values *ARE* shared with the main routine -- as we can prove by using _MEM to looking in their memory address manually -- but we don't have any Foo AS FooType to interact with them with.
It's the exact same thing which we'd see in the following:
a = 3
PRINT a
Example
PRINT a
SUB Example
SHARED a AS INTEGER
a = a + 10
END SUBWe print 3, and then we print 3 again. We have an "a" in the main module, and we have an "a" in the SUB which we're sharing, but they're not the same variable -- they're not the same variable types at all!
If we want to actually share "a" in the SUB above, we'd need to have an INTEGER a to share it with:
a = 3
PRINT a
Example
PRINT a
COLOR 4
PRINT a%
SUB Example
SHARED a AS INTEGER
a = a + 10
END SUB
See what's going on with your TYPE? It's the same process -- it *IS* sharing the values with your main module. You're just not interacting with them, as your main module is using a different set of variables with the same name instead.
