Run an app in the background from a batch file

To save myself from typing "otepad" a few times a day, I put together a simple batch file, "n.bat", that would just run notepad.exe with the specified command-line arguments (if any). The file "n.bat" consisted of just a single line: @notepad.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

(The leading "@" character just causes the command not to be echoed to the command prompt window, which makes things look nicer; the "%1" through "%9" are the environment variables for the first 9 command-line arguments, which should be more than enough for any scenario that I'd ever use Notepad for!)

This worked fine, except that the command prompt window would wait/hang until the Notepad instance exited. (When n.bat was run from the Start | Run dialog, an empty Command Prompt window would appear until Notepad exited.)

To resolve this problem, I used the start command: @start notepad.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

Error in MSDN docs for CString::Find()

While looking at the MSDN documentation page on the CString::Find() method (C++ MFC), I noticed some information that appears to be incorrect.

The signature of the method is:

int Find( TCHAR ch, int nStart ) const;

The comment on the nStart parameter is:

The index of the character in the string to begin the search with, or 0 to start from the beginning. The character at nStart is excluded from the search if nStart is not equal to 0.

(Emphasis added by me.) If the bolded part of the statement is true, is it just me, or would it be impossible to use the Find method to search a string beginning with the character at index 1? :-)

I tested the behavior of the method in a simple C++ console app using Visual Studio 2005. The character at nStart is indeed always included in the search, even if nStart is nonzero.

I reported this issue to Microsoft via their web feedback form, and got a reply that the issue has been forwarded "to the appropriate Microsoft group for review." We'll see if any changes are forthcoming!

Bugs in Google Toolbar v2.0 beta for Firefox?

Earlier today, I installed the Google Toolbar v2.0 beta update for Firefox. I've noticed a couple of problems since installing it:

Alt+g

The Alt+g keyboard shortcut to focus the search field on the toolbar no longer works. I can see why this was missed during testing because for most Firefox users, Alt+g opens the Go menu. However, in my copy of Firefox, I have the Go menu disabled, which I did for the specific purpose of allowing Alt+g to work with the Google toolbar instead (as it does in the Internet Explorer version of the Google toolbar)!

I reported this issue to Google via their contact form for the Toolbar, so hopefully they'll fix it in a future update.

Update 4/7/2006 8:30pm: I got a response back from the Google team via email. They let me know that Alt+s works in Firefox to focus the search field. I hadn't previously been aware of this; it sounds good to me, since Alt+s is even easier to reach on the keyboard with my left hand than Alt+g! Now I'll just have to train myself to use it...

It is kind of unfortunate that the Firefox and IE versions of the Toolbar use different keyboard shortcuts; I wonder if IE could be made to use Alt+s as well for consistency.

Publishing Posts on Blogger

In my previous blog post that I made earlier today after installing the Toolbar update, the post wouldn't publish properly; when I clicked the Publish button, the browser just got stuck in a loop trying to publish the post; the post showed up in my list of posts in the Blogger "control panel", but it didn't actually show up in the blog itself.

I ended up opening up IE instead and publishing the post from there, and it worked with no problem.

I'm not sure yet whether the Google Toolbar update is somehow to blame for this problem. We'll see how publishing this post goes!

Update: Publishing this post from Firefox with the new Google Toolbar installed worked with no problem. Looks like maybe it was just a temporary issue with the Blogger site itself earlier today, as I haven't made any other changes on my machine since then.

Fix: "ERROR: Names must not begin with a number" from caspol.exe

I ran into an error when using caspol.exe (a command-line tool provided with the .Net Framework that can be used to establish trust with a particular URL, among other things) to try and establish trust to a specific IP address:

ERROR: Names must not begin with a number

At first, I thought that caspol just couldn't be used to establish trust to an IP adddress (as opposed to a named server). However, the problem turned out to be that I was using the -name command line option to try give the new code group the same name as the IP address I was establishing trust with -- and this is what the error message was complaining about.

So the resolution is to either use a name that doesn't start with a numeric character, or to just leave the -name parameter off the command line entirely (which will result in an unnamed code group).