I wanted to keep you up to date on whats going on with SlickEdit.

In October of 2012, Uniloc USA, Inc. filed a lawsuit against SlickEdit, Inc., alleging patent infringement (U.S. patent 5,579,222) concerning a license management system.

Uniloc USA, Inc. is a patent-assertion entity or “patent troll,” i.e. a company whose sole business is to sue software companies including Adobe, Microsoft, Sony, and Symantec. It has sued more than a dozen companies over this patent.

In an unusual turn of events, after more than a year of litigation Uniloc USA, Inc. asked the Court to dismiss its own lawsuit against SlickEdit, Inc.  This came a week after the court held a three-hour Markman hearing on February 13, 2014 in which SlickEdit argued that Uniloc’s patent covered far less than what Uniloc was claiming.

Make no mistake, this is a BIG win for SlickEdit in what amounts to be a David vs. Goliath scenario.

Patent infringement suits are considered extremely costly to defend against. Even in cases like this where there is no infringement, small companies are often forced to settle due to the astronomical legal fees associated with patent cases.

I knew SlickEdit did not infringe. I hired a great attorney and worked closely with him. We were able to put together a solid case and ultimately saved the company a lot of money.

I interviewed nine different patent attorneys at nine different firms and easily chose Tim Shannon of Verrill Dana, LLP.  Tim and his team mastered the patent, mastered our product inside and out, and led a claim construction argument that literally threatened to derail Uniloc’s entire national campaign. Tim never let up and got us a great result. I highly recommend his service.

Glad to be done with this mess. Now I can continue to have a blast working on the product!

Clark, CEO

This (‘/’) is a slash.  It is used to separate pieces of paths and filenames.  It is used by all the UNIX systems I am aware of, the Mac (that’s right, I said UNIX and the Mac separately, and I will continue to), and  URLs around the world.  On a US QWERTY keyboard, it is on the same key as the ‘?’.  It is located in a convenient place so that a touch typist can sit down at virtually any keyboard type a filename and know where it is. a/b/c/d/e/file.c.  Wow, that’s easy.

This (‘\’) is a backslash.  It is used by Microsoft to separate pieces of paths and filenames.  It is used by Microsoft Windows.  On a US QWERTY keyboard, it is usually above the enter key, except in some cases where it is in the same place but ½ the size, or other cases where it is located at the bottom of the keyboard. a\b\c\d\e\file.c.  I can’t say that was exactly painful  but it wasn’t as easy.  It just wasn’t.  Also, this could just be me, it looks funny.

Sometimes when we start a project, we do something to differentiate ourselves from other similar projects that came first.  Sometimes these things don’t serve much purpose except to say “See?  I’m not doing what you did, I’m doing something different”.  It could be that’s how the backslash came about.

Regardless of why it’s here with us, it is time for it to be put to rest.  Support both for a few versions if it makes you comfortable.  Or just make a clean break.  I’m OK with either one.

Next time on “Dan Rants About Things That Don’t Make Much Sense to Him”, I’ll cover the Mac using the Control+Click as a Right Button Click even though two button mice have been widely available since Nirvana was a garage band.  I’ll cover drive letters in an upcoming episode but I just exposed the uselessness and confusion of the backslash and I don’t want to stick it to one company twice in a row.  Plus we don’t have to do it all at once.  c:/a/b/d/e/file.c.  I can live with that.

Today’s tip, as most of these prime numbered tips, comes from something that was a default years ago that I stuck with.

Put your build output in an edit window.

Most programmer’s editors or IDE’s relegate the output from a build to some sort of tool window that is typically in a tab group docked a the bottom.  This is how SlickEdit works by default, because it is what is expected today.  Sometimes you have to jump off the bridge because all of your competitors did.  But that doesn’t mean that is the most powerful way to work.

Try right clicking in the Build tab and selecting “Send Compile Output to Editor Window”.  This means the build window (what we call the the “concurrent process buffer” or simply “process buffer”) is in the ring of open files when you cycle through them using the next-buffer/prev-buffer commands, or pick one from the Files tool window.  This is actually very powerful.  At first it may seem that you can’t move freely, but you can.  The cursor-up key will cycle through the command history by default, but clicking the mouse or using a non-cursor key to move (page-up for example) will allow you to move freely through the output, or delete it by hand.  I find this much more useful than trying to view my output through a porthole.  Try it out and let me know what you think.  You can always turn this off by right clicking in the Build tab (or the process buffer) and turning off “Send Compile Output to Editor Window”.

« Previous PageNext Page »