Standard Collection Editor with prefixes per collection element

Interestingly there is a bug in that separator query i mentioned above. 

To that separator query a "node" is passed. During runtime, this is the pervious collection element rendered, in the inspector window, it s the concept containing the collection. In my example, the InstanceMethodCallOperation ....   

Hi,

I've overridden some of the default editors in my "MPS extensions" project once. I added something similar you are asking for for argument lists that have more than two arguments:

Layout is a bit different then what you want, but you can still have a look at the project here: https://github.com/digital-ember/digitalember.extensions

The way I did it you can find in the overriden editor component IMethodCall_actualArguments for the "actualArguments" ref node list by providing a conditional styling (if there are more than two arguments). I cannot tell you off the top of my head if the same would work for your preferred layout, since styling is often a trial and error approach to me...

Hi Robert,

thanks for your comment - i just had a look at the repo. I m familiar with MPSs editor hints. However, i m still hoping that i do not have to overwrite all editors of various available expression concepts in baselang, just to get this feature implemented. 

Let me add at this point, that i m not using the InstanceMethodeCall directly but MyMethodCall which is almost a copy of InstanceMethodCall. I do also reference InstanceMethodeDeclaration. So i can provide my own Editor for the MyMethodCall.... i did not mention this in my original post. 

So basically i m looking for an editor for my MyMethodCall concept. Right now, i don't have n idea..... 

Well, if you already extend InstanceMethodCall, you might as well also extend the interface IMethodCall and override the editor component IMethodCall_actualArguments.

It was relatively easy in the end to adjust the styling so that your preferred layout applies: 

Be aware that, in any case (introducing your own extensions by means of sub-concepts or by means of using editor hints), your editor will likely lose some of the build in functionality of the base editor (like action maps, focus policies, etc.). You can copy the exisitng implementation and adjust it to your needs, but changes to the base editors will, in many cases, not be reflected in your sub-editors.

I would have to look a bit closer into how to add argument labels as well. Is it a must have for you?

This should be all the changes you need to get above layout (i.e., there is no need to touch Expressions):

Hi Robert,

thanks again for your quick response. As stated in the intro post, the prefix for each collection element is the problem. not the new-line on indent-layouts. 

You could try it programmatically (sorry for not reading your initial post closely):

Nice, this might be exactly what i was looking for ! 

Is it still editable with this approach? I.e. can the user still add a param4 in case a param4 is requested by the declaration? 

Amazing !! 

The example certainly lacks different desirable usability aspects. It was just ot give you an idea how you might be able to get the argument name along with your parameter w/o caring about what your parameter actually is. This solution has many drawbacks since the cells are created programmatically. You want to look into the reduction rule for CellModel_RefNodeList as inspiration how you build these editor cells (e.g. the separators) in a way the usability is good: http://127.0.0.1:63320/node?ref=r%3A00000000-0000-4000-0000-011c8959029f%28jetbrains.mps.lang.editor.generator.baseLanguage.template.main%40generator%29%2F1106598080605870079&project=digitalember.extensions

I cannot add new parameters with above solution by pressing "Enter" or typing in a separator, for example, but the parameter cells themselves are fully functional as one would expect.

Okay i will probably have an in detail look into programmatically creating editors ... 

Of course, another option is using r/o access and fabricating that look, which is very simple. however, this solution won't be editable as well.. 

Cheers  and thanks for your support....  

Almost there, almost there.

However, when inserting a new argument, the code completion does not show up. Thus, it s not possible to change the <actualArgument> (expression) to something meaningful (e.g. VarReference)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Im using an abstract cell provider, like Robert suggested.

which in turn uses my OperationCallArgHandler()

Any Hint what i could try ?? Or some experiment to dive more into the problem? 

Daniel

The SubstituteInfo delivers the entries for the code completion menu. You can use the Cell Explorer (Language Debug > Show Cell in Explorer) to check if there is a substituteInfo set on cell and if it is the correct one.

Thanks Sascha,

i thought that you might be the right one to ask! Indeed the substituteInfo was missing. I forgot to set it explicitly for the editing cell itself ... 

Cheers .... :)