Re: [FlaconJX] problems with class references

> > Not sure what you mean by "importer classes have namespace declarations". > What does that code look like? This: internal class BaseTextLayoutImporter extends ConverterBase implements ITextImporter { private var _ns:Namespace; // namespace of exp

Re: [FlaconJX] problems with class references

On 3/9/17, 12:33 AM, "Harbs" wrote: >I have already removed tlf_internal from the entire code base. > >I’m not sure where the QName is coming from. The importer classes have >namespace declarations, maybe that’s throwing a spanner into the works? Not sure what you mean by "importer classes hav

Re: [FlaconJX] problems with class references

I have already removed tlf_internal from the entire code base. I’m not sure where the QName is coming from. The importer classes have namespace declarations, maybe that’s throwing a spanner into the works? I don’t see this as a very high priority issue if simple cases work. > On Mar 9, 2017, at

Re: [FlaconJX] problems with class references

I can't seem to reproduce this in a small test. In theory, the only code that outputs "new QName" would be in response to a namespace token like mx_internal::someProperty. I see in original TLF code the call has "tlf_internal::description", but in your example, it is just "description". Can you d

Re: [FlaconJX] problems with class references

It appears there is more to it. The class that owns memberType also has a tlf_internal::description field which is confusing the fetching of memberType.description. Are you going to be leveraging tlf_internal namespaces in the port? That hasn't been fully debugged and will not generated small co

Re: [FlaconJX] problems with class references

On 3/8/17, 2:48 AM, "Harbs" wrote: >Please look at this paste: >https://paste.apache.org/JfGh > >Changing the type of memberType to “*” resolves this issue for me, but >the question is whether this is a bug which should be fixed, or a >limitation that requires a