We have just released version 2.2 of PowerTOC. This new version just adds a new feature, the possibility to place the slide number to the left of the slide title.

This feature has been added by a request from an user. It was something that I considered when I originally planned PowerTOC, and again when redesigning it for version 2.0. The reason why I had not added it before is because, a complete implementation including tabs and indentation of normal slides with respect to title slides is not easily implemented.

Finally, I have reached a compromise. Users don’t get the option of placing a tab between the slide number and the slide title. Instead, the number and the title are always separated by a dot and a space. Therefore, table of contents with numbers on the left have the layout shown below:

I hope the solution is satisfactory. Otherwise, If you can think of a better way, please let me know about it.

I have always been curious about what features of Control Runner our users are really using. I guess each user only uses a subset of the available features (I personally don’t use them all!) because some of them are not useful for his personal needs, but mostly because the user does not know what features are available, or what are they for.

For that reason I plan to present some not so obvious ways of using Control Runner to increase your everyday productivity. I will present them in no particular order. In fact, my intention is to not even plan the series. I am so accustomed to Control Runner after nearly 15 years, that I am using it all the time without even noticing it. So, what I am going to do is to just go ahead and publish a post whenever I notice that I am using Control Runner to help me in my everyday work.

The feature of today is …

Make any window topmost

Today I have been working on our automatic registration system. This is a complex system that involves a PHP script that calls an executable maintained on our web server to generate automatically the registration keys for our products. The PHP script is called by our e-commerce partner when a client purchases a license for any of our products.

Since we are going to release a new product real soon now, I have had to change the key generation system in order to accommodate the new product.

It didn’t work. At all.

So, I had to do some tests using my local PHP Editor and a browser window. The routine goes as follows; you change a line in the editor, upload to the server (using the editor), turn to the browser, refresh the browser, notice what error is giving this time, return to the editor to try another thing … you get the idea.

When you are faced with a situation like this, it really makes sense to have both windows visible at the same time. Fortunately Windows makes it easy to have two (or more) windows tiled as shown on the following screenshot.

Figure 1 - Using tiled windows

This solution is better than having to switch from one of the windows to the other using ALT+TAB (and much better than using the taskbar icons).

But you can notice that I don’t really need to use the whole width of my screen for the browser, and that all the toolbars it has are really taking too much of my screen real estate.

What I do in these cases is shown on the next screenshot:

Figure 2 - Using a topmost window

I resize one of the windows (let’s call it the secondary window) to the smallest size that makes it easy for me to work with it. And I place it wherever it does less harm (note how I am taking advantage of the white space that exists in my PHP script). When I have it positioned, I press the following key combination: CTRL + ALT + T. That makes the secondary window a topmost window.

What is a topmost window? As it name suggests it is a window that is placed on top of all other windows, including the current window (the one that has input focus). This way I can see the main window and the secondary window at the same time.

You didn’t know of this keyboard combination, did you? Well, it doesn’t work unless you have Control Runner running on your system.

You don’t like the combination? Maybe it has too many keys. Don’t worry, you can change it.

Of course, when you have finished working, you can revert the secondary window to a normal window by hitting again the same key combination.

Do you have a favorite feature?

Please let me know it. I’d love to know how are you using Control Runner.

It has been our single most important problem with our line of Office productivity add-ins. And the reason why we haven’t been able to keep our development schedule on time.

The problem

Microsoft has been trying to improve the security of users of their Office software for years and has come with a number of schemes to prevent the execution and propagation of viruses (and other malware) in the form of addins for Office applications.

They have basically worked in two different directions:

• Preventing the execution of code not signed.
• Preventing the execution of code not installed on a particular place on the system (a trusted location to use their terminology).

Each version of Office from 2000 to 2007 has implement an slightly different way of handling the security issues. In particular Office 2003 (by far the most popular version of Office used by our customers) uses a security level by default that prevents any add-in to work, unless it is installed on a trusted location.

On top of that, there are a number of different issues that can prevent an add-in to be properly installed, including trying to install it when the host application (Word or PowerPoint) is running, not using an administrator account, and several more.

Whatever the problem, the result is always the same: The toolbar is not shown, and the user has no idea about what might be wrong because there isn’t any error message displayed.

It is impossible for us to know what proportion of our potential clients have had this problem in the past. According to our uninstall survey it has been the most common cause that has prevented our potential customers to try the software.

Therefore it has been a huge problem for us. We have tried several approaches to solve it, like including a topic in the help file, a page in our web site and two demos, explaining the procedure to setup the addin.

Sales for our add-ins have been dropping consistently during 2008, although the volume of visits to the MomSoft site and downloads of our add-ins have remained fairly constant during the period.

The solution?

Finally, around a month ago I had an idea. It is not very difficult to make an utility that looks at all the appropriate places on a computer system to try to determine if an add-in is correctly installed, registered, not disabled and if the security setting of the host Office application is preventing the execution of add-ins.

The result is what I have called the "installation check utility", for lack of a better name. An screenshot of the utility is shown below:

We released new versions of FormsAssistant and PowerTOC last weekend. The new versions include the setup check utility and execute it immediately after finishing the installation. Sales have returned back to the levels of 2007, so maybe I have been able to nail down the problem. Of course, a week is not enough time to know.

I keep my fingers crossed.

From time to time a user contacts us with questions or suggestions that immediately turn on the proverbial light bulb on top of my head.

Why didn’t it occurred to me, if it is so obvious?

The last time it has happened to me was when a user complained about PowerTOC insisting in treating Normal slides as normal slides and Title slides as title slides.

Well, it seems obvious to me, was my first reaction. It’s the right thing to do, isn’t it?

Wrong!

I was wrong, of course, at that user made me realize it. So, please bear with me while I explain …

The immutable law of software development

First, let me digress a little to show my point.

The other day I was in the NAB trade show in Las Vegas. My client sells (among other things) a radio automation software, and I took advantage of a little free time to have an engineer demo the application for me.

During the demo he explained to me the difficulties they had with this particular product line, so different to their other lines (radio equipment, i.e. hardware). It seems they get the strangest requests to modify their software to suit the needs of their clients. He pointed out that they lose sales because they can’t run their business as if it was a garage, making custom work for each potential client.

I explained to him that they could take advantage of this fact, making their automation system extensible and creating a community of independent developers that could be hired by their clients to do the needed custom work on top of their standard software. That way everybody wins: they get the sale, the client the odd feature, and a number of micro ISV get business.

The funny thing is that he saw this as a problem, while I have always thought it is one of the greatest advantages of the software business. One of the first lessons I learned when I started MomSoft is:

Software is used for purposes completely different to what the designer had in mind when creating the software.

I recently read an article (I seem to recall it was on PC Magazine) in which there was a great example: using Excel to make tables and lists as opposed to do number crunching and what-if analysis. That should be now the primary use of Excel. The Excel team has taken good note of this use, and Excel includes a number of features best suited to this use.

Back to PowerTOC

I designed PowerTOC, as I always do, with the intention of solving a personal problem. I want to include a Table of Contents on my presentations, but PowerPoint does not include the feature. So I made it.

But of course I designed PowerTOC to handle the kind of presentations I do. I have created and fine tuned over time a number of templates that include layouts to separate the different sections of the presentation. For that reason, PowerTOC notes the layout used on each slide when creating the Table of Contents to determine if a slide is a title slide or a normal slide.

For some reason, the organization of my user does not work that way. They only use Normal slides, and they want to organize the Table of Contents of their presentations, according to the content of the slides, not their layout. And why shouldn’t them?

Introducing PowerTOC version 2.1

The result is the brand new version of PowerTOC we have just released. This new version includes a way for users to overwrite the standard logic used by PowerTOC to determine if a slide is a title slide or a normal slide. It still looks for the layout of each slide, but users are given the possibility of forcing a Normal slide to be considered a title slide. Or, if they want to, they can do the opposite, treating a Title slide as if it were a normal slide.

I know it sounds confusing. Again, this is a consequence of my original design. Since PowerPoint used to have just two layouts: title and normal, I used the same names for the Table of Contents.

For a Table of Contents it probably makes more sense to use Level 1 and Level 2 items. So, in other words, PowerTOC convention is to treat slides with a Title layout (and Section layout on PowerPoint 2007) as Level 1, and all other slides as Level 2. I think that at some point in the future I will change the definition on the program.

I want to thank this user (I haven’t asked him for permission to use his name) for the comments he made that have been the basis of this enhancement to PowerTOC.

And the funny thing is that I find I am using this new facility myself. I feel relieved not to have to rely on the layout of the slide to properly create the Table of Contents of my presentations.

About monaSoftware

I guess that the creation of this blog comes just in time. I have been finally able to catch one of the more elusive bugs I have suffered as a developer and I’d like to take the opportunity to tell a little story about how did I catch this bug.

The purpose of this blog is primarily to supplement the information contained in the web site of my software company MomSoft. Not just informing of new releases and explaining obscure, or at least unusual, ways of using the software, but commenting in computing in general (usually Windows related, but not necessarily)

The bug. A succinct description

For these of you that don’t know it, Control Runner is our most beloved product. It was our first product (it was called MomShell at these times) and we have been selling and enhancing it for more than nearly 15 years now.

Control Runner, being so mature as it is, works very nicely. There are just a couple of glitches that we have not yet been able to solve, mostly related to the handling of icons of the targets of the program buttons. This problem requires a complete change on how are icons managed, so it will have to wait until we release version 4 in a few months.

But, from time to time we were reported a bug that caused the configuration of Control Runner to be lost. Some months we received one of these reports, some months we received none.

Now, this is a very serious problem. A typical Control Runner user has many many items configured on Control Runner. At the latest count I have nearly 200 of them on the development computer (much less on my normal working computers). Reconfiguring Control Runner from scratch is, to say the less, a pain.

For any one familiar with programming the worst case of bug is the irreproducible bug. This is bug that seems to be alive and not related to your one code. It happens, apparently, when the bug so wishes as opposed to when the program flow reaches an statement that has an error, or when the algorithm you are using reaches the point where it is wrong. For the software developer bug hunting usually involves setting up the exact same conditions that cause the bug to appear and use a magnifying lens (also known as a debugger) to see what is happening.

This was not the case. Our users were unable to describe what conditions caused the configuration to be lost. No error message, no computer hangs before. Nothing. Nada.

So, I had to figure it out.

The history of a frustration

I made an assumption. For me it was clear that the problem was that, somehow, Control Runner was not saving the configuration files correctly. Therefore they would become corrupt and the next time the computer started Control Runner would encounter an error and would restart with a default configuration.

I examined the code used to save the configuration and tried several tricks to try to catch this elusive bug. But nothing worked. It looked as if, after all, Control Runner was able to save the configuration files without problems (which is true). But I knew better. I knew that there had to be a problem because the configuration files were getting corrupt.

I asked my users to send me their configuration files to try to reproduce the problem. I wanted to see what kind of items could be causing the files to become corrupt. Unfortunately, when the error happened, the old (possibly corrupted) configuration files were overwritten with the new, empty files.

So, I made a backup of the configuration files before saving them and asked users to send me the backup files. It didn’t work either. The configuration files contained just normal items and I was able to open and save them without any problem whatsoever.

The solution. So simple

Then, one day I received the following message from a user:

I find at times CR loses all of it’s settings and just opens with the two default buttons. The only way to get things back is to re-load a backup set of files. I thought this might be due to some failure in writing the data files out at the end of a session but I now find that it is a problem at startup, not closedown. For some reason the program fails to read the data files and, of course, when I close it down then it wipes all the data away. If I make the data files read only then I can restart CR and it reads them perfectly.

And that was it. The problem was not that Control Runner was corrupting the configuration files when writing them, but rather that it was not reading them some times. The result was very similar, old configuration becoming lost. But the cause was completely different.

The lesson I have learned is: “When you are completely unable to find any problem in the particular code that you are staring at, no matter how hard you try, maybe the problem lies elsewhere“.

I still don’t know what is causing the problem. I suspect that some systems have too many processes running at startup and the file operation system used by Delphi stops waiting and simply returns without reading the file. I will investigate the matter further in the future.

Whatever the reason, solving the issue that has had me puzzled for years was just a matter of minutes. The user is notified if the configuration files seem to be wrong. This introduces the delay needed for the computer to finish the other tasks and, on the second try, the configuration files are read correctly.

Easy when you know where to look.