UMPITYGRUMPITY.COM!

Sunday, September 28, 2008

I have created an initial working set of code and file/folder structure that allows for including separate AHK files within a folder. There are a couple of caveats to this method and it brings to mind that I should investigate goals for making the app UNOBTRUSIVE to the scriptlets, and making each scriptlet unobtrusive to the others that are loaded.

Caveat #1: Including files this way makes all included scriptlets part of one another, and potentially breaks some.

In my tests, I have two test scripts included, a Disable Win Key scriptlet, and a Hello World scriptlet. Both run something when a hotkey is pressed. The problem is that the Disable Win Key scriptlet’s hotkey performs the same as the other scriptlet’s hotkey… saying “Hello World” in a message box. This is due to the way hotkeys in AHK can be layered and tied together. The script contains only one line: LWin::

With this open-endedness we find that instead of LWin doing nothing, it finds the next available code to execute, which by order of inclusion, is the Hello World scriptlet.

This is a problem for the app as it will nullify the benefits of the main goal here.

Caveat #2: This method of scriptlet inclusion does not apparently allow for UN-inclusion for the included scripts. The most useful way would allow for un-inclusion, but a work-around is available…just not as elegant as this.

The work-around would be to rewrite the scriptlet includes file, and restart the app. All unwanted scriptlets would be unloaded from memory and only the wanted ones would be left, albeit restarted, which may not be what some would want.

Proposed goal: To find a way to include each scriptlet in it’s own process, and then that way we know how to start, restart, and kill the processes. Then you should have true and complete Unobtrusiveness. However this may bring another caveat. The downside may be that we lose the ability to narrow down all separate sets of AHK resources to just one. More research is needed.

I’ve been using a LifeHacker home-brewed app called Texter to quickly replace text that I might find myself typing a lot. I’ve already made two bundles that I can see myself adding to regularly; Logins, and Me.

What you see in the picture above is my own Texter management window. It shows my Default bundle in the bundles list, plus my own custom bundles. The Me bundle contains any personal info about - you guessed it - ME. I’ve chosen to go with a somewhat universal programming classes format, so all I have to do is type in me.whatever and press enter or tab and the info comes up automatically. For instance, me.age{Enter} will quickly put 28 into whatever I’m typing into.

It’s actually quite an advanced little app in fact. I’ve found that I can store not only my username and passwords for web sites, but I can have it automatically scripted to log me into the site as I type in the trigger phrase. One example would be for this site. All I need to do is type ::log.ump into the username field of the login form and BOOM - it’s logging me in. It’s not the most secure place to store logins of course - although it’s better than risking your login identities with some online tools. It just leaves it open to somebody figuring out your Texter hotstrings on your actual computers. For me, I’m willing to take that chance since I know that no one else uses my computer.

So, after this brief initial playing around, I am certainly convinced of it’s usefulness. I should mention though, that I’ve noticed a bug that semi-crashes the app when I use the global disable hotkey. Another strange thing is I’ve seen it try to auto-type stuff I haven’t made hotstrings for, like the word “although” when I just type altho.

Texter is a free app by Adam Pash, made using AutoHotKey (my favorite!)

Texter via LifeHacker