Working with selections

The very first thing I realized when I sat down to do this was that I’d need to get the bounds of the current selection, and I’d never worked with selections before.  Whenever I hit an area that I’m unfamiliar with, the first place I go is the API documentation.  To get there, you can click Help > Contents, and then click API Documentation at the bottom of the contents list.  Next, select Macro Functions By Category and you will be taken to a categorized list of the documented Slick-C functions.  I scrolled down and found the Selection Functions category in the list, clicked it, and started looking through that list for potentially useful ways to get the bounds of the current selection.

Right away, I noticed _get_selinfo() and it looked like a perfect fit.  The problem that I discovered though, is that _get_selinfo() doesn’t provide line numbers for the current selection, only column numbers, which made it useless for the information I needed.  I then decided to look at how other macro functions were using _get_selinfo(), so I right clicked it and selected “Goto reference to _get_selinfo” which lists all of the places in the macro code where it’s called.  You can also use the find-refs command for this.  This led me to other code that used _begin_select() and _end_select(), which I had passed over in the help originally because they sounded more like actions than a way of getting selection information. My strategy for getting the line range was to call _begin_select(), which places the cursor on the first line of the selection, and insert a line of code to get a timestamp.  I would then do the same thing with _end_select() and insert the code to get a second timestamp and report the difference.

Writing the macro

We’ll start by beginning a new macro file the same way we did in Part 1, and we’ll call it “insert_debug_timer.e”.  Using our selection strategy, we can write the following macro code:

After loading this, you can select some text in your editor, run insert-debug-timer() and your selection will be surrounded by the text “This is the beginning” and “This is the end”.  Success!  Now we can move on to inserting the actual code that will do the timing.  There will be two parts to this, the code that gets inserted before the selection, and the code that gets inserted after the selection.  I first made a throw-away command to test what the code might look like (in Slick-C):

Let’s start with the code that gets inserted before the selection.  We know that we’re going to have to detect which language we’re in and insert something different based on that, just like we did in Part 1.  I didn’t want to pollute the code in the insert_debug_timing() command, so I decided that I’d make a separate function to insert the “before” code.  This function will take the indentation text as a parameter and directly insert the text at the current line.

Next we can write the second function, which is basically the same as this one, except that it inserts the code to take a second timestamp, diff the two timestamps and report the time difference.  We now replace the lines in insert_debug_timer() with calls to these two functions.  We now have a command that takes the current selection (or the current line if there’s no selection) and wraps it with timing code.

A final improvement

This is a good start, but there are a small improvements I had to include.  The problem I ran into after about 10 seconds of using the macro is that if you have more than one section you want to time, you get a variable name collision.  Since these debug timing code inserts are really just temporary, we can name the variables anything we want.  I decided to make a global int variable called g_debugVarCounter that we could append to the variable names every time the insert_debug_timer() command is called, and then increment that value at the end of the command.  Here is the declaration of the global counter:

and here’s how we can use it to make the variable names:

Now we can insert debug timing commands wherever we want and there are no variable name collisions. The insert-debug-timer() macro is ready to be bound to a key combination by clicking Tools > Options, then go to Keyboard and Mouse > Key Bindings in the options tree, just like we did in part 1.

The macro file can be downloaded by clicking the this link.

Removing debug timing sections

Another important improvement would be a way to remove any of the code we’ve inserted by running this command.  We’ll cover how to do that in the next blog post… check back soon!

Unfortunately, only the most advanced of the advanced users ever consider getting so deep into an application that they learn to write their own macros for it.  There’s a few reasons for this.  Many people don’t even know that so much functionality is available in macro form.  Even if a user did look into making their own macros, finding out what functionality is available in macro code is an enormous challenge.  We all have deadlines and important things to do, and learning a new code base like the Slick-C macro language just doesn’t realistically fit into most people’s 24 hour day.

I personally love making little knock-off gizmo utilities for things that fit my workflow.  One of the things that I do often is putting debug statements at various points in my code to report the value of some variable.  This is very helpful when you want a history of values, not just a one stop breakpoint in the debugger.  I decided to make a macro that adds these statements automatically given the word under my cursor (assuming it’s a variable).  It’s a simple, first-step macro, and instead of just posting the code, I’m going to walk through the steps to make it.

Starting a macro from scratch

To start, click File > New Item From Template.  This will bring up the “Add New Item” dialog.  Select Slick-C in the “Categories” tree, select a location where you’d like this file (a scratch development folder is best), and enter insert_debug_value as the name.

Click the Add button.  This creates a new file called insert_debug_value.e in the specified directory.  This file will be opened in a new buffer with the following code included:

This is the basis for all macros started from scratch.  You can load it hitting the escape button to go to the command line, then type “load” and hit enter.

SlickEdit will respond by reporting “Module(s) loaded” in the status area at the bottom of the application.  You can now type “insert-debug-value” on the command line and your new command will execute.  Of course, it doesn’t do anything yet…

Implementing the macro

A general strategy for this function will be the following:

1. Get the current word that the cursor is in.
2. Determine which language is being edited.
3. Insert a new line beneath that to output it’s value.

That seems simple enough.  To start, we’ll use the cur_word() function to determine the full word beneath the cursor.  This function has a byref parameter, which returns the beginning column of the current word, so we have to pass a temp variable for that.  We can also use the say() function to report the value of curWord to the stdout window.  The code currently looks like this:

Again, you can reload this by hitting the escape button to go to the command line, then type “load” and hit enter.  If you run it from the command line, it will show the stdout window titled vsapi.dll, and the value of curWord will be shown.

Now we can start to build the text that we’ll insert.  Since we want this inserted line to be indented to match the current line, we’ll get the current indentation using the first_non_blank() function.  This puts the cursor on the first non-blank column on the line.  Next, we’ll get the column number using the p_col property.  We can build an indentation string using the indent_string() function, passing the starting column value.  The code now looks like this:

For this example, we’ll support three languages; Slick-C, C/C++ and Java.  To tell which language we’re in, we can use the p_LangId property, which returns the language ID of the current editor.  We can switch on that value and append the code to the variable containing the text to insert.  Finally we can call insert_line() to insert the text we’ve built.

Go to the command line and reload the file by typing “load” and hitting enter.  Now put the cursor on a variable in the editor, go back to the command line and type “insert-debug-value” and hit enter.  A say() statement will be inserted into the file on the line after the cursor that reports the value of the variable your cursor was on.  Now you have a way to quickly add a debug statement to your code to report the value of the variable without having to write anything.  A final improvement is to store the original line number and column so they can be restored after the new line is inserted.

The macro file can be downloaded by clicking the this link.

Binding a key combination to your macro

A macro like the one we just made works best when bound to a key, since we don’t want to have to go to the command line every time we want to invoke it.  To bind a key combination to this macro, bring up the options by clicking Tools > Options, then go to Keyboard and Mouse > Key Bindings in the options tree.  Type the name of the macro in the “Search by command:” text box to find it.  Double click its entry to bring up the “Bind Key” dialog.  We’ll bind it to “Ctrl+Shift+/”.  Press that key combination and it will appear in the “Key Sequence:” dialog.  Click the “Bind” button to bind it.  The key bindings entry should look like this:

Click OK on the options dialog.  Now, whenever you press “Ctrl+Shift+/” your macro will execute.

Is it perfect?

Absolutely not!  There are many potential problems here.  The cursor may not be on a variable.  The buffer may be read only.  There are also many other languages that this macro could support.  The list is potentially huge.  However, this macro is a starting point from which you can start to tinker around with writing your own macros.  Soon, you’ll be amazed at how much can be done with Slick-C that you’ll start writing lots of little tools and utilities that fit your own unique workflow.  Check back for more blog posts in this series, which will build on what we’ve started here.

In the article he discussing some of his favorite features of SlickEdit and why SlickEdit is his code editor of choice for programming.

On objections on switching editors

If your current editor works well enough for you, why switch? The answer depends on how you define “well enough.” Your current editor probably handles every editing command you think you need now, but consider the possibility that something could make you far more productive. You’ll see a few examples in a moment, but first, here are some of the reasons you might decide not to switch editors.

Regular Expression Search and Replace

This isn’t an exclusive SlickEdit feature, some other editors have it too; but if you haven’t had the opportunity to experience regular expression searches, you should really consider switching to an editor that supports the feature.

Macro Record/Playback

SlickEdit carries out many of its commands through its slick-C programming language (note that both Brief and Emacs have their own languages as well). SlickEdit lets you write your own macros, or do a simple record / playback. This comes in handy when the syntax for find and replace gets too dicey.

Other Features

As you might imagine, because SlickEdit’s been around for 20 years, this article just scratches the surface.

Continue reading Hey, Check Out My Slick New Editor! here: http://www.devx.com/enterprise/Article/42874/0/page/1

SlickEdit’s Slick-C macro language should be no stranger to our users, but many folks aren’t aware that macros can be called when SlickEdit is started. In this tutorial, I’ll demonstrate how to use Automator to create a simple text service for SlickEdit, using this macro call facility.

First, launch the Automator application and create a new service using the Service template. At the top of the new workflow, it should say Service receives selected text in any application. Make sure Replaces selected text is not checked.

From the library’s actions panel, select the Text > New Text File action, and drag it into the workflow as the first item. Pick a name and location for the temporary file to be saved, and make sure Replace existing files is checked, or else you’ll receive an Automator error the second time you use the service. Select the Encoding to be (UTF-8).

From the library’s action panel, select the Utilities > Run Shell Script action, and drag it into workflow as the second item. The shell should be set to the default of /bin/bash. Change the right-hand drop-down to read Pass input as arguments.

Delete any existing text in the shell script editor. Add the following text as the first line.

export VSLICKXNOPLUSNEWMSG="1"

Switch to Finder, and navigate to the Applications directory. Highlight your SlickEdit application, and Control-Click the application, and select Show Package Contents from the context menu. Drill down to the Contents/slickedit/bin, highlight the vs executable, and drag this into the shell script editor. This will insert the full path to the executable in the script editor. Make sure it’s on a new line after the export line you just typed.
Append the following right after vs, making sure the command is all one line.

-#new-file "-#get $1"&

The full script should look like the following:

export VSLICKXNOPLUSNEWMSG="1"
/Applications/SlickEditV1402.app/Contents/slickedit/bin/vs -#new-file "-#get $1"&

Automator Service

Don’t forget the ampersand at the end of the second line. Save the service, (⌘+S), and give it the name “New SlickEdit File”.

Switch to another application, like Safari or TextEdit, highlight some text, and pull down the application’s services menu. Your new service should now be available in the menu in the Text category.

The SlickEdit “magic” is done with the -# arguments. These specify macros to be called when SlickEdit in invoked. Any SlickEdit macro command (defined with the _command keyword in Slick-C) can be called. Surround the entire -# argument with quotes if the Slick-C command takes any parameters, like the get macro in this example.

You can create a similar service that will insert the text into the currently active document by simply removing the -#new-file argument.

By default, service workflows are saved under $HOME/Library/Services. You can remove the service by removing this file.

To rename a Service, select the workflow file under $HOME/Library/Services, Control-Click to bring up the context menu, and select Show Package Contents. Look for the Contents/Info.plist file, and open it in the Property List Editor application. Change the value of the Services/Item/Menu/Menu item title entry. You do not need to rename the workflow file itself.

This was the case when we put out our first release of SlickEdit 2009, version 14.0.0.5. We had completed our usual beta cycle before releasing this version, which included a number of drops to correct reported problems. After the last beta drop, we made a few more changes, all of which seemed totally risk-free.

Within two hours of releasing SlickEdit 2009, we had reports of severe problems with the File tabs and the File list. These problems trace back to one of these simple, risk-free changes. We had done our normal testing after these changes, and we hadn’t discovered any problems. But this problem was so severe we had to pull the release until it could be fixed.

So, what did we learn from this?

First, there are no small changes. Even when you think you know the effect a change will have, you could be wrong.

Should we have tested more? Sure, you can always test more, but that is no guarantee that you will find a problem. Testing suffers from a horizon effect: you can only see as far as you test. The problem you need to find could lay just beyond or miles beyond. You don’t know until you find it.

Second, testing is different than using. When you are testing, you click all the buttons and try all the functions, but you are rarely able to perform all combinations of operations. Some problems depend on the order in which operations are invoked. Others require multiple operations before the problem surfaces, as was the case with the problem we missed.

It should be no surprise that the parts of SlickEdit that work the best are the things we use everyday. But there are many languages we don’t use on a daily basis. Even if we did, with a product like SlickEdit, our testing cannot hope to replicate the variety and complexity of our customers’ use patterns.

We’ve determined that prior to shipping any release, we need help validating it. So, we’ll create a Release Candidate when we have finished our testing. We’ll make the Release Candidate available for early adopters to test, and if all goes well, it will be used for the General Availability release. In this way, we hope to catch more problems before they are set free to roam the countryside and terrorize the populace.

Q&A

Does that mean you’ve given up on testing? No, we plan to continue testing just as we always have. We just need help with final validation.

What if I don’t have time to help you catch problems? Then wait until a release is no longer a release candidate. At that point, others will have helped to validate it, and you will have less likelihood of experiencing issues with a new version.

If an unladen swallow flies west from New York…

Read The Friendly Manual… or not

Many software products have changed over the years to cater to end users who don’t want to spend a lot of time learning how to use new software.  I first saw this in the game industry, where people can’t seem to be bothered to read a manual at all.  These days, games don’t even come with instructions.  They provide a tutorial level or integrated help that watches what you do and introduces you to the things you need to know as you play.  It’s brilliant, really.  The users don’t have to read a thing before playing, and who’d want to?  When I get a new game, I don’t want to waste time reading when I could be already up to level 10.  The game companies win too, because they don’t have to pay for the printed materials.  Everyone’s happy.

But how does this translate outside the game industry?  It’s been tried before, with much less success.  Clippy was the spokesman for the first wave of learn-as-you-go user experiences.  We all know how that turned out.  “One of the worst software design blunders in the annals of computing,” wrote Smithsonian Magazine.

So users didn’t like being told how to use the software while they used it.  Another form of learning that is not always well received is the tip of the day.  I know my first order of business after installing new software is checking the “Never, never, ever show me this again” checkbox on the tip of the day dialog.

Wizards also tried to ease the user into getting up and going without having to wade through options pages and understanding all of the menus and toolbars.  Although wizards have had some success, it’s still a paradigm that’s seems old.  When I think of wizards, I feel like I’m flashing back on an episode of “I Love the 90s“.

At the very least , there hasn’t been a lack of effort to try to help users figure out how to use their software without the manual.  Yet, most of these attempts seem to fail.  It’s as if users don’t want to read how to use the software and can’t be bothered being shown how to use it by the software itself.  Part of me wants to rant about how idiotic that is and the other half of me recognizes that I fall into that group.

Done programming?  Great, now get back to work.

I’ve spent most of my programming career writing programs for in-house use, or writing programs that were bought by large companies to be rolled out in-house.  The thing that all of my work had in common was that the end users were not end users by choice.  The software I helped write was all rolled out in some fashion to a large group of people whose jobs depended on them learning the software.

Here at SlickEdit, I’m no longer writing software that users must adapt to.  Instead, I’m writing software that users  make a conscious choice to use or not use.  The choice to use it hinges heavily on the trial, and if the user can’t get the trial installed and doing spectacular feats in less than five minutes, then the opportunity is completely lost. The bottom line is that the most important software performance metric is not how fast my code works, but how fast the user can use it meaningfully.  If that doesn’t happen, then the user loses interest and all of the great work we’ve done will never be seen.

That’s quite a psychological transition for me, because I’ve never focused before on instant user gratification.  One of our strategies involves the software helping users through an optional tool window, called the Tools Assistant,  which is part of the “Tools for Visual Studio” product.  It stays off to the side or can be closed if the user doesn’t want the help.  But there’s also a lot more to this effort than just adding up-front convenience to the software.  We also have to think up new ways to get users to see the product in action with very little effort on their part, often without even downloading it and installing it.  This involves a lot of non-programming work, like video script writing, screen shots, articles, etc…  It’s certainly an interesting change of pace, but it really pushes the limits outside of my programming turf.  I took a break the other day to fix bugs and it was refreshing just to see code for a while.

I love a change of pace… it keeps things interesting.   However, trying to figure out how to pitch a software product may be one of the biggest challenges I’ve had as part of a software development team.  I certainly never took any marketing classes in college, and at this point they’d all be irrelevant anyway.  So I’m no longer focused on reducing the time it takes to perform complex operations… my focus now is on reducing the amount of time it takes a new user to say, “wow, that is so cool!”  So far I can’t find any way to calculate the big O for that, but I’m trying.

Unfortunately I discovered this technique after we finished the documentation and shipped the plug-in, but hopefully me pointing it out here may help some users. 

Also, don’t forget the “Activate Editor” command in Eclipse (F12 by default).  If you are using _eclipse_execute_command to jump into different Eclipse Views and search around mouse-less, hitting F12 will jump you back into the last active editor.

<update> 

Check out this thread of the SlickEdit Forums for adding a generic Eclipse Pass-through Command: http://community.slickedit.com/index.php?topic=3549.0

From the post:
If you are evaluating 3.4.0 for your company, you can make this happen easily.  One of the best features in Core 3.4.0 is the introduction of _eclipse_execute_command, which is discussed in the user guide/readme, and also a little more in my post here: http://community.slickedit.com/index.php?topic=3816.0 .  This is the idea that Rob suggests in this thread.

I’ll take this opportunity to give a brief tutorial on how to integrate that “Activate Task” shortcut into the SlickEdit environment.

First you need to know the command id of what you are trying to execute.  I used the method described http://evans-stuff.blogspot.com/2007/10/it-seems-that-im-not-only-one-still.html , in which you create a Simple Cheat Sheet and use the Command Browse button (see first screenshot).

Then I just used the search field to find the command (see second screenshot).

Now that I had the command/parameter info, I opened up the Slick-C macro file where I write my custom commands (ryan.e), and added functions for Activate Task and Deactivate Task using _eclipse_execute_command (see third screenshot).  Remember to load your macro file with F12 after writing the functions.

Then I used the SlickEdit Keybindings dialog to bind eclipse_activate_task to Ctrl + F9 (see fourth screenshot), and voila.  Hitting Ctrl + F9 in a SlickEdit editor will launch the Mylyn Activate Task dialog.

It may seem like a lot of steps, but it’s really not.  This whole process took me less than 10 minutes including the time I took to capture/crop/annotate the screenshots.  You can use this method to execute almost any Eclipse command from any plug-in from the SlickEdit environment.

- Ryan

Using Code Annotations to Write Review Comments
The Code Annotations feature in the Editing Toolbox is extremely useful for writing code review comments because it lets you attach comments to specific locations in the code without altering the code itself. You can bring up the Code Annotations tool window by clicking SlickEdit > Show Code Annotations.

[Click for full size image]

The first step when writing code review comments is to create an annotation file to store all of your code review comments. You can then send this file to the code review organizer when you’re done. You can use the Annotation File Manager to create a file called “Code Review – Bob” (or whatever your name may be).

Writing Comments About the Code
After applying the “Scott’s code” visualization scheme that we made in the first article, we can navigate through the sections of code that Scott has written. On line 497 of PackageBaseWhidbey.cs, we see that he’s doing a GUID comparison using a literal string. This goes against coding standards, so we’ll log a comment that the string literal needs to be defined as a constant. Put the cursor on that line and click the New Annotation button on the Code Annotations toolbar. This will bring up the New Annotation dialog.

We’ll create a review comment, which is one of the standard annotation types. We’ll also select the “Global : Code Review – Bob” scope, or category, which will put the annotation into the code review file we created earlier. After filling out the fields and clicking OK, a purple highlighted marker is placed on the line of the new comment.

[Click for full size image]

Once you create an annotation, it gets an entry in the annotation list. You can select that entry to see a summary of the annotation, or you can double click on it to jump directly to the code it is assigned to. This makes it easy to get to the code that you’ve commented on.

We also found a bug on line 431 of FileUtility.cs, so a bug annotation can be logged for that. This new annotation has a red highlight to indicate that it’s a bug type.

[Click for full size image]

It’s helpful to only show annotations that you have created for the code review, without the clutter of others in the list. You can filter out all non-code review annotations by using the Annotation Filter Configuration dialog, available on the code annotations toolbar. Select Filter by Scope and select the “Global : Code Review – Bob” item. Now, only your code review annotations will be visible in the list.

Wrapping Up Your Review
Once all of your code review comments have been completed, they will all be contained in the file “Code Review – Bob.sca“, which we created at the beginning of the article (code annotation files have an extension of .sca by default). That file can then be sent to the code review organizer.

All of the received code annotation files can then be imported by the organizer during the code review meeting, where they can be discussed. Reviewing code this way maintains a tight link between the code review comments and the actual source code, and is far better than trying to manage the process with pen and paper, or a set of text documents.

You can also create a report of the annotations to print before the meeting, or to send to other developers. To do this, click the View annotation Detail toolbar button. The Code Annotation Details dialog will be shown and each annotation in the list will be shown in the report. A small red document icon will appear by each annotation that may be clicked to navigate to that annotation in the source code. The report can be exported to HTML or printed.

[Click for full size image]

The next step will be the actual code review meeting, which will be the focus of part 3 of this series. Once the code annotation files are pulled together from all of the reviewers, those comments can be discussed and updated. After the code review meeting, they can be exported to a single code annotation file and emailed back to the group. The developer being reviewed then has a clear set of action items as a result of the meeting.

I can’t say that I’ve met too many developers that eagerly looked forward to reviewing code. Most developers understand the importance of code reviews, but many have experienced the pain of poorly run code reviews. Although SlickEdit Tools does not have a “code review” feature, it provides several features that can be used together to make a code review run smoothly. A well done code review process can be the difference between developer loathing and developer buy-in.

Because code reviews are such a big topic, this article will focus on some of the steps that lead up to a code review. Code reviews typically focus on the work of a single developer, so we’ll start there. We are going to be code reviewing the developer with ID SLICKEDIT\shackett (or Scott) in source control, and we’ll be reviewing his work since March 3, 2008, which is the date of our last (fictional) release.

Finding the Best Files to Review
Our first challenge involves finding the set of files that Scott has worked on since March 3, 2008. We’ll use the Find Version feature of the SlickEdit Tools Versioning Toolbox as our starting point.

Find Version allows you to query versions of the source code files in your solution. The code review organizer can use this feature to find an ideal set of files to review. Simply click SlickEdit > Find Version to bring up the Find Version tool window. For this example, we’ll find versions with the following criteria:

• Since date: Finds all versions checked in since a particular date, such as the last release.
• Developer name: Finds all versions checked in by one or more specific developers.

These two criteria are used to find all versions checked in by Scott during the latest development cycle (March 3, 2008 – present).

No development team has the resources to code review every file in that list, so it’s important to find the best candidate files to review. Therefore, the next task is to look through the results and find a sampling of files that represent the most important or complex code. You might also include some files that have a high number of check-ins by that developer, which indicates high rate of change, or churn. These are the ideal candidate files to be reviewed. Email the names of those files to all developers who will be participating in the code review.

[Click here for the full size image]

In this example, PackageBaseWhidbey.cs has had several changes and is a very important file, so we’ll include that in our code review process.

Loading the Files to Review
When a developer is ready to prepare their review comments, they should close all other files and open the files in the list sent by the code review organizer. This can be done quickly using the Load Files feature in the Editing Toolbox, which allows you to quickly filter the list of files in your solution and open the ones you’re looking for. Click SlickEdit > Load Files to use this feature.

By typing “basew” in the filter, we narrow down the files in the list to only those that include that text in their file name. We’ll select PackageBaseWhidbey.cs and open it.

Isolating a Developer’s Work
One of the most difficult things to do when reviewing the code of another developer is actually identifying the work that that developer did, especially if it was done as part of a team. Once you have PackageBaseWhidbey.cs open, we’ll use the Version Visualizer feature of the Versioning Toolbox to see which parts Scott has worked on. Click SlickEdit > Version Visualizer to show this tool window. Next, select “Default User Scheme” in the drop down at the top of that tool window.

The versions of the file will be processed and the tool window will list the names of all developers who have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify who wrote each line of the file.

[Click here for the full size image]

You can find Scott’s name (SLICKEDIT\shackett) in the tool window list and double click on it to go to the first line of code he contributed. You can then use the next and previous button on the tool window to navigate through the blocks of his work.

To make Scott’s work stand out more distinctly, select his name (SLICKEDIT\shackett) in the list and click the “Toggle Selection Visibility” toolbar button. When toggled on, Scott’s work will stand out, and all other developer’s work will be dimmed out. This allows you to quickly see what code is Scott’s and what code isn’t. You can click this button again to toggle it back off.

[Click here for the full size image]

Another option is to assign a unique color to Scott. To do this, click the Configure Visualization Schemes button on the Version Visualizer toolbar. This will bring up the Scheme Builder dialog. We’ll create a new scheme to highlight all areas of code worked on by Scott. Click the Add new scheme button and give the scheme a name of “Scott’s code”. We can now add a scheme item for Scott and give it a color of bright red.

[Click here for the full size image]

We can save this visualization scheme and then apply it by selecting it in the Version Visualizer drop down. This same scheme can be applied to any file to highlight areas of the code written by Scott.

[Click here for the full size image]

If you find a block of code written by the developer being reviewed that looks questionable, you may want more context about the developer’s intent, such as the check in comment made when that section of code was checked in. This information is very important for creating meaningful code review comments. The easiest way to do this is to see which version that code was checked in as, and look at the comment associated with that version. To do this, select “Default Relative Age Scheme” in the drop down at the top of the Version Visualizer tool window.

[Click here for the full size image]

Again, the versions of the file will be processed, but now the tool window will list the IDs of all versions that have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify which version last updated each line of the file. The colorizing of each segment corresponds to the age of the version it was checked in with (dark is oldest, light is most recent).

You can find the version associated with the questionable code and take a look at the comments associated with it. You can also use the next and previous button as before to see all of the code in the file that was updated as a result of that check in. For instance, we may have disagreed with the AddMenuCommandHandler function being public. We can see that change was part of version 762. By hovering over that version in the Version Visualizer tool window, we get a better understanding of why the function was made public. All of these features assist the team in making judgments about which code to review. They also provide some insight into the motivation the developer being reviewed might have had when checking a set of code in.

Next is the task of actually commenting on the code. This task is always best done in electronic format, in a way that can be pulled together as part of the code review meeting. The next article in the series will go through some of the features of SlickEdit Tools that facilitate writing comments about code and tying them directly to the source, without modifying the files.

Why is he having so much trouble using my editor? Because I’m using SlickEdit. What does he use? SlickEdit.This scenario happens a lot to me, really anytime a coworker tries to use my machine. Even after he gets used to the color scheme and whatever tool windows I use, if he doesn’t happen to use the same emulation that I use, he’s hosed. He spends more time trying to get somewhere in the code than he does actually making any changes. And no doubt he’s got some custom keybindings on his machine that he uses all the time, but my editor seems to think they have completely different functions.

So the good thing about SlickEdit is that it’s incredibly customizable. You can set it up to do whatever you want, however you want. You can go over, under, around, and through your code using commands and keybindings that you define, and after using them for a couple of days, you’ll feel like you were born using Ctrl+W to comment a line of code. You’ll do all this without thinking about it, because you’re thinking about the code instead of the use of the editor.

Ah, but then you have to use someone else’s configuration. It’s worse if they’re looking over your shoulder, giving you keyboard performance anxiety. You’re all thumbs, two left hands, a DVORAK user in a QWERTY world. Your customizations are your crutches, and you have to limp along to solve a stupid problem when you know it works perfectly on your machine.

In fact, you work perfectly on your machine, too.

The book is a symbol of the impact our work has on others. It says that there are enough people using SlickEdit for a publisher like Wrox to publish this book. That someone like John, whose knowledge of SlickEdit is remarkable, was available to write this book also indicates something of the passion our customers feel for our work. This awareness of the positive effect our work has had on others is often missing in software development.

I’ve worked on a lot of different projects in my career. Most were large custom automation jobs that were deployed on a server somewhere. Often there was little to no interaction with the actual users of the system. With SlickEdit, I get to see and use the result of my efforts. I interact with people who use our products every day. And now, with the release of Professional SlickEdit®, I feel, well, almost famous.

Why a SlickEdit Book?

The very existence of a 3rd party book on SlickEdit raises the question of why such a book is needed. Some might ask, “Isn’t the user guide good enough?” The answer, frankly, is “yes it is” and “no it isn’t”.

After 20 years of development, SlickEdit is full of features. Even though we’ve made great strides in improving our documentation over the last several releases, there’s still a long way to go. As John points out in the introduction to Professional SlickEdit®, “The SlickEdit User Guide that is shipped with the product does not even document every feature…” Hey! We’re working on it!

The SlickEdit User Guide and Professional SlickEdit® describe SlickEdit from two different perspectives. Our goal with the User Guide is to teach you how to install, configure, and use the features in SlickEdit. Professional SlickEdit® picks up where the SlickEdit User Guide leaves off. It covers many of the features that are documented in the user guide but it does so from an advanced usage perspective, showing effective ways to use the features. The book includes examples showing actual code and how various features can be used. It also includes sample Slick-C macro code to customize and extend SlickEdit, which will be of particular interest to advanced users.

We try to be process-agnostic at SlickEdit. We recognize that people have very different work patterns, and we don’t want to force you to change them. Instead, we believe it is important for SlickEdit to adapt to your work style. No matter how much we are convinced that brace style 1 (shown below) is the only sensible choice we allow you to mess up your code with brace style 2 and 3 as much as you like.

As an independent author, John had more degrees of freedom. He was freer to express his opinion, not unlike the freedom one has while blogging. So, where our documentation provides a list of the capabilities, John directs you towards the ones he finds to be most useful.

A Fresh Perspective

One of the key benefits I’ve gotten from this process is the insight from seeing our product from another perspective. Working with John and reading his descriptions of SlickEdit helped me see the product in a new way.

It’s a common problem. The more you work on something the less you are able to really see it. You see, instead, your perceptions of the product. How many times have you written something, code or text, and missed a simple flaw, like an omitted word or a boundary condition? No matter how many times you read it, you see what you expect to see not what is really there. Then, someone who reads it for the first time easily finds the problem.

My thanks to John Hurst for writing this book and the good people at Wrox for publishing it. And for treating me to a truly rewarding moment in my career!

[1] Professional SlickEdit® by John Hurst (ISBN-13: 978-0-470-12215-0), Wiley Publishing, Inc.

SlickEdit C# Project Tutorial

In this tutorial, we’ll build a simple C# console application with SlickEdit. This tutorial assumes you have the .NET Framework 2.0 and the C# compiler (Csc.exe) installed under %WINDIR%\Microsoft.NET\Framework\v2.0.50727. The Windows SDK (v6.0 or later) or the full .NET Framework SDK is required for the mdbg.exe managed code debugger.

Conventions

Dark blue italics represent menu commands: File > New
Bold items represent names of dialog buttons, labels, and controls: Location:
Monospaced fonts are used for environment variables, file paths and names, and text that you type into dialog controls:
Several screenshot links are provided that show how the dialogs are used.

Creating the starter project

• In SlickEdit, go to Project > New. Create a (generic) project. You probably want to use the Create project directory from project name option. Change the Location: to a directory where you want the project to go. Click OK to create the starter project. Dismiss the project properties dialog if it appears afterwards.
• Go to File > New Item from template…  Under Installed Templates \ CSharp, highlight the C# Main Entry Point template. Change the Name in the lower portion of the dialog, and check the “Add to current project” checkbox. Click Add, and the new file will be created. It should appear under the Source Files project folder. Edit the Main() method. Add the following code inside the Main()

  1 2 3 4 5

  #if DEBUG Console.WriteLine("Hello World - Debug"); #else Console.WriteLine("Hello World - Release"); #endif

• Go to Project > Workspace Properties to display the workspace properties dialog. A SlickEdit Workspace (.vpw) is the equivalent of a Solution (.sln) in Visual Studio. Click the Environment button to display the Workspace Environment Options dialog.
• Click Set Environment Variable . Create a new variable named DOTNETDIR , and point it to your .NET framework that you want to use for the C# compiler, like C:\Windows\Microsoft.NET\Framework\v2.0.50727. To use an existing environment variable in the definition of the workspace environment use the %(VARIABLE) syntax, and not the %VARIABLE% syntax. For example: %(WINDIR)\Microsoft.NET\Framework\v2.0.50727
  Be sure to select environment variable names that do not already exist.
• Create another variable named WINSDKDIR , and point it to the Windows SDK or .NET Framework SDK, like C:\Program Files\Microsoft SDKs\Windows\v6.0 . You want this to be a directory where the mdbg.exe managed code debugger can be found.
• Click OK. You will be prompted that you need to close and reopen the workspace for the variables to be set.

Setting up the build command

• Once you’ve closed and reopened the workspace, go to Project > Properties to show the dialog. In the Settings for: combo, select Release, which should be the only other choice right now.
• Go to the Tools tab and remove the Compile and Rebuild tools. (Use the red X button) This should leave Build, Debug, and Execute.
• Highlight the Build tool. Change the Command line: entry field to the following:

  1	%(DOTNETDIR)\csc.exe /warn:3 /target:exe /define:TRACE /debug- /out:%bdSeHello.exe %{*.cs}

  The %bd in the above command line is a variable that represents the build output directory, in this case Release\.
  The %{*.cs} construct means all project files that end with the .cs extension

• Replace SeHello.exe with whatever you want the exe to be named. You shouldn’t need to change the Run from dir: entry field as it should already be %rw
• Make sure the Capture Output and Output to build window options are selected.
• Highlight the Execute tool. Change the command line to “SeHello.exe”, or whatever your exe output name is from the Build tool command line. Change the Run from dir: option to %bd
• Make sure the Capture Output and Output to build window options are selected.
• Click OK to close the dialog and save the changes. You should now be able to execute a build from Build > Build , and see the output of the C# compiler. If the build succeeds, Project > Execute should run the console program and display the “Hello World-Release” results.

Setting up the debug build

• Open the project properties dialog again, and click Configurations . Click New to create the Debug configuration, and copy the settings for the Release configuration.
• Click OK to create the Debug config, and dismiss the dialogs.
• Back on the project properties dialog, highlight the Tools tab, and select Debug from the Settings for: combo box.
• Highlight the Build tool name , and change the Command line: entry field to:

  1	%(DOTNETDIR)\csc.exe /warn:3 /target:exe /define:DEBUG;TRACE /debug+ /out:%bdSeHello.exe %{*.cs}

  All we did was add the DEBUG define and change /debug- to /debug+. Again, use your exe name in place of SeHello.exe if you want.

• Highlight the Execute tool name, and make sure it is the same as you set up for the Release configuration.
• Click OK to save and close the project properties.
• Go to Build > Set Active Configuration … and select Debug.
• Execute the Build > Build command. If the build suceeds, run the Build > Execute command. You should see the “Hello World – Debug” output in the build window.

Setting up the console debugger

• Back on the project properties dialog, highlight the Tools tab, and select Debug from the Settings for: combo box.
• Highlight the Debug tool name, and change the Command line: entry field to:

  1	%(WINSDKDIR)\Bin\mdbg.exe SeHello.exe

  Again, change SeHello.exe to your exe name as needed. Run from dir: should be set to %bd

• Make sure the Capture Output and Output to build window options are selected.
• Click OK to save and close the project properties.
• Run the Build > Debug command. The build window should have focus with a blinking cursor just after the first mdbg> prompt.
• Enter the following commands in order, pressing <enter> after each one.
  • print args to show the value of the args variable.
  • next to do a step over
  • go to continue execution
  • quit to quit the debugger (IMPORTANT!)
• The entire debug session output should look like the following.

C:\Dev\Lab\TestProjects\SeHello\Debug
> C:\WinSDK\Bin\mdbg.exe SeHello.exe
MDbg (Managed debugger) v2.0.50727.312 (rtmLHS.050727-3100) started.
Copyright (C) Microsoft Corporation. All rights reserved.
For information about commands type “help”;
to exit program type “quit”.
run SeHello.exe
STOP: Breakpoint Hit
16: static void Main(string[] args) {
[p#:0, t#:0] mdbg> print args
args=array [0]
[p#:0, t#:0] mdbg> next
19: Console.WriteLine(“Hello World – Debug”);
[p#:0, t#:0] mdbg> go
Hello World – Debug
STOP: Process Exited
mdbg> quit
C:\Dev\Lab\TestProjects\SeHello\Debug
>

Handling complex build commands

A small console application like this one doesn’t have any extensive dependencies, and most of the default options for the C# compiler are fine. However, more complex projects will require many more options to be passed on the command line. For these cases, it can be useful to create an options file for all of the command line switches.

• Go to File > New to create a new text file and add it to the project. For this example, we’ll create the command line options for the debug build in a file called Debug.opts
• Edit the new options file and put in the following contents, which should match your first few options on the Debug build command line:

  1	/warn:3 /target:exe /define:DEBUG;TRACE /debug+

• Open the Project Properties dialog to the Tools tab, select the Debug configuration, and highlight the Build tool. Change the build command to:

  1	%(DOTNETDIR)\csc.exe @Debug.opts /out:%bdSeHello.exe %{*.cs}

• You can now run the Build > Build command to make sure the options file was correctly read.

The Coors Brewing Company of of Golden, Colorado, USA, had a fairly profound impact on the thirty-somethings in the world like myself.  You see, we have been led to believe for thirty years or so that it was once illegal to transport Coors beer East of Texas.  As far as I can tell, this was never true (although it was not nationally available until sometime in the 1990s).  Nonetheless it was the plot of the hit 1977 movie Smokey and the Bandit.  And when I say “hit 1977 movie”, it was the second highest grossing movie of that year.  Star Wars was number one.  It is not Scorcese or [fill in name of artsy director you like here], but it was a big deal.

I don’t want to get off on a big tangent here, but a small one is necessary, stick with me.  For anybody who did not get basic cable over the last thirty years, the basic plot is as follows:

• It is illegal to ship Coors beer East of Texas
• Burt Reynolds and Jerry Reed are paid a large some of money to get 400 cases Coors beer from Texarkana, Texas to Atlanta, Georgia in twenty-eight hours
• Burt Reynolds distracts cops from the speeding eighteen wheeler carrying the 400 cases of beer by performing really cool stunts in a 1977 Trans Am
  • In order to keep a low profile, the eighteen wheeler is painted with a mural of a masked bandit robbing a stagecoach.
• Jerry Reed sings his hit song, “East Bound and Down”
• Hillarity insues

Sounds ridiculous right?  Well, it does lack the realism of “Die Hard”, but it is actually not a bad movie provided that:

1. You are a guy
2. When you watch a movie you want to be entertained and don’t question things too much.

But the point here is that history was changed:

• The mystique of Coors beer was further boosted to those who could not get it East of Texas.  Here I need to emphasize that people thought it was really illegal to take Coors beer East of Texas.
• The Trans-Am became as cool as the (then recently jailed) Evel Knievel with suburban pre-teens across America.
• Jerry Reed had a hit single.

As much as I love old Trans-Ams, and that song, what I want to focus on is the first item in that list: People believed that it was illegal to take Coors beer East of Texas.  This is one of the standout facts people in the United States know about Coors beer.  What they do not know is this: in 1959 Coors was the first beverage in America to be packaged in a two-piece aluminum can.  These cans are a part of common life today.  There are two on my desk right this minute (diet soda, not beer).  They are so common place people my age really cannot picture a world without them.  A world where I am told you had to use a can opener (one of the pointy triangluar ones, not the rotating ones with a blade) simply to drink a beverage.  I imagine the people at The Coors Brewing Company of of Golden, Colorado are proud of having introduce this convenient, and recyclable, can.  But far more people remember that it was illegal to ship Coors beer East of Texas (and when I say “far more people”, I  mean “me”).

What could this possibly have to do with software development?  It can be difficult to figure out what people will latch onto.  In my tenure at SlickEdit, I have seen a lot of sleep lost over features that did not make quite the splash we hoped they would.  Thankfully none of these turned out to be as big a blunder as the Edsel.  I will share the one that personally hit me the hardest though:

1. Launch SlickEdit’s DIFFzilla® setup dialog (Tools>File Difference)
2. Fill in “Path 1″ and “Path 2″ with any two files that SlickEdit tags
3. Click the “Symbols” radio button at the top left



4. Clicking OK will yield output that actually show changes on a symbol level, including modified functions and added/deleted functions.



5. Selecting an item from this list and clicking “Diff” will actually compare just those two functions in the DIFFzilla output dialog.

This can be convenient for a number of reasons.  Sometimes a function moved, and the file itself has changed so much diffing two whole files just confuses matters.  This feature will shine in those cases.

I thought this would be a hit.  Everybody here thought it was a neat idea, and I worked feverishly to sneak this into the 8.0 release.  It was not a hit.  In fact, I am not certain that a user has ever actually used this feature.  It is generally good for a “wow” or two at a trade show though.

The moral of the story?  Be careful when you choose to add features.  The two-piece aluminum can may not look nearly as flashy as a 1977 Trans-Am, but people will still be using it 50 years later.

I often get involved in a similar debate about SlickEdit–not about whether it is a floor wax or dessert topping–but whether it is an editor or an Integrated Development Environment (IDE). To answer this we need to examine a brief history of programming and the differences between editors and IDEs.

A Brief History of Programming
The first evidence we have of man as programmer lies in the cave paintings in France. Some would have you believe that these are depictions recording daily prehistoric life. If you look more closely it becomes clear that these are really the first known examples of a written program.

The programming language is symbolic with a confusing syntax. What, today, we would write simply as:

requires many more figures in this primitive programming language. Of course, there were no computers back then, so all programs had to be hand executed. This could explain why most of the programs were about hunting and dancing. These early cave programs were written with bits of charcoal and pigments made from plant extracts. Editing tools were utterly lacking.

Another prominent example of early programming is seen in Egypt during the reign of the pharaohs. While some hieroglyphs may, indeed, be a form of writing, some we now know were early programs. This is particularly true of the large obelisks carved by the Egyptians. These were intended to be inserted into a large, obelisk-shaped reader. Unfortunately, no examples of these early peripherals still exist. As with many stone computers, they were disassembled and reconfigured into items more practical in those times, such as homes, restaurants, and parking garages.

The Egyptians’ programming language, called Osiris (later replaced by Osiris++), uses several abstract symbols that are combined to represent a larger set of programming concepts. In fact, the Egyptians were the first to introduce the concept of the variable, as seen in this example:

Though no interpreters from that time still exists, it’s largely believed that this statement translates into:

Again, the Egyptians had little in the way of editing tools. Programs were typically written with a hammer and chisel, making undo a very time consuming operation. They did, however, introduce the earliest use of whiteboards in the form of clay tablets, which allowed them to prototype code in a more forgiving form.

There isn’t time for a comprehensive history of programming, so we’ll have to skip over the early Greek and Roman programmers, who used Scroll 1.0 to write their programs, and frontier programmers in the early American west, who whittled their programs out of wood. We’ll skip past systems where you toggled programs into the front panel in binary and those using paper tape or punch cards.

The modern era of programming began in 19-mumble-mumble with the advent of the teletype. With these systems you had access to your full program and could readily extend and modify it. Editing was done a line at a time, so these editors were called “line editors”. You would print a range of lines, then type a command to insert or alter a line.

Teletypes were just an evolutionary bridge to the console, early CRT systems that displayed your code electronically. With consoles, the first visual editors were created. These editors displayed a page of code and allowed you to move a cursor within the file. Editing could be done simply by positioning the cursor and inserting or overwriting characters.

Contemporary editors share many characteristics with these early editors. They have added features like syntax highlighting, Graphical User Interfaces, window management, and a host of other features, but the process of writing code is fundamentally the same. Typically, these editors are file-oriented. You open a file, make changes, and save the file. All other activities are performed by programs or utilities launched from a command line or shell.

Integrated Development Environments group the related development activities into a single…well…integrated development environment. This is generally considered to be more convenient because it allows previously separate utilities to interact.

An IDE generally has 4 main components:

1. An editor—something providing the heretofore described ability to write code.
2. A project/build system—something that knows about the set of files in your project and allows you to launch a build on these files.
3. A compiler or interpreter—that allows you to build and execute your program.
4. A debugger—that allows you to step through your code and examine values.

Typically, an IDE will also provide a number of code/object browsers, integration with source control tools, and other utilities related to programming.

Interaction between the editor and the other components in the IDE provides key points of efficiency not available using standalone editors:

• The project/build system provides the knowledge of the available files and symbols in the program. Using this information you can browse to open files and use powerful completions while typing. This saves keystrokes, prevents wasted time looking up functions and methods, and reduces the number of compile errors.
• Integration with the compiler allows an IDE to launch a build and gather the results of the build. Programmers can quickly step through the errors and navigate to the source code for that error. With a standalone editor, you must manually open files and execute an operation to go to the specified line.
• Integration with the debugger allows you to set breakpoints from within the editor and view the code in the editor as you step through the code. Though similar capabilities are available in standalone debuggers, the code will be displayed differently, often without or with different color coding (sometimes called syntax highlighting). Once you are used to reading code in color, any alternate presentation slows your comprehension.

Different Strokes for Different Folks?
So, obviously, the IDE has completely supplanted the visual editor, right? No, for a number of reasons some users still prefer to use editors rather than IDEs. Emacs and vi (and their descendents) are the two most common examples of these.

One reason some people prefer a standalone editor is that IDEs tend to be very GUI-oriented, providing graphical mechanisms to launch operations. Standalone editors tend to be command-oriented, providing comprehensive key bindings to initiate operations. Using commands and key bindings is a big boost to programming efficiency, compared to the time lost grabbing the mouse and selecting things.

The editors in IDEs are often less powerful than the standalone editors. When all you do is write an editor, you can focus on the kind of power programmer operations that really improve programming efficiency. Developers of IDEs have to split their time between the editor and all of the other elements in the environment.

The choice of platform also makes a difference. Use of standalone editors is far more common on UNIX and Linux systems than on MS Windows or the Apple Macintosh. UNIX and Linux users are typically more comfortable writing scripts to automate builds and process results. They see the OS as the integrated environment.

Even with these reasons, users of standalone editors are missing out on those key points of efficiency that come with an IDE. That’s why the descendents of standalone editors, like Vim and GNU Emacs, have been adding more of those capabilities.

So What the Heck is SlickEdit?
SlickEdit looks and works like an IDE, but we call ourselves an editor. This is because we don’t include a compiler or a debugger with SlickEdit. It’s also because we place our emphasis on the editor. SlickEdit is a command-oriented, keyboard-centric editor. In fact, SlickEdit began as a powerful visual editor that grew to include the most essential IDE capabilities.

Though we don’t include a compiler and a debugger(iii), we work with commonly available compilers and debuggers. If you have installed the GNU C/C++ tool chain, a Java JDK, or Microsoft Visual Studio, then SlickEdit works like an IDE, providing the key integrations described previously. SlickEdit detects the presence of these tools and interacts with them inside the SlickEdit environment(ii).

So, is SlickEdit a great editor that works like an IDE, or is it an IDE with a great editor? Like the Shimmer product in the SNL skit, SlickEdit is both.

————————————————————-
i: http://snltranscripts.jt.org/75/75ishimmer.phtml
ii: SlickEdit launches the Visual Studio debugger in a separate window.
iii: SlickEdit does include a copy of GDB to insure compatibility.

Managing Builds

Schema URL Mappings
 

We’ve been using CruiseControl.NET and NAnt for nightly builds of our products. Both technologies use an XML file format. SlickEdit’s XML features include Auto-completion of tags and attributes, gleaned from the definitions in XSD schemas. Visual Studio also has an excellent XML editing experience, but SlickEdit allows you to customize what specific XSD schemas are used for a particular XML namespace declaration. CruiseControl.NET does not distribute an “official” schema for their namespace, mostly because the CruiseControl syntax is extensible with a plug-in architecture. By using Microsoft’s XML tools I was able to take my existing CruiseControl project files and generate a starter schema. SlickEdit’s URL Mappings allow me to then use that custom schema for document validation and auto-completion.

In an effort to reduce redundant code and reduce the size of the NAnt source files, many common properties and tasks used by multiple projects have been broken out into a series of include files. However, locating a property or task that is defined in an external file usually requires a multi-file search.

Regex Evaluator

By using the SlickEdit Regex Evaluator I was able to craft a regular expression to search for task and property definitions. Once the expression was ready, I created a macro in Slick-C (SlickEdit’s C-like macro language)(snippet) to search for the word at the cursor in the current NAnt build file and any included build files. Now I have instant search across multiple files when the definition of a property or target eludes me.

Building Installers with WIX (Windows Installer XML)
WIX is an open-source toolkit from Microsoft for building Windows Installer .msi files. It too uses an XML file format. There are tools available in Wix for getting your project started and compiling your list of files to be installed, but authoring an installer still requires quite a bit of hand-editing the XML source. I use SlickEdit’s Aliases feature to provide completion of code snippets for commonly used Wix XML constructs. Aliases go well beyond simple insertion of prewritten code. You can configure an alias to format and auto-indent the new text, set the initial editing position, and prompt for replacement parameters.

Defining Aliases

All of the code for the installer is placed in a custom SlickEdit project. A custom project allows you to create as many organizational folders as you need, optionally organized by physical directories or file extensions. The real power in SlickEdit projects is the ability to define custom build steps to call external tools. Since this project invokes quite a few NAnt build targets, I customized the build menu by adding new build tools to the project. These allow me to invoke NAnt to execute the build targets and display the output in the build window.

Dabbling in PHP and MySQL, with a Side of PowerShell
A year or so ago, I worked on a side project to develop a content management website using PHP and MySQL. The application had to work with Internet Explorer, Firefox, and Safari browsers. Using SlickEdit allowed me to create a single project to organize the code and work with the Subversion repository located on a remote Linux hosting account. And I was able to edit the code on both a Windows XP tablet PC and my MacBook as the custom project format is identical on Windows and *Nix platforms. Customizing the project’s build commands allowed me to add shortcuts for opening pages in multiple browsers, execute MySQL scripts one the database, and transfer files via FTP to my remote hosting account.

PowerShell Syntax

SlickEdit supports dozens of languages out of the box, and has the ability to quickly add your own user-defined highlighting schemes or modify existing ones. I found that the default listing of SQL keywords didn’t include some of the MySQL keywords, but they were easy enough to add via the Color Coding options dialog.

For the past year or so I’ve been using PowerShell in place of cmd.exe, and steadily building a library of scripts to automate routine tasks. But it just didn’t seem right that such a neat shell language should have to be edited without any syntax highlighting. With SlickEdit, this was easily solved. To set up color coding for PowerShell, all I had to do was create a new language definition, specify the comment format, and add a list of keywords.

No Code Left Behind
These examples only begin to scratch the surface of the features available in SlickEdit. Your code or build process doesn’t have to be a second-class citizen just because it doesn’t fit neatly into Visual Studio. For all those times you have to “just edit it in notepad” or “run this tool from the commandline”, think of how SlickEdit could save you time and hassle.

Download Free Trial

You can download a free trial of Slickedit 2007 here: SlickEdit Trial

1. It performs a scan of your source code and creates an XML file representing all of the code elements and their associated comments.
2. As you click through the Auto Code Doc Viewer, it dynamically produces the next rendered page by running a transform on the XML file created in step 1.

Therefore, it’s fairly easy to customize the output. This article will show you how to make some simple modifications to do this. For our example, I’ll be creating a customized SlickEdit template.

Creating a New Template Directory
Before we do anything, we will create a new output template. To do this, perform the following steps:

1. Browse to the C:\Program Files\SlickEdit Tools v1.1\win\HtmlFormatting directory. This may be in another location if you didn’t install it to the default directory. The HtmlFormatting directory is the directory we’re interested in.
2. Create a new folder as a child of the HtmlFormatting directory. For the example, it will be called SlickEdit. Copy the contents of the HtmlFormatting directory to the new directory. The following screen capture shows this.

If you start Visual Studio and go to Tools > Options, then find SlickEdit > Auto Code Doc Viewer, the option page will have a drop down called “HTML output style”. If you click the drop down, you will see SlickEdit in the list. Selecting it will use the transforms from the SlickEdit directory instead of the HtmlFormatting directory. This is shown in the following screen capture.

Out new SlickEdit template is created and ready to use, so now we can make some modifications to it.

The Style Sheet
At this point, all of our modifications will be made to files within the newly created SlickEdit directory. The file default_stylesheet.css contains the major styles that are used in the HTML rendering, so we will edit this first. Before we go any farther, let’s take a look at what our Auto Doc Code Viewer output looks like before any edits.

Modifying the Background Color
Our first modification will be to change the background color to a very subtle blue (#EFF8FC). To do this, open default_stylesheet.css for editing. Add a background-color item to the BODY entry at the top of the file:

BODY
{
    font-family:verdana,arial,helvetica;
    color:#000000;
    margin:0px;
    margin:5 0;
    margin-top:0px;
    background-color:#EFF8FC;
}

Save that change and click the refresh button on Auto Doc Code Viewer. The output now looks like the following:

We now have a blue background!

Modifying the Quick Link Color
Now let’s update the style of the index and hierarchy lines. Those are controlled by the “eyebrow” style, so search for the word eyebrow to find its definition. We’ll update its background-color and border-width to match the following:

.eyebrow
{
    background-color: # DDDDDD;
    border-color: #999999;
    border-width: 1px 0 1px 0;
    border-style: solid;
}

This will give it a top edge and will shade it light grey. The top edge will be important when we add stuff above this element.

Modifying the Code Element Name Bar Font
For our final step in the style sheet, we’ll modify the font of the code element name bar to a larger, non-bold Comic Sans MS font. To do this, find the definition of the h1 style and change the definition of h1 to the following:

h1
{
    font-family: Comic Sans MS;
    font-weight: normal;
    font-size: 180%;
    margin-top: 0em;
}

The following screen capture shows our changes to the output so far.

Adding a graphic
Our next and final step will be to add a company graphic to the page. To do this, a SlickEdit graphic named slickeditlogo.gif is copied to the SlickEdit directory we created. To add the graphic, each XSL file must be updated. For this example, we will update the solution.xsl file. The others can be updated in a similar way.

Open the solution.xsl file in the SlickEdit directory for editing. Find the <body> tag and add the <img> tag to the line directly between it and the <table> tag that follows it. It should look like the following:

<body topmargin="0" leftmargin="0" ... >
<img src="slickeditlogo.gif" mce_src="slickeditlogo.gif" />
<table bgcolor="#ffffff" border="0" ... >

If we save and refresh the output, we won’t see any change. In order for the change to be applied, the XSL transform file must be reloaded. The way to force that to happen is to go to the to Tools > Options dialog, the find the Auto Code Doc Viewer options. You don’t have to change anything, just click OK. This will force a reload of the XSL transforms, including the change to the solution.xsl file. To see the change to pages that you’ve already generated (visited), you must do a rebuild.

The following screen capture shows our changes to the output so far.

Conclusion
Because Auto Doc Code Viewer uses XSL transforms, there are many different ways that the end result may be viewed. The default template provides the first in what will be a series of code documentation views, available in future releases. Until then, you have the ability to modify the templates yourself to suit your own output needs.

Right around this time we started work to add version control support to Visual SlickEdit 1.1.  At the time most of the version control systems we had requests to support were very file oriented.  You checked a file out, it was locked, you worked on it, and checked it back in.  Some of the companies that made these products were actually here in “The Triangle” area of central North Carolina, which was convenient, and almost all of these companies were willing to give you a free copy of their product for support purposes, or do a product swap.  In no particular order, these players were Source Safe, TLIB, and PVCS on Windows, and RCS or SCCS on UNIX.  Briefly there was a product for Windows called “Microsoft Delta”.  It is really hard to find information about at this point.  Apparently it was not well received, and Microsoft purchased One Tree, the company that produced Source Safe.  (This is not one of those anti-Microsoft rants, just a history lesson).  Supporting these products proved challenging because it was tough to create a general purpose framework for all of them, and we felt creating individual support for each one would eventually prove even more problematic.  So we put in place a system with configurable command lines that had “parse in parts” and we were off.

A few years down the road, we started getting requests to support a product called ClearCase.  It was more directory oriented than file oriented, and actually had its own file system (for its UNIX versions).  It was huge compared to these other systems.  It also changed hands (or in some cases companies changed names) a few times.  We managed to come up with a set of command lines that worked alright for ClearCase, and looked ahead.

Around 1995 Microsoft released a spec for dealing with source control systems known as the “SCC Interface”.  It was very file oriented.  It supported the concept of a project, but most of the operations that were supported dealt with a single file (checkout, checkin, etc).  We started support for this in Visual SlickEdit v4.0.  It solved some problems, and created some new ones.  Overall it was a good thing.  Unfortunately, it kind of disappeared.  The interface itself is still in use today, but if you wanted to find a copy of the specs for it, it might prove challenging.

In the late nineties, we had a lot of requests to support a version control system called CVS.  It had actually been around for at least ten years at the time.  CVS is a very directory oriented system, and I initially had a very hard time wrapping my head around it.  We finally had to break our mold and support one system differently, with much customized support.  We first shipped the support for CVS with v9 in 2003, but we had been using it internally for some time.

Shortly thereafter, something called “Subversion” happened.  It works the same as CVS in many regards, so adding support for it was not that difficult.  It is taking some time to “settle down” though, given a combination of changes in Subversion itself and the amount that the interface has been used/tested.

So what does the future hold?  I hope to spread something more like our current CVS and Subversion interface to more systems.  I hope to do it in a robust manner that does not cause more problems than it solves.  Also, I hope not to spend too much time writing features that serve no practical purpose.  I hope to revamp our version control integration in a fashion that says “I learned a few things along the way”.

Top Ten Reasons NOT to use SlickEdit

10. I’d lose my parking spot if I had time to go out for lunch.
9.  Milestones? What are milestones?
8. Half the fun of writing code is fixing syntax errors.
7. If I finish my work on schedule they’ll just give me more to do.
6. I love reading library reference manuals.
5. I can get full disability when my Repetitive Stress Injury is severe enough.
4. Nothing is more satisfying than formatting my code by hand.
3. Real programmers don’t need no fancy tools.
2. The office is so peaceful after 10PM.
1. There’s really only one good reason not to use SlickEdit — you’ve never tried it.

The ads are running in both printed and online mediums and you can see a sampling of them below.

So there you have it – the top ten reasons not to use SlickEdit.  What do you think of the campaign? Is it funny? Does it catch your eye? Not your cup of tea (or coffee)? Let us know.  You won’t hurt our feelings.  We would love to hear your feedback, as well as any ideas you have for additions to the list. 

Look forward to hearing from you!

Jason

While no editor can offer the exact same set of capabilities as another, SlickEdit provides more of the powerful editing features that CodeWright users are accustomed to than any other editor…and some that CodeWright users never had before, like Comment Wrapping, Backup History, and the Regular Expression Evaluator.
 
No programmer relishes the thought of switching editors. After using an editor for years, the key sequences and operations become second nature. To ease this migration, SlickEdit offers a CodeWright emulation that uses the same key bindings for common operations and provides default behaviors familiar to CodeWright users. This makes you productive right away on SlickEdit.

A PDF of the CodeWright emulation is available at http://www.slickedit.com/codewright.

SlickEdit also provides a utility that converts CodeWright workspaces and projects into SlickEdit workspaces and projects. Each CodeWright .psp file is converted to a corresponding SlickEdit .vpw file. Likewise, the CodeWright .pjt files are converted to SlickEdit .vpj files. While this utility doesn’t convert all commands or options, it does save a lot of time setting up the project structure in SlickEdit. The CodeWright project converter is implemented as a Slick-C macro file.

To download it, go to http://www.slickedit.com/codewright.

Follow these instructions to load the file:
1. Save the file to any directory.
2. Open SlickEdit.
3. Select Help > Product Updates > Load Hot Fix.
4. Navigate to the saved zip file, select it, and click OK.

Once loaded, you run the converter by selecting Project > Open Other Project > Convert CodeWright Project. Or you can run it from the SlickEdit command line. Press F9 (in the CodeWright emulation) to bring up the SlickEdit command line. Type: convert_cw_project –oThen press Enter. The ‘o’ option tells the converter to open the newly converted workspace. CodeWright users, you have a new home!

Visit www.slickedit.com/2007 to download a free trial today!

In programming, however, the mouse can be one of the greatest productivity sinkholes. Time is wasted each time you lift your hand from the keyboard to grab the mouse, and more time is wasted when you move your hand back to home row in preparation for more typing.

So what’s the solution? Keep your hands on the keyboard! To do this use the SlickEdit^® command line and bind commonly used commands to keys.

Launching Operations

SlickEdit provides three ways to launch operations: key bindings, commands, and menus. OK, there are actually four, if you include icons. Since the focus of this article is how to keep your hands on the keyboard, I was going to skip that one.

Key Bindings
Key bindings are the fastest way to launch an operation. They can be pressed at any time while editing. A key binding associates a key sequence with a command. A key sequence is a series of key strokes. Anything you do frequently should be bound to an easily remembered key sequence.

For example the key sequence Ctrl+A means hold down the Control key, typically labeled “Ctrl” on most keyboards, and press the A key. The letter A is represented as an uppercase letter, but this does not mean that you are to press the Shift key. If you are supposed to press the Shift key, the sequence will be written as Ctrl+Shift+A.  We use the uppercase A to match the letter on the keyboard.

Commands

Commands are useful for less frequently used operations or operations that take arguments. They are executed from the SlickEdit command line and are nearly as fast as key bindings. Press the Escape key (in most emulations) to activate the command line, which is displayed at the bottom of the SlickEdit application window. 

  Figure 1, SlickEdit with Command Line

It offers a full command history and completions for command names and arguments. Use the arrow keys or the mouse to scroll through previous commands. As you type, a list of possible completions is displayed. Use the arrow keys or mouse to select a completion. SlickEdit stores recorded macros as commands. You can also use Slick-C to write new commands. Use the _command keyword to identify a macro as a command. Any command can be bound to a key sequence for faster launching. 

Menus

Menus are accessed via the mouse or a keyboard shortcut. Menus are great for infrequently used items that may not be worth a key binding. They are also helpful to learn about new capabilities. But if you use an operation frequently, you will be more productive by binding it to a key sequence or launching it from the command line. Many menus list a keyboard shortcut to launch the operation. This is just the key binding for the associated command. So when you use a keyboard shortcut, you are really just using a key binding.

You can also operate the main menu through hotkeys. Enable the use of hotkeys by selecting Tools > Options > General, selecting the General tab, and putting a check in “Alt menu hotkeys”. This will be selected by default in many emulations. Once enabled, pressing the Alt key will display an underscore beneath each menu option, indicating the letter to press to activate that option. This is not as fast as key bindings, but it does keep your hands on the keyboard and is much faster than using the mouse. In some cases the menu hot key sequence is a good mnemonic for the command. For example, Alt+P, E (to bring up Project > Properties) may be easier to remember and type than binding project-edit to Ctrl plus some function key. 

Icons

SlickEdit presents icons in a series of toolbars related to different tasks. Toolbars can be customized with an extensive set of additional icons. Icons are useful for die-hard mouse users or for setting up infrequently used operations for which you have a hard time remembering the associated command or key binding. 

The Golden Triangle

The three methods (excluding icons) to launch an operation are related, forming the Golden Triangle of operation launching. If you know how to execute an operation with one of these, you can easily configure SlickEdit to launch the operation using the other two methods. Commands form the base for the other two…which is why it is shown as the apex of the triangle (Damn it, Jim, I’m an engineer, not an artist!). Maybe I should have used a Golden U or something. 
 

Figure 2 the Golden Triangle; behold its majesty!

From Key Binding to Command

Sometimes you may want to change the key sequence to which an operation is bound. You first need to find the command associated with that key sequence. Use the what-is command from the SlickEdit command line or select Help > What Is Key from the main menu. The command line will be replaced with the prompt, “What is key:” Enter the key sequence in question, like Ctrl+A (hold down the Control key and press A), and SlickEdit displays the associated command. In CUA emulation, SlickEdit will output, “Ctrl+A runs the command select-all”. You can use the same approach to determine the commands associated with mouse events. After you run what-is, click any mouse button and you will be prompted with a list of mouse events. Select one from the list and SlickEdit displays the associated command. For example, if you select mbutton-down in CUA emulation, SlickEdit will output, “MButtonDn runs the command mou-paste”. 

From Command to Key Binding

To find the key binding for a command, use the where-is command or select Tools > Options > Key Bindings from the main menu. The where-is command works just like what-is, except you type in the command name and it outputs the key sequence. The Key Bindings dialog displays a list of the commands. You can scroll through the list or search for a command by typing the command in the text box at the top. The key binding for the selected command is displayed in the dialog.  

Figure 3, Key Bindings Dialog   

Modifying Key Bindings

The Key Bindings dialog can also be used to set a key binding. Type the command in the Command field, or select one from the list. Then click the “Add Key or Mouse Click” button. Now type the key sequence you want to use. For example, to bind a command to Ctrl+A, hold down the Control key and press A. To bind a command to a mouse event, click any mouse button and then select the appropriate event from the list. When you are finished, click the Bind button. To exit the dialog, click Done.

From Menu to Command
If the menu entry displays a keyboard shortcut, you can quickly find the associated command using what-is and entering the key sequence. If the menu entry does not display a shortcut, then finding the command for an entry involves a little more work.

SlickEdit provides a convenient UI under Macro > Menus that allows you to view and modify menus in SlickEdit. To find commands for the items on the main menu, select “_mdi_menu” from the list and then click the Open button. You are presented with a menu hierarchy that you can expand to find the menu entry in question. Once selected, information about the entry is displayed including the command executed. You can use this menu to add or change the shortcut for a menu item. Doing so has the same effect as using the Key Bindings dialog to bind the menu entry’s command to a key sequence.   

Figure 4, Menu Editor

Some menu entries are added dynamically by SlickEdit, so you may have to search the code to find the associated command. One example of this is Build > Java Options, which is only present when a Java project is active. Unfortunately, finding the associated commands for these entries can be very difficult and not easily covered in an article like this.

Context Menus
It is also easy to find the commands in the context menu for the editor window. The context menu, itself, contains an entry to “Edit This Menu”. Selecting this option brings up a dialog that lists the menu entries and associated information, including the command. Use this dialog to modify the context menus. Note that there are two context menus for the editor window: one when a selection is made and one when no selection is made. You can view or change the function that is used for these menus by selecting Tools > Options > File Extension Setup and selecting the Advanced tab.

From Key Binding to Menu and Back
Menu entries map to key bindings through commands, so key bindings are not directly associated with menu entries. To map from a key binding to a menu or vice versa, you need to look up the associated command. That Golden U is looking better all the time!

Customizing Toolbar Icons
The focus of this article has been to help you keep your hands on the keyboard, so icons weren’t included in the Golden Triangle. Besides, then I would have needed a Golden Square or some other form of rhombus, and that just doesn’t sound cool. You may find it helpful to change the set of displayed toolbars, add or remove icons, or change the behavior for an icon. SlickEdit uses the term “toolbar” to refer to both icon bars and tool windows. To change the set of displayed toolbars, select View > Toolbars and check/uncheck one of the listed toolbars. The list is divided into two groups. The top group is comprised of tool windows, like the Symbol view and the Projects view. The bottom group is made up of icon bars.

Additional options are available on the Toolbar Customization dialog by selecting View > Toolbars > Customize. The Toolbars tab provides a way to control the visibility of the toolbars. The Toolbars tab allows you to set options for which toolbars are visible, whether they are dockable, etc.

The Categories tab displays the complete set of available icons. These can be added to any icon toolbar by dragging them to the desired location. All of the icons have pre-defined behaviors, except the set in the “User Definable Tools” category. Use these to add your own functionality.

Each icon has an associated command that defines what happens when it is clicked. To view or change that command, right-click on the icon and select Properties. The icon needs to be located in a toolbar to do this. You cannot access the properties for an icon in the Toolbar Customizations dialog.  

“Exit, Stage Left”

OK, that one is a Snagglepuss reference[ii]. Whatever angst I previously expressed for mice has now been transferred to the Golden Polygon of Unspecified Dimensions. Regardless of the shape, you now have the tools you need to configure SlickEdit to work the way YOU think it should, using the key bindings you find natural. This is one of the essential steps in being a true power programmer.
 

[i] Mr. Jinks, sometimes called “Jinks the cat”, appeared in the “Pixie and Dixie” cartoons as part of “The Huckleberry Hound Show”, by Hanna and Barbera.

[ii] Snagglepus is another of Hanna-Barbera’s cartoon characters.