Update on Indexers and Arrays

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA

Update on indexers/arrays. Non-generic indexers/arrays have now been implemented for both C# and VB and will appear properly in the next maintenance release. This is a highly requested feature so we're very happy to get it out to you all soon.

Generic indexers still won't work though because we are not yet parsing the types used to construct the generic. A sample scenario is in the previous post.

Actipro Software Support

Posted 17 years ago by Jake Pearson - Software Developer, Alion Science and Technology

Hi,
I think this feature has stopped working. I am using 4.0.0257 of Syntax Editor and entered "System.Collections.Generic.List<string> l; l[0]." into the .NET Language Reflection quick start and didn't see any intelliprompt drop down. Any idea?

thanks,
Jake

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Jake,

The add-on isn't resolving the generic item type yet per the original post. Thus generic collections will not have intelliprompt on indexers.

Indexers will work for regular arrays though, since that was completed several builds back.

Actipro Software Support

Posted 17 years ago by Jake Pearson - Software Developer, Alion Science and Technology

Thanks for the update, I misread the post above.

Posted 16 years ago by Reis - CA

Any update on indexers for generics? This post looks like a year old...

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Good timing, actually am working on it right now finally.

Actipro Software Support

Posted 16 years ago by Reis - CA

Great! Looking forward to it. Love the product.

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Generic types have now been fully implemented and IntelliPrompt should work properly with constructed types. This new functionality will appear in the upcoming maintenance release.

Actipro Software Support

Posted 16 years ago by Jake Pearson - Software Developer, Alion Science and Technology

Awesome, thanks!

Posted 16 years ago by JesperTreetop

Generic indexers don't seem to be entirely implemented. Using build 274, I can manage to get the correct type inferred in the tooltip, but the correct IntelliPrompt won't show up.

The inheritance looks like this:

public class BarSeries : BaseValueSeries<Bar>, IList<Bar> { ... }
public class BaseValueSeries<T> : IEnumerable<KeyValuePair<DateTime, T>>, IDictionary<DateTime, T>, IDictionary<int, T> where T : System.IEquatable<T> { ... }

BarSeries, the topmost class, overrides some virtual indexers.

Edit: To clarify, for a given object

BarSeries x

, if I type

x[0].

, I won't see any IntelliPrompt for the Bar type, even though the tooltip for x[0] recognizes that it contains a Bar object.

[Modified at 07/01/2008 02:55 AM]

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Hi,

Can you post a full code snippet that we can paste into our SDI editor that shows this happening? Thanks!

Actipro Software Support

Posted 16 years ago by JesperTreetop

I'm still working on trying to reproduce this in the SDI editor. When I pasted the classes into the SDI editor, it worked as expected.

By stepping into the SyntaxEditorIntelliPromptMemberListPreFilter event on CSharpLanguage, I managed to find out that in the SDI editor, where this works, the last of the Items in the Context has a ResolvedInfo of type PropertyDeclaration.

In our code, the corresponding entry (the last of the Items in the Context) is instead of an obfuscated type "m" that seems to carry references to the indexer (Public | Virtual modifiers, the string "Item" and a IDomTypeReference that seems to refer to an open generic type). This seems like an abstract superclass inside your code.

This doesn't help you reproduce the problem, but maybe it can give you some helpful clues while I continue trying to reproduce this inside the SDI.

[Modified at 07/01/2008 09:26 AM]

Posted 16 years ago by JesperTreetop

I've managed to produce a test case:

using System;
using System.Collections.Generic;

namespace TestCase {
    public class Bar { public decimal Foo; }
    public class BaseValueSeries<T> {
        public virtual T this[int x] { get { return default(T); } }
    }
    public class BarSeries : BaseValueSeries<Bar> {}
    class X {
        void Y() {
            // HERE
        }
    }
}

In place of the HERE comment, in method TestCase.X.Y, write

new BarSeries()[0].

While writing the indexer, the tooltip will correctly indicate that the returned object is a Bar object, but when you hit the period key, no IntelliPrompt will appear, at all.

(By the way: I noticed in reducing this test case that when an override in BarSeries akin to

public override Bar this[int x] { ... }

was in place, the behavior changed slightly and the return type was reported as "T" instead. I can't get it to do that with this test case however, so I'm not sure what triggers it, but it might be worth looking into as well.)

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

It looks like the problem is the "new" since right now the add-on doesn't yet process IntelliPrompt correctly on new expressions.

If you do it like this it does work, at least in our updated code here (which has a number of changes over the current official build you have):
BarSeries s = new BarSeries()
s[0].

Actipro Software Support

Posted 16 years ago by JesperTreetop

In that case, I may have inadvertently reduced it to a different bug. (In the original case, just storing it inside a variable and then using the variable's indexer is enough to freak out IntelliPrompt to the point where it doesn't get any info at all when you hit ".".) I will verify this later.

Posted 16 years ago by JesperTreetop

I have managed to reproduce the problem.

Edit: Try this code in the SDI, and it will work:

using System;
using System.Collections.Generic;
using B; // the types are all defined in this code sample

namespace TestCase {
    class X {
        BarSeries Create() { return new BarSeries(); }
        void Y() {
            BarSeries b = Create();
            b[0]. // <-- IntelliPrompt WILL be shown
        }
    }
}

namespace B {
    public class Bar { public decimal Foo; }
    public class BaseValueSeries<T> {
        public virtual T this[int x] { get { return default(T); } }
    }
    public class BarSeries : BaseValueSeries<Bar> { }
}

However, if you create a class library with just the following code (completely default, just replace the code in Class1.cs)...

using System;
using System.Collections.Generic;

namespace A {
    public class Bar { public decimal Foo; }
    public class BaseValueSeries<T> {
        public virtual T this[int x] { get { return default(T); } }
    }
    public class BarSeries : BaseValueSeries<Bar> { }
}

...edit the SDI editor to add a reference to this DLL (something like dotNetProjectResolver.AddExternalReference("A");), copy the DLL into the binary's folder and write the following in the SDI editor...

using System;
using System.Collections.Generic;
using A; // the types are all defined in the referenced assembly

namespace TestCase {
    class X {
        BarSeries Create() { return new BarSeries(); }
        void Y() {
            BarSeries b = Create();
            b[0]. // <-- IntelliPrompt will NOT be shown
        }
    }
}

...then IntelliPrompt will *not* work.

This definitely has to do with resolving types across assemblies.

[Modified at 07/02/2008 03:55 AM]

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Hi,

If you have the stub assembly already created, just email it over to our support address and reference this post. Thanks!

Actipro Software Support

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Thanks for the sample, this is now fixed for the next maintenance release.

Actipro Software Support

Posted 16 years ago by JesperTreetop

Awesome. Thanks.

I can confirm that this has been fixed in 275.

[Modified at 08/07/2008 04:30 AM]

The latest build of this product (v24.1.0) was released 2 months ago, which was after the last post in this thread.

Comments (19)

Add Comment