Go Back

What is the Techincal Reason For DBL-E-IVBAD When Using a Complex Type Imported from C#?

When attempting to import C# Projects via the C# to DBLNET Conversion Tool (C# to Synergy DBL Conversion Tool):

DBL-E-IVBAD (https://www.synergex.com/docs/errors/comp/warn/compIVBAD.htm) will trigger on the following toy program:

C#

using System;
using System.Xml.Linq;

namespace StaticInitialValues
{
    class Program
    {
        static readonly XNamespace MyNamespace = "http://schemas.microsoft.com/developer/msbuild/2003";
        static void Main( string[] args )
        {
            Console.WriteLine(MyNamespace);
        }
    }
}

The Generated DBLNET Code
import System
.array 0
import System.Xml.Linq
namespace StaticInitialValues
    class Program
        static readonly MyNamespace, @XNamespace, "http://schemas.microsoft.com/developer/msbuild/2003"
        public static method Main, void
            args, [#]string
            endparams
        proc
            Console.WriteLine(MyNamespace)
        endmethod
    endclass
    main
    proc
        Program.Main(Environment.GetCommandLineArgs())
    endmain
endnamespace


Interestingly enough this example does not have the same issue (using a String) can someone explain why and point to the documentation that explains this?

C#
using System;
namespace StaticInitialValuesString
{
    class Program
    {
        static readonly string MyString = "http://schemas.microsoft.com/developer/msbuild/2003";
        static void Main( string[] args )
        {
            Console.WriteLine(MyString);
        }
    }
}

DBLNET
import System
.array 0
namespace StaticInitialValuesString
    class Program
        static readonly MyString, string, "http://schemas.microsoft.com/developer/msbuild/2003"
        public static method Main, void
            args, [#]string
            endparams
        proc
            Console.WriteLine(MyString)
        endmethod
    endclass
    main
    proc
        Program.Main(Environment.GetCommandLineArgs())
    endmain
endnamespace

Thank you,
Ace Olszowka

3 Answers
0   | Posted by Ace Olszowka to Synergy .NET on 11/5/2018 10:27 PM
Kish Baley
This:
static readonly XNamespace MyNS = "blah-blah";

is sugar for this:
static readonly XNamespace MyNS;
static Program()
{
  MyNS = "blah-blah"
}

By attempting to convert the latter, you get the more meaningful error DBL-E-TYPMISMCH (Type mismatch between @System.Xml.Linq.XNamespace and A...". There is no implicit conversion from Synergy A to XNamespace, however there is an implicit from string to XNamespace, so the following converted code works:
static readonly MyNS, @XNamespace, %atrimtostring("blah-blah")

It's important to note that 'string' constants (ie. "blah-blah") are technically alpha constants in DBL.

If the C# to DBL converter was modified to always add %atrimtostring() around C# string constants, then it should have prevented the erroneous IVBAD error.

 

11/9/2018 4:12 PM   1  
Ace Olszowka
Bug or no?

11/9/2018 9:40 PM   0  
Kish Baley
I would not consider this a bug. Adding %atrimtostring() around C# string literals DURING the conversion would take care of most cases where a framework class (other than Synergy .Net) expects a string, but there is a performance hit when %atrimtostring() is unnecessarily called in code. IMO, I'd rather not take the performance hit and resolve the issues that do arise from a missing atrimtostring(). Others may disagree.

FYI, this is NOT unique to the converter, I first found it with crafted code; the important thing to remember is that a literal string in Synergy source is an Alpha type and sometimes you have to wrap it in %atrimtostring() for classes that expect a string AND have no implicit alpha-to-string conversion.

11/9/2018 10:05 PM   1  
Please log in to comment or answer this question.