NinjaScript Editor Not Remembering Cursor Position

[jeronymite]

NinjaTrader 8.0.22.1 64-bit.

When using the NinjaScript Editor with multiple tabs, it seems that the editor does not accurately remember the cursor position in each tab.

This is what I experience:

• Edit in one tab (Tab1)
• Move to another tab (Tab2) and edit
• Return to Tab1 -- the cursor is still positioned in a location of several edits previously, not where the last edit left it

I don't believe it should be relevant, but in case it may be, these are all tabs editing AddOns.

Grateful for investigation.

Thanks.

[NinjaTrader_Jesse]

Hello jeronymite,

Thanks for the post.

I just wanted to post a quick note to let you know I will test this and report what I can to development. If I have further information I can provide here I will make another reply.

I look forward to being of further assistance.

[jeronymite]

Hi Jesse, I'm wondering if there is any progress on this. It continues to make editing (in my case, large AddOns) very frustrating. When working with many thousands of lines of code, to continually have to relocate oneself to a prior editing point, rather than it being remembered and immediately available, is an unnecessary distraction.

I also note other issues with the editor:

• It expands large amounts of code regions during editing if one is adding/deleting bracketed code (i.e. {}) when the brackets are inevitably unpaired in that process for a period. This can result in one having to continually collapse code, just to maintain the view one wants.
• When moving the cursor to the left border of the editing region, the automatic background highlighting of blocks of code (usually methods) to show the full extent of them, is potentially a health hazard to people who suffer neurological susceptibility to light flashing, e.g. epileptics. I raised this issue some time ago, even noting it directly with Ray, and NinjaTrader's response was to reduce the brightness of the highlighting. Whilst an improvement, I strongly urge that an option be offered whereby the user can select the brightness of the highlight, even to point of it being disabled. This is truly a potential health issue for some people. For me, I note that it becomes a very annoying matter when editing at night and the flashing is more obvious. One could also make the delay between entering the border region where highlighting is triggered and the actual highlight occurring to be settable.
• When Finding text, if the text is in a collapsed region beyond the currently displayed text (i.e. off-screen), the region will be opened and the cursor moved to the found text, but the screen does not scroll to the opened point, leaving one wondering if there was something found or not. One has to manually scroll down to discover the location.

Many thanks, as always, for your consideration of the feedback provided.

[NinjaTrader_Jesse]

Hello jeronymite,

Thanks for the post.

At this time there is no update, if I have anything to provide I will reply back here. I will see what i can note from these comments to provide to development.

I can suggest to use visual studio as that is a more advanced editor which likely does not suffer the same problems. The toolbar button will launch the project and as long as you have the NinjaScript editor open it will compile changes to the files.

I look forward to being of further assistance.

[tgn55]

I reported this issue a while back in this post.

I did a fair bit of testing but could not trigger it on the standard source files. Mine are quite a lot more complex... and it is a thorough pain. I do use VS... much better editor, but there are many other advantages too. Definitely recommend you go down this path... it will be worth it.

[jeronymite]

Thanks, tgn55. I read your original post and you and others seem to encounter much the same issue as I have. It is extremely frustrating! And it seems to have been there for years!

One comment I would make about the entire matter is that what one is editing (the actual text/code), how many tabs are open, how long the editor has been active in a given editor window, or what the names of the files are, all are of zero relevance. The editor is supposed to be commercial-grade and robust. It should cope with anything that is thrown at it.

Sadly, it is not that level of product ... yet. I have even encountered bugs where in the middle of typing code, it crashes NT8, reproducibly. It seems that the syntax checking blows it up. I have yet to document that little gem.

In any case, I continue to wrestle with the enormously frustrating "where's my cursor!" bug every day, as well as numerous other "idiosyncrasies" that simply should not exist in a commercial-grade code editor.

As to using VS, I do agree it is a much better editor, but there are downsides as well, including the still-not-quite-there integration with the platform. What is there is great, but a more seamless integration is desirable, including full designer support. Also, even if the VS approach were "perfect", that cannot be an excuse for allowing the NinjaScript Editor to be so in need of improvement, since many users will not have VS.

Anyway, for all that, I continue to write code for NinjaTrader 8 and am delighted with its functionality and capabilities. There are lots more things I wish the developers would expose so I could use them, but that's a conversation for a whole new thread.

[jeronymite]

Here's another oddity I discovered today. If one copies a variable declaration that includes a scoping qualifier (private, internal, public) and pastes that into a method as a prelude to editing out the scoping qualifier (by way of convenient editing to avoid typing errors with the variable name), so long as the scoping qualifier is present, the editor loses all sense of regions below that point, including the recognition of method start/end on all methods that follow. Deleting the scoping qualifier immediately restores the correct recognition of the regions. Even simply typing a scoping qualifier into a method causes the issue. Should not happen, IMHO.

Hoping the NinjaScript Editor will receive serious development improvement in the next release.

Thanks.

[jeronymite]

Here is yet another reproducible "oddity" I have discovered. If one selects a range of lines to comment out, using the default HotKey to do this (Ctrl+K) does not work if the final line in the selection is immediately before an already-commented-out line.

For example (with Line numbers [not in the actual editor text] added to illustrate):

1 Text line
2 Another text line
3 Yet another text line
4 // Comment line

Selecting only lines 1 and 2 and using Ctrl+K will comment out lines 1 and 2 as expected. Selecting lines 1, 2 and 3 and using Ctrl+K will not do anything.

Grateful for all identified issues, including this one, to be fixed in a release in the near-future, where the NinjaScript Editor is given a lot of attention to improve it.

An additional side-comment (an opinion) about using Ctrl+K to comment out lines is that I would like to see either Ctrl+K act as a toggle for Comment Selection/Deselection or an additional HotKey defined for Comment Deselection.

Also, separately, just for information here, I have initiated a feature request re how the editor expands/collapses regions: https://ninjatrader.com/support/foru...ons-on-command

Thanks.

[NinjaTrader_Jesse]

Hello jeronymite,

I will test and report what I can here.

I would suggest to use visual studio instead if you need a solution now, you can use the mentioned key commands in visual studio or reset any of them as needed. We highly suggest using visual studio in place of the NinjaScript editor when possible, it is also integrated into the NinjaScript editors toolbar to open the solution. You can also get visual studio community for free from Microsoft now.

If I have a tracking ID that I can provide for the details you posted I will reply back here with that.



I look forward to being of further assistance.

[jeronymite]

Thanks, Jesse.

There are some additional improvements in the Editor that would make sense:

• When there are multiple Editor windows, after a successful compile, clear the error displays in all windows. (Unsuccessful compiles should probably leave them as they are.)
• The popup message warning about Debug performance on first compile is fine ... once. It should not popup again if one subsequently compiles from a different Editor window.
• It would be good if the popup message warning about Debug performance on first compile had a "Do not show again" CheckBox, meaning do not show again, even after a restart of NinjaTrader. It should, however, still be shown again if Debug is disabled and subsequently re-enabled.

Thanks.

[jeronymite]

Two additional issues:

• Occasionally, the "Collapse all regions" hotkey collapses the regions then loses focus within the editor
• If the focus within the editor is lost, Control-Home to go to the top of the editor (and similar actions) cause the following unhandled exception:

2020-08-28 09:07:10:559 *************** unhandled exception trapped ***************
2020-08-28 09:07:10:559 Operation is not valid due to the current state of the object.
2020-08-28 09:07:10:565 System.InvalidOperationException: Operation is not valid due to the current state of the object.
at NinjaTrader.Gui.Tools.ScrollableTabPanel.SetVerticalOffset(Double offset)
at System.Windows.Controls.ScrollViewer.ExecuteNextCommand()
at System.Windows.Controls.ScrollViewer.OnLayoutUpdated(Object sender, EventArgs e)
at System.Windows.ContextLayoutManager.fireLayoutUpdateEvent()
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.ContextLayoutManager.UpdateLayoutCallback(Object arg)
at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
at System.Windows.Media.MediaContext.AnimatedRenderMessageHandler(Object resizedCompositionTarget)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Grateful if you would add these to the (ever-expanding) list of issues with the NinjaScript Editor to be fixed.

Thanks.

[NinjaTrader_Jesse]

Hello jeronymite,

Thank you for the reply.

I am not sure what you mean by "If the focus within the editor is lost, Control-Home to go to the top of the editor ". This is a good situation to make a list of steps that exactly produces the error and we can simply report it at that point. The error would not be enough for me to provide anything to development yet.

I can still suggest using visual studio as an alternative here to avoid spending further time on these items until a future version of the platform is released. The button in the toolbar will launch the NinjaScript solution and VS has the same general code editing capabilities/shortcuts.


Please let me know if I may be of further assistance.

[jeronymite]

Thanks, as always, Jesse.

When in the editor I simply press the hotkey assigned to "Collapse all regions". Sometimes (unpredictably), after the collapse has been done, the cursor is not visible in the editor, and pressing Control-Home and similar keys causes the unhandled exception. Normally, if the cursor remains visible, one can continue editing without issue, However, on the occasions when the cursor disappears, one has to select within the text area to be able to continue editing.

The same effect can be produced independently by opening a new editor window with a file to edit. Verify that the cursor is visible, the text is editable, and that Control-Home takes you to the top of the document, as one would expect. Now, click on the tab of the editor window. Without clicking in the editor text area, click Control-Home as if one wanted to move to the top of the text area. The unhandled exception occurs. This is essentially reaching the same point by different means.

Both of these ways (deliberate as demonstrated above, or unexpected when using the hotkey) should not generate an unhandled exception.

Hope this clarifies.

As for using the VS editor, that is certainly one possibility, and I do take advantage of that from time-to-time. But there are aspects to using that editor that make the NS editor preferable ... strangely. Perhaps I need to be more familiar with the VS editor's range of discretionary options. I find its "presumptuous" approach to code formatting problematic at times. I'll investigate using it further.

Thanks.

[jeronymite]

Another observation of aberrant behaviour, if I may.

When editing braces (i.e. {}), the editor automatically expands everything below the editing point if an opening brace that already has a matching closing brace is deleted. This does not happen if the matching closing brace is the one deleted. This leads to a continually frustrating experience of having to re-collapse the code below if that is the view one wanted.

As always, grateful for your kind assistance in these and all other matters.

Thanks.

[jeronymite]

One further comment, more akin to a feature improvement request.

Within the editor, Control-F emulates the Microsoft product behaviour of opening a Find window. Thanks. The window also offers a Replace capability, but the equivalent shortcut that is available in Microsoft products for Replace, i.e. Control-H, is not implemented in the editor. Can this additional shortcut be implemented, please?

Thanks.