For the unfamiliar, the Exec method of WshShell (used in Windows scripting) runs an application and provides access to that application's standard streams as TextStream objects. The problem with this method is that the blocking behavior of these streams is not defined (as noted in the comments on the StdOut property) and, more importantly, is impossible to use safely. The problem, familiar to anyone who has dealt with reading and writing to child programs, is that it is very easy to block while attempting to read from (or write to) the child process. What makes this problem worse is that TextStream provides no method for dealing with blocking; there is no way to set non-blocking mode or to check if input is ready to be read or to check if it would be safe to write (at least, none that I am aware of).

As a demonstration of the problem, consider the following applications. First, the child program (written in C):

Second, the attempt to read the output of this program from a script (written in JScript): The idea was that the AtEndOfStream property might indicate that there is no more data to read. If you attempt to run this program you will find that that is not the case. Instead, AtEndOfStream indicates that no more input will ever be read. So, the script spins waiting for more output (or the end of output) while the child program is blocked writing to stderr and we are deadlocked. So, what do we do? We can interleave reads to stdout and stderr, but we would still block if the buffer is filled on one of the streams and empty on the other. Unless we can predict the output of the program, or the amounts of information printed to its stdout or stderr will be small enough to not cause it to block, there is no way to safely run the program (again, that I am aware of).

The solution that I came up with (which has its own drawbacks in terms of performance), is to write the program output to files, then read it back in the script once the program has finished. This solves the deadlock problem at the expense of decreasing the performance by requiring the output to be written to disk as an intermediate step (although the OS may not flush it to the physical disk). The code for this solution is presented below:

Note that if the script will not continue to work while the program is being run and nothing needs to be written to the standard input of the program, it would be better to replace Exec with Run, which can wait for the program to finish without the sleep/wait loop.

Remember, Don't ever WshShell.Exec a command directly if you are not sure of its inputs and outputs and your script deadlocking would be a problem.

After some moderate difficulty (mostly due to bugs 507536 and 552480) I have finally managed to setup Eclipse as a build environment for Apache Tomcat.  The process is as follows (Note that $DEVELSERVERDIR can be anything/anywhere that you have access to as a normal user):

1. aptitude install eclipse tomcat6-user
2. Install Java EE Development Tools plugin from the Eclipse WPT Project
3. tomcat6-instance-create $DEVELSERVERDIR
4. cd $DEVELSERVERDIR
5. ln -s /usr/share/tomcat6/lib
6. ln -s /usr/share/tomcat6/bin/bootstrap.jar bin
7. cp /var/cache/tomcat6/catalina.policy conf
8. Configure tomcat and eclipse to your liking and add the Tomcat instance to the Eclipse servers list

At this point you should be able to import/create projects which can be run on your local server instance. (If not, you are in the same boat I was in this morning... and best of luck to you)

The HTML select element has received much criticism when used for multiple selection over its usability problems. Although it may be simple enough for experienced users, it must be explained in detail (repeatedly) to the less experienced users, who will always find its behavior to be unintuitive. Recently we have come up against this problem and are attempting to work around it.

For some useful background and some great alternate implementations of multiple-selection see Ryan Cramer's analysis and replacement ideas as well as a jQuery Simple Multi-Select plugin which offers an on-demand replacement for the select multiple elements.

The approach that I took was to attempt to leave the select element alone as much as possible, since it is widely recognized and understood by HTML veterans (and already integrated in huge amounts of legacy code), and make it a little more user-friendly by removing the requirement of holding Ctrl to select multiple options. With the modifications in place, clicking on an option will toggle that option between selected and un-selected, while holding Ctrl or Shift will result in the same behavior as before. The solution is written in JavaScript with jQuery (although there is no reason it couldn't be reworked to remove the dependency on jQuery) and was completed without any browser sniffing (only feature-detection).

The script can be found in the forge on the Improve Multiple Select project page. The script can be directly downloaded from the files section (I suggest against directly linking to it - since the location may change). As always, feedback, suggestions for improvement, bug reports, etc. are greatly appreciated.

I recently encountered the following error in Microsoft Access 2000:

Apparently this is a catch-all error for any condition where the database engine (or presumably one thread of the engine) is busy completing a task and something else (such as a VBA macro) attempts to perform a function which requires the engine to perform some task. It is horribly difficult to track down, due to the lack of internal debugging interfaces in Access, but check for macros which may be updating visual elements in a form and getting into a loop (for example, OnCurrent actions cascading in a loop or likewise). In my particular case, the error was only triggered when a filter was applied in a form which contained a subform with a field whose default value depended on a field in the parent form. Once I removed the default value from the field in the subform, the error disappeared. (Note also that this only occurred in Access 2000, not Access 2003)

Good luck in tracking down the source of this error if you encounter it.

I recently encountered the following message in Microsoft Access 2003 when attempting to update any column of a linked table (linked to an MSSQL2005 DB): The interesting part of this story is that there really shouldn't be a write conflict in the data because the linked table in question is in a DB on my local computer which is only being accessed by Access and has no triggers which could be confusing Access. Further investigation, and a useful thread on Bytes, revealed that the problem was columns in the linked table which have the datatype BIT and was allowed to be NULL. Changing the columns to BIT NOT NULL and refreshing the linked table in Access solved the problem.

Update: KB 280730 covers this issue.

I recently encountered the following error message in Microsoft Access 2003: After further investigation, as suggested by a thread on microsoft.public.access.forms, the problem appears to be related to duplicate columns in the form Record Source. However, the error is not limited to simple duplicate columns. In my case, the duplicate name was the result of a table join where the compound names were distinct (i.e. Table1.Col1 and Table2.Col1), but the simple column names were not, which resulted in the error. Perhaps I shouldn't be using joined tables as my Record Source... perhaps.