Request: Only editing a member (no namespace/class visible)

SyntaxEditor .NET Languages Add-on for Windows Forms Forum

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Feature Request Overview

Several customers have requested a feature where you would be able to specify a "header" and "footer" section of code that would not appear within the editor but would provide IntelliPrompt while editing.

So for instance, the parser would "think" you are editing this:
using System; 
using MyNamespace; 

namespace MyScripts { 
 void OnChange() { 
  // some more user code here 
 } 
}
When in reality, the only thing the end user sees in the editor is this:
void OnChange() { 
 // some more user code here 
} 
Possible Solution #1

Add a HeaderText and FooterText property to the Document that is normally ignored. The semantic parser would have to be able to examine Document.HeaderText + Document.Text + Document.FooterText and adjust all its offsets by subtracting out the length of the HeaderText since that should be invisible to the end user.

Design problems with this implementation include:
1) Outlining (since it is based on the AST) will show containing namespace/class indicators. Would require some sort of workaround.
2) Error indicators that should be inserted in the header/footer regions would have to be filtered out.
3) Type/member drop-down list could not be used since it would show items in the header/footer regions. But in this scenario this is probably a non-issue.

Possible Solution #2

Add a mechanism to support hidden regions of text with SyntaxEditor. Place the header and footer text within hidden regions.

Design problems with this implementation include:
1) Line numbers will be off, but maybe could be corrected by using the Document.AutoLineNumberingBase property.
2) Auto-indent will be off since there will be { characters in the header text.
3) Outlining (since it is based on the AST) will show containing namespace/class indicators. Would require some sort of workaround.

Let's Get Your Feedback

Which solution do you think is better? And do you foresee any other issues with implementation of either? We think #1 would be easier to implement for this scenario. Let's hear from you!


Actipro Software Support

Comments (10)

Posted 13 years ago by Jake Pearson - Software Developer, Alion Science and Technology
Avatar
Solution #1 seems simpler for me to use. I basically just set the header and footer and I am done. Temporarily, I have my SyntaxEditors doing this with the header/footer code showing and it is pretty simple. I'm not sure what you mean by 1.3. Will intelliprompt not work if you implement this?

I'll give you an example of Intelliprompt filtering. Let's say the code of the syntax editor is something like this (with comments indicating where the header and footer is):

//Begin Header
namespace Foo
{
   class Bar
   {
      [IntellipromptHide]
      public string MyString;
      public int MyInt;

      public void Goo()
      { //End Header
         this.
        //Begin Footer
      }
   }
}//End Footer
When the user types "this." Normally you would see MyString, MyInt, etc...
But maybe I could put an attribute on one of the fields so the user wouldn't know it existed like what I put on MyString above.

Or another solution would have you add an event to the TypeResolver or whereever you think would be best that would get fired before the intelliprompt got displayed. It would pass on the name of the class and a list of all the items that would be displayed. You could add a Visible property to IntelliPromptMemberListItem that would allow me change which items would be shown. I think I prefer this solution, mostly so I can hide GetType and GetHashCode from classes.

Please let me know if I'm not being clear.

thanks,
Jake

[Modified at 10/12/2006 10:03 AM]
Posted 13 years ago by Ricardo Goncalves
Avatar
Hi, I would like to do something like that, but how i define a header and a footer?

I searched the help and didn't find nothing...


Thanks,

Ricardo
Posted 13 years ago by Alex
Avatar
I also vouch for this feature – it will be a great usability improvement in my application. As far as implementation, I think that option # 1 is easier to use.
I addition, I would like to have more control over the IntelliPrompt. Ideally it would be great to combine easy of use IntelliPropmt in AddOn with extensibility of SyntaxEditor,
There are some features I really miss.
1. When I use DotnetResolver.AddAssemblyReferece ( or LoadForXXX) I would like to specify a callback with can allow me to filter out some types. In any real case scenario (except of pure Visual Studio), an assembly contains many types that average user of application shouldn't see.
2. I also would like to be able to modify the IntelliPromptMemberList on a fly and to add/remove some members to it (as a previous user proposed)

Thanks
Alex
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Ricardo, sorry but the header/footer feature isn't implemented yet. This thread is to discuss how to implement it.

I started seeing how hard it would be to do #1 and ran into some snags. Then I had a brainstorm of a solution #3 which might be much better overall.

Possible Solution #3

Change Document.LanguageData so that when using the add-on it stores a new DotNetLanguageOptions type instead of DotNetProjectResolver directly. This new DotNetLanguageOptions type would have additional post parsing options.

The general idea would be that the fragment of code in the document would be parsed into an AST, and then merged into a predefined compilation unit that you already parsed. The "parent" compilation unit would be defined in DotNetLanguageOptions and we'd have to indicate what parent AST node in that compilation unit would get the stuff that was parsed from the Document.

So DotNetLanguageOptions would probably have members like:
- P:ProjectResolver (DotNetProjectResolver class - what is currently in LanguageData)
- P:DocumentContext (DotNetDocumentContext enum [CompilationUnit, StatementCollection, etc.] - basically what the code in the Document is)
- P:MergeParentAstNodeList (IAstNodeList - the AST node list that the AST node generated from the Document's code will be inserted into... so this could be like a method's statements collection)
- P:MergedCompilationUnit (CompilationUnit - the result of the merge... used only for reflection)

Then when the semantic parse of the Document completes, it looks at the options and if a MergeParentAstNodeList was specified, would merge the AST representing the Document code into MergeParentAstNodeList and take the root node of that and make that the compilation unit stored in the MergedCompilationUnit property.

Design problems with this implementation include:
1) Type/member drop-down list could not be used since we would be using this to parse statements, so in this scenario this is probably a non-issue.
2) Would probably need to implement a blocking parse call to parse code (for the header/footer) into a CompilationUnit. Then the appropriate IAstNodeList can be set to the MergeParentAstNodeList property in the options.

Brainstorm on this idea and post back what you think.

Reflection Request

I've added the request for a type reflection filter (when building the cache) and a member list item filter to the TODO list.

How would you like this done... like do you want to be able to override a method on DotNetProjectResolver to filter stuff out for the member list items?


Actipro Software Support

Posted 13 years ago by Alex
Avatar
Quote:

Reflection Request

I've added the request for a type reflection filter (when building the cache) and a member list item filter to the TODO list.

How would you like this done... like do you want to be able to override a method on DotNetProjectResolver to filter stuff out for the member list items?

Frankly speaking, I don't like to have to override this function. The logic for this function can depend on the execution context and I don't want to passs this context to the DotNetResolver.
What about event or even better aa callback delegate as a method parameter,like this

public delegate bool TypeFilterCallback(Type type);
public void AddExternalReference(Assembly assembly, TypeFilterCallback typeFilter); 
On another subject - some time ago we discussed the possiblity to create a CodeDomCompilationUnit from the AST context. Is is also in the TODO list?

Thanks
Alex
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
The member list filter question was for filtering member list items, which is a different feature request than the filter for types.

For types, I agree with you... probably passing a delegate is the way to go. Or maybe an interface (which would enable future support for member filtering, etc.)?

So I'd still like to hear thoughts on the member list item filtering.

As for the CodeDOM conversion, we are so swamped with work right now. Especially working on a VB language for the add-on and a couple other things. If you need that, you're probably better off working on it yourself since we have a lot of things on our plate that are higher priority. It is on the TODO list but it's near the bottom. Sorry, there just aren't enough hours in the day. :)


Actipro Software Support

Posted 13 years ago by Jake Pearson - Software Developer, Alion Science and Technology
Avatar
Method #3 sounds like it would be more flexible than what we were talking about before. It it is easier for you to write then go for it.

For filtering, setting a delegate seems like a good solution to me. Or you could make an event instead for applications that allow plugins.

thanks,
Jake
Posted 13 years ago by Jake Pearson - Software Developer, Alion Science and Technology
Avatar
Hi,
Do you have an estimate on when this will be implemented?

thanks,
Jake

[Modified at 10/25/2006 02:09 PM]
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Working on it... have been retrying to implement option #1 and are having more success this time around. Should be able to post more progress info tomorrow or Friday.


Actipro Software Support

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Got it! Option number 1 is completed, since it is the easiest for the end user (you all) to work with. You just set the new Document.HeaderText and FooterText properties and you are done.

We've even added a new QuickStart to demo this functionality. It will be included in the next maintenance release.

Jake, if you want to help test it out now send over an email.


Actipro Software Support

The latest build of this product (v2020.1 build 0400) was released 7 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.