UMPITYGRUMPITY.COM!

I had an idea just now. I saw the problem when I saw a coder complaining in IRC about new programmers who make a cms blog and don’t include a time-date stamp.

The problem: New developers don’t always have the whole picture for their web app’s features.

The solution: A central repository of feature and idea characteristics.

Imagine a web database full of web app features that are used in many web sites. You look up blog for example, and find the Time-date stamp characteristic, the permalink characteristic, the categories and comments characteristics.

Having a member driven cross-referencing content system would enable this to be a valuable resource to new developers.

Well, I haven’t been researching much in the way of this program’s features. I have however, been tinkering with some other AutoHotKey hotness. Lol. I kind of think I should give up on this idea since it would be too difficult to achieve all of it’s most useful goals, and for this: Axem - AutoHotKey Scripts Manager and others like it..

There are other scripts that are coming together that do a lot of the main functionality of the GreaseGeek/Better Windows idea, but without the single AHK instance feature. That dreaded feature seems unattainable after as much research as I’ve done so far. At least without a lot more work than I am willing to contribute at this time. Plus even if it gets done, it may cause other side-effects.

I’ll probably see what other people in the LH coder’s group have to say, and see if anyone wants to take it over.

I spent some time last week looking at some alternative execution methods for the scriptlets. Yesterday in particular, I looked at separate processes and also execution as DLL functions. Yes, DLL functions. I saw that running dll’s accomplishes a lot of what I’m after for the scriptlets to be run in the greasegeek/better windows app, but in it’s own process or thread. The trouble is, how practical is it? I’m still looking.

In my tests, I could not simply compile a script and then start it by doing a DlllCall to the exe’s “Main” function or any explicit function for that matter. I also could not just rename it to a .dll file and get anything to happen that way. There are other ways of getting things to run with the DllCall method, which is why I’ll still be investigating it. I’ll have to look at the AHK forums and see if anybody has been able to get AHK compiled exe’s to run from that command. The method supports running EXE’s so in theory it should be a clear possibility to run an AHK that’s compiled.

Another thing I looked into was multiple threads for the scriptlets. The problem with that is that AHK is not multi-threaded in the traditional sense. It simply pauses separate threads to run parts of another for the moment that it needs to run, then resumes the other that it was currently processing. In short, it runs only one thread at a time, and will put as many as there are aside from one that gets processed now, on hold indefinitely until that thread is done with what it’s doing.

As you can see, turning on and off the separate threads of each scriptlet is not in the least ideal, and I would say completely unacceptable for most scripts. This is why I’ve looked at ways of running each scriptlet in it’s own process (via either by autohotkey.exe, or by a DllCall, or otherwise). This is my main focus at the moment, but perhaps I should just go ahead and settle for the AutoHotKey.exe approach for now and worry about getting it more ideal later.

It looks like the tentatively named “GreaseGeek” app that I’ve started might already be getting an official name soon. It’s looking Better and better all the time…

The official name will be used in the upcoming development journal entries. So keep an eye on that.

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.