Skip navigation

Visual SlickEdit 9

New Features Go Beyond Code Editing



Visual SlickEdit 9

New Features Go Beyond Code Editing


By Mike Riley


Regular asp.netNOW readers may recall the praise I effused in my review of Visual SlickEdit 8.0. A new version has been released and has eclipsed the old by heaping on a load of new features while still keeping the environment remarkably agile and the start-up execution speed nearly as fast. Of most interest to .NET enthusiasts is the product's full support for CLR automatic code-completion of library functions and parameters. Additionally, VS.NET solutions can be debugged within the Visual SlickEdit environment, giving all the rich functionality without the boxed-in feel of most IDEs.


Figure 1: Visual SlickEdit 9 now supports code completion with library function and parameter look-ups for .NET languages, such as C# and VB.NET.


Beyond the .NET language improvements, Visual SlickEdit 9 also features the unique ability to refactor C++ code. Refactoring is normally associated with Java (and to a lesser extent, .NET) code, but there are still a considerable number of developers using C++, especially in the embedded arenas. Bringing this functionality to that programming segment is a long overdue capability that will make C++ developer's lives easier. Also of note in this new release is SlickEdit's first foray into the world of GUI development with a relatively simplistic Java-based Java GUI Builder. Although SlickEdit's GUI builder is light years behind sophisticated GUI palettes like those found in Borland's JBuilder product, it nevertheless is good enough for simple GUI-based applications.


Unfortunately, SlickEdit missed a major market advantage by not including a .NET GUI builder for the Windows environment. SlickEdit proponents might argue that the .NET GUI elements apply to only one of the OS platforms on which SlickEdit runs, but I would counter that that is not the case. Project Mono (, the Linux-interpreted version of .NET, has just released its initial interpretation of Windows form assemblies, effectively bringing .NET GUI-based applications to the Linux environment. Perhaps a future version of Visual SlickEdit will expand the new GUI building feature beyond Java and support any GUI-capable language such as .NET, GTK+ (The GIMP Toolkit) for Gnome-based apps, or even Tkinter for Python-based GUIs.


Figure 2: The rudimentary GUI-builder is Java-based for Java-only GUI apps; perhaps future versions of Visual SlickEdit will support .NET Windows GUI apps, as well.


.NET Code Improvements

The most important additions for .NET developers are the aforementioned CLR code-complete and debugging support. However, this could have used some additional attention as many of the build, debug, and execute settings need to be modified to support new C# or VB.NET projects outside the Visual Studio.NET solution files. As I eluded to earlier regarding the opportunity to create a .NET GUI builder, SlickEdit could have had a coup with native .NET Framework SDK support out of the box, circumventing any dependency on access to a VS.NET IDE. Instead, this version still defaults to playing a slave to .sln files for full debugging support. In other words, Visual SlickEdit 9's CLR debugger only works with previously prepared Visual Studio.NET projects/solution files, not on new standalone .NET language files created within the Visual SlickEdit environment that are not associated with a Visual Studio.NET project.


However, SlickEdit's support staff did help me manually configure the environment to build and execute .NET language applications (information that I will pass along to the reader). Configuration settings will need to be altered from the default in order to compile .NET Framework-based applications. For C# developers, these settings should be:

  • Debug: csc /out:%bd%rn.exe % /debug+{*.cs}
  • Release: csc /out:%bd%rn.exe %{*.cs}
  • Execute: "%bd%rn.exe"


Also, you must set the PATH to the C# compiler of choice (for example, C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322). Finally, make sure that your C# files have the .cs extension; otherwise, the build syntax will not tag the file for compilation. SlickEdit plans to have these settings pre-configured in a future release of the product. In addition to the C# support, Visual SlickEdit now also fully supports statement-level tagging for VB.NET and improved VBScript tagging recognition, as well.


Other New Features

Besides the enhanced cross-platform, cross-language neutrality of the editing environment, Visual SlickEdit now supports dual monitors for that Matrix-like surrounded-by-code feeling, background searches to keep your mind on coding (and not spidering), macro command enhancements, a product update manager, and a few other tweaks that continue to polish an already shiny product. A Flash-based tutorial is available on the CD, although this is identical to the product advertisement/tutorial on the company's Web site.




Now supports library functions and parameter code completion for .NET languages, including C# and VB.NET.

Command-line project parameters must be edited to work with .NET Framework SDK-only CLR applications.

Can now debug .NET CLR applications.


CLR debugger only works with Visual Studio.NET projects, not individual .NET language files.

Statement-level tagging for VB.NET syntax.

GUI Builder is for Java-only applications.

Figure 3: The good and the bad.



Visual SlickEdit continues to be my basic code editor of choice, although I had higher expectations for the .NET support in this new release. Although the C++ refactoring and Java GUI Builder tools are worthy additions, these features will be rarely leveraged by .NET converts. Regardless, for those developers who live in the real world of multiple code syntax environments and are believers of using the best tool for the job regardless of platform loyalty, Visual SlickEdit is still one of the best programmer toolboxes available.



Web Site:

Price: US$299; upgrade from version 7 or higher, US$99



Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.