Silverfrost FTN95 and .Net Generics

Hello,

I am working on upgrading a FTN95 console application to a GUI application, so my basic plan of attack is to turn the FTN95 application into a DLL and reference it in a .Net 4.0 project.

This application used to read in large XML files and use the data as its paramaters, however I am now looking at using LINQ-XSD and passing the resulting class directly to FTN95 and having it parse the data in the class in memory instead of reading a file.

Can anyone tell me about issues I might run into with this approach?

However when I pass this class directly to FTN95 there are some issues with generic type arrays for example (List<T>), where whenever I try to access their members in my FTN95 the compiler simply throws an error and says the field does not exist.

Is there anyway to use generics in FTN95 code.. ambiguously?

Also I was wondering what the easiest way to parse a .Net array in FTN95 is? and if it is possible? If not would creating a .Net extensions library for FTN95 to use be a recommended solution? And could I use a .Net extensions library to throw detailed exceptions from within FTN95 code?

Thanks, Alex.

UPDATE: I ended up using non-generic arrays on the .NET side which can be more difficult to work with and may result in some memory pressure when converting these arrays to dynamically sized ones so this solution is not ideal and can add unexpected performance pressures when trying to integrate with an FTN codebase.

Why did I never get a reply to this? It is not mentioned in the documentation and is a real stuff around for anyone just expecting .NET integration to work in any normal fashion.

My .NET FTN95 and C# skills are a little rusty. The only thing that I can suggest is that if FTN95 is failing then you could try posting a simple demonstrator and ask for it to be fixed.

The only general point that I would make and may be relevant is that parts of .NET FTN95 use salflibc.dll so in this sense .NET FTN95 is not portable to other operating systems.

Quoted from PaulLaidler My .NET FTN95 and C# skills are a little rusty. The only thing that I can suggest is that if FTN95 is failing then you could try posting a simple demonstrator and ask for it to be fixed.

The only general point that I would make and may be relevant is that parts of .NET FTN95 use salflibc.dll so in this sense .NET FTN95 is not portable to other operating systems.

Thank you for your reply, I have included code in this post: https://forums.silverfrost.com/Forum/Topic/3578

It is hosted in a public github repo so you should be able to download/view the code from the browser.

alex21

I was thinking of something simpler and more direct. It would take me at least an hour to identify the issue from all of this information.

There isn't any support for generics in FTN95

Quoted from Robert There isn't any support for generics in FTN95

Is this stated anywhere in the documentation? I found this page: https://www.silverfrost.com/ftn95-help/netprog/supportedfeatures.aspx

But all the links at the top are broken, but it says that generic names are supported for arguments and interfaces whatever that means...

Essentially what is the difference between a generic type and a non-generic type that makes it different from any other type? It really seems like a naming thing because I have updated my example on github to show simply giving a generic type a concrete name compiles fine, so what is it about long random ass generic type names you can't support? Because in a project with a .NET domain where I can't go in and wrap every generic type with a concrete name, its not practical and reflection has performance issues that I should be able to avoid...

! 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

    ! But simply wrapping the generic type, which is essentially just a type with a really random name (is it some kind of naming issue?!) 
    ! given the concrete name of StringList... will compile... so generic type names are not supported why?
    c = dataType%WrappedDataList%Count




public class DataType
    {
        public List<string> DataList
        {
            get;
            set;
        }

        public StringList WrappedDataList
        {
            get;
            set;
        }

        .....

        public DataType()
        {
            DataList = new List<string>() { 'hello', 'this', 'is', 'a', 'test' };
            WrappedDataList = new StringList() { 'hello', 'this', 'is', 'a', 'test' };
            .....
        }
    }

https://github.com/alexhopeoconnor/ftn_generic_collections_example

I need to have a look at it again.

Quoted from Robert I need to have a look at it again.

Thank you, will improve performance/remove boilerplate requirements in some of my projects and let me know if I can help but giving any more examples or anything.