Not logged in▾
Log In Register
Forgot Password Resend Validation E-mail

SyntaxEditor vNext - Editor View Panes

by Avatar Bill Henning (Actipro) - 7 comments
Wednesday, March 13, 2019 at 3:30pm

Another feature we're looking to add to SyntaxEditor vNext (the 2019.1 version) is editor view panes, which are small UI panes with editor-related functionality that slide in from the view's top-right corner.  We originally started this effort with the idea of adding an inline search view similar to the one found in Visual Studio. 

Here's a walkthrough showing how it works when you press Ctrl+F:

An example editor view pane for find/replace functionality

We will cover this new inline search view in detail in a future post, as it's still being developed at this time.  But you can get a feel for how it will function via the video above.  

As we worked on this feature, we thought it would be a great idea to try and make more of a generic mechanism to host these kinds of editor view panes.  Other editor view panes could be added for go-to line, go-to anything, refactoring, etc. kinds of user interfaces.

Submit Your Feedback

We're just in the planning stages of this more generic editor view pane mechanism right now and would love to get your feedback.

Let's hear your thoughts in the comments on what kinds of built-in panes you might like to see, or what kinds of custom panes you might build with this mechanism!

The features described above are intended for the future v2019.1 SyntaxEditor for WPF, SyntaxEditor for UWP, and SyntaxEditor for WinForms products.

Tags: developing, uwp, winforms, wpf, syntaxeditor
WPF Controls

Actipro's WPF Controls

Over 100 UI controls for building beautiful Windows Presentation Foundation desktop apps.

Learn More

Over 100 UI controls for building beautiful Windows Presentation Foundation desktop apps.

Includes editors, docking windows, MDI, property grids, charts, tree controls, ribbons, gauges, themes, and much more.

Learn More Download Free Trial

Comments (7)

Posted 6 years ago by Boyd - Sr. Software Developer, Patterson Consulting, LLC
Avatar

This looks great!  The search example shown is probably the best use case for this.  Built in "go to line" functionality would also be nice.  These are all little dialogs editor builders typically have to create themselves, so anything that can be provided out-of-the-box is excellent.

Some other concepts that might work well here would be things typically wired up to a status bar.  While not interactive, they could show important information.  Increment search, for instance, could display the text you've typed so far or the "no matches" text when nothing is found.

A zoom slider could also work.  When performing a zoom operation (via mouse wheel or keyboard), a slider could drop in and then auto-hide if you don't interat with it after a fixed period.  That would replace the current zoom indicator you have (that shows zoom percentage) and include the added benefit of being interactive.

Posted 6 years ago by Erel Uziel
Avatar

What are the options under the "document" list? For our use cases, search, refactoring and other similar features must be solution-wide.

Posted 6 years ago by Bill Henning (Actipro) - Actipro Software LLC
Avatar

Hi Erel,

At the moment, it's just "Document" and "Selection".  All these new built-in search features can be turned off if you like.  We still will have the old EditorSearchView in the WPF/UWP vNext as well.

Do you currently use EditorSearchView in your app?  

Can you provide more detail on the use cases you have, and if you are currently using EditorSearchView with them, how are you doing so?  That would help us plan for the future.

Posted 6 years ago by Erel Uziel
Avatar

> Do you currently use EditorSearchView in your app?  

Mostly no. We've implemented a custom search feature. It searches all documents and it is based on an index.

You can try it if you like: https://www.b4x.com/b4j.html

Posted 6 years ago by JesperTreetop
Avatar

This looks great. Hopefully there will be support for making sure the view moves out of the way and/or checking that the view isn't occluding some part of the editor text. For example, in the gif demo, searching for "constructs" would hide the match unless the editor scrolled such that the text was still visible.

Posted 6 years ago by Bill Henning (Actipro) - Actipro Software LLC
Avatar

Erel, were you saying you wanted to be able to alter the current search scope options (like possibly remove our "Selection" and "Document" ones and add your own custom one) so that you could intercept the search request with your own custom logic and handle the find/replace logic completely on your own?

Jesper, we've designed the pane to work similar to the Visual Studio panes.  While the pane isn't going to move to other locations if a match is made underneath it, there are some things that can help.  First, if a match requires scrolling due to its line being outside the lines in the view, it will try to scroll the match to the middle of the view.  That should generally be below the pane and fully visible.  The only time you'd run into it obscuring things is if the match was on the right side of the first couple visible lines.  In that case, if you hold Ctrl, it will fade the pane out similar to how it works with IntelliPrompt popups now.  You can also press Esc to close the pane.

Posted 6 years ago by Erel Uziel
Avatar

Not exactly. What I meant is that for our use case, features that target a single document, are less useful. 

It would be nice to have a built-in search feature that can search all documents.

Add Comment

Please log in to a validated account to post comments.

Previous Post Back to Blog Next Post