But still to this day my work around is not accessing booleans in a collection directly... as after posting an example showing the representation of booleans read from a .NET array were changing randomly because of how Silverfrost was reading the memory I never received a reply... That example project is no longer available as I did not maintain the dropbox account hosting it.

However I have grown increasingly frustrated with memory corruption issues in the .NET integration and have now noticed simply casting to value types actually pointed to by a collection/array is enough to run into this...

In FTN if we were able to access non-wrapped generic types directly the following would compile:

Code:

! Initialize the dataType
dataType = NEW@("Domain.DataType")

! Simple integration syntax won't work for generic types...... Won't even compile, need to wrap it as a non-generic type for it to work directly
! even though it implements non-generic interfaces (IList) with the same name as the member I am trying to access...
!c = dataType%DataList%Count

So really I think there must be an issue with the compiler converting .NET types to 'intrinsic' (am I using that right?) FTN types, possibly something to do with the number of bytes it is reading from memory at the address in some situations because of the way these types are represented in different circumstances on the .NET side.

Please let me know if you need any further examples of these problems with the .NET integration and accessing generics or type conversion resulting in memory corruption.