Ishida Tech Solutions, Ltd.
The personal and professional home of Brad Ishida

If you’re having the same problem I was, this is your lucky day because this solution is nowhere to be found as far as I can tell.

I recently had the following symptoms on a Windows XP box with multiple users.

1) The desktop icons for files would not appear for new files without manually refreshing the desktop by pressing F5 or by selecting “refresh” from the right-click menu.

2) When saving files from a web browser, the files don’t appear on the desktop without a manual refresh.

3) When moving files from the desktop to the recycle bin, the file icon remains on the desktop until there is a manual refresh.

4) The problem only occurred for one user and not everyone with an account.

The solution:

The registry value for the desktop for this user was incorrect. The value contained the variable %ALLUSERSPROFILE% instead of the correct variable %USERPROFILE%. I changed this value to %USERPROFILE%\Desktop

1) start->run->regedit

2) Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders and check the value for Desktop. If it looks wrong, you can fix it and this will most likely fix your desktop refresh problem.

I recently formatted some external drives in Vista and then moved them to an XP machine where they would not mount. When I went to reformat them in XP, I found that I could not format the disks at all. The disk management tool (control panel->administrative tools->computer management->disk management) listed them as “GPT protected” and would not allow me to erase them.

The solution was to use the command line tool “diskpart” to clean the disk so it could be formatted like normal in XP.

1) start->run->cmd

2) diskpart

3) list disk

4) select disk # (select disk 4 for example)

5) clean

6) exit

Now the disk will be available to format using the Disk Management tool.

I recently had a problem in FireFox 3 on my MacBook Pro (running 10.5) where I couldn’t save any files. “save link as”, “save image as” or anything that would normally launch an associated program such as Acrobat for a PDF file stopped working. FireFox would save a “.part” file but not the intended file. I solved this problem by the following:

1) close FireFox.

2) Find the “downloads.sqlite” file. Look in your home directory and then Library->Application Support->FireFox->Profiles->xxxxxx.default->downloads.sqlite.

3) Rename this file. Put a “.bak” on the end of it or something.

4) Start FireFox and let it recreate the downloads.sqlite file. Everything should work again.

Just a quick tip:

Start->run->cmd then type taskmgr.exe

This can come in handy if you’re using remote desktop from a Mac or have some other situation where you just can’t press CTRL+ALT+DELETE.

If you need to create a tool to view the progress of a file upload from an HTML form to a Perl CGI script, there are a few things you’ll need to be aware of. I will explain the basic blueprint for what needs to be done to accomplish this task. One of the first challenges you might notice is that when you try to detect the progress from your CGI script, the file has already been uploaded by the time you can try to do anything. This is due to the way that the form data is fed to the CGI script. The key to this problem is to “capture” all the data that is being sent to the form. By the time you’ve declared your variable to hold your CGI data, the opportunity to view the progress of the file upload has already been lost. You need to capture the data being posted to the script before declaring your CGI variable.

######################################
#you need to detect the progress of the file upload before you declare your
#CGI variable
use CGI;
my $q = new CGI;
#at this point in your script, the data has already been transferred to the server
#and you cannot show the progress in real time
######################################

#!/usr/bin/perl

#keep track of how much data transferred so far
my $transferred_so_far = 0;
#set an interval for how often the upload progress will be updated
my $noticelimit = 10240; #this is 10KB, make larger to decrease reporting overhead
#capture the form data and write it to a unique file. This script has already safely determined
#a unique $username based on a login. Your script may have another way of handling this.
open TMP, "> ./$username.post" or die "cannot open file";
while (read (STDIN ,$LINE, 4096)) {
    #this keeps track of how much has been uploaded so far
    $transferred_so_far += length($LINE);
    #we print the data to a unique user file, so we can re-read from a separate progress script
    #while we are busy in this loop, another progress reporting script will read this file and
    #report the data transfer in a separate pop-up window
    print TMP "$LINE";
    if ($currentnotice > $noticelimit) {
        #at every interval of $noticelimit, we will write the upload status to a unique file
        open NOTICE, "> ./$username.notice" or die "cannot open file";
        print NOTICE "$tmpsofar Bytes transferred so far..";
        close(NOTICE);
        $currentnotice = 0;
    }
}
close(TMP);

#now that the data transfer is complete, go ahead and declare your CGI variable and read in
#the captured data from your temp file to standard in
open(STDIN,"$username.post") or die "can't open temp file";
my $q = new CGI;

Now you are in a position where you can create a separate script that will simply read the contents of the $username.notice file and report what it finds. You can set this script to refresh itself every few seconds and that will serve to show the progress of the data transfer. Placing this script in a small popup window that you can launch when the submit button is clicked for the file upload will handle this nicely.

Recently while helping a client who was doing some software testing of CD-ROM software, a problem was discovered where the application would run on some Windows boxes but not on others. The program gave the error “Run-time error 3041: Cannot open database with a previous version of your application”. This error is usually seen with Access databases, so we started there. The program did in fact have an “MDB” file, so the problem was that the MDB database file was created with some version of Access that was not being handled for some reason.

The solution to this problem was found in the Windows registry. Like most up-to-date Windows XP boxes, this one had the Jet 4 database engine. However, there were missing entries that tell Jet 4 how to handle older databases that would have previously been handled by Jet 3 or Jet 2. To fix this, I did the following:

1) Open the registry: Start->run->regedit

2) Create a key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines and name it “Jet 2.x”.

3) Under the “Jet 2.x” key, create a string value called “win32″ and modify it to contain “C:\WINDOWS\System32\Msrd2×40.dll” (assuming your WINDOWS directory is C:\WINDOWS)

4) Create a key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\ISAM Formats and name it “Jet 2.x”.

5) Under this “Jet 2.x” key, create a string value called “Engine” and modify it to contain “Jet 2.x”.

6) Register the DLL file above and you’re all set. Start->run->Regsvr32.exe C:\WINDOWS\System32\Msrd2×40.dll

These steps tell Jet 4 how to handle Jet 2 databases. You can repeat the steps for Jet 3 databases as well by just using “3″ instead of “2″ in the appropriate places. Also note the file name of the DLL would be changed to Msrd3×40.dll. This fix was applied to machines running Windows XP Pro, Windows XP Home and Windows Vista Ultimate.

I was installing a new KVM switch with some Windows XP boxes and this annoying problem with the Windows XP login screen kept occurring. Sometimes you can’t get the password field on the login screen to take the keyboard focus–the cursor just ceases to exist. I noticed I could get around this by pressing CTRL+ALT+DEL twice. This brings up the alternate login dialog box and the keyboard focus problem goes away. After logging in, there are no more keyboard problems. Guess it’s just Windows being Windows.

This site is fairly new and I’m still getting acquainted with WordPress, but so far I like it pretty well. It’s pretty easy to to keep everything valid XHTML with minimal effort. Now, there’s probably another way to handle this, but… I wanted to create a page outside of WordPress, but still keep it “part of the site” with the same style sheets, layout, etc. I created my new contact page and then I borrowed from my WordPress theme by using “require(’../wp-blog-header.php’);” This allowed me to use the get_header() and get_footer() functions to give my new page an identical look to my blog pages even though it was not created from within WordPress. This also made it easier to incorporate a captcha into the page to help keep my email address from getting crawled. Everything appeared to be working fine, but when I used the W3 Validator, it informed me that my server gave it a 404 not found error. This was strange because the page loads just fine. I grepped through the WordPress files for “404″ and found that WordPress likes to throw server codes a lot using status_header(404). Normally, I would think leaving that job up to the web server would probably be preferable, but maybe WordPress has its reasons and to be fair–it probably didn’t count on me creating my own pages outside of WordPress and trying to use the theme files to do it.

The piece of code doing this can be found in wp-includes/classes.php.

if ((0 == count($wp_query->posts)) && !is_404()
&& !is_search() && ( $this->did_permalink ||
(!empty($_SERVER['QUERY_STRING']) &&
(false === strpos($_SERVER['REQUEST_URI'], ‘?’))) ) ) {
    $wp_query->set_404();
    status_header( 404 );
    nocache_headers();
} elseif( is_404() != true ) {
    status_header( 200 );
}

I just altered that “if” statement to also check if the REQUEST_URI file or folder exists in the local path. This solved my problem well enough and now the 404 codes for my home-grown pages have disappeared and all is well again. Just replace or set $YOUR_LOCAL_WEB_ROOT with the local path to the root of your web directory. Here is the altered block:

if ( (0 == count($wp_query->posts)) &&
!file_exists($YOUR_LOCAL_WEB_ROOT . $_SERVER['REQUEST_URI']) &&
!is_404() && !is_search() && ( $this->did_permalink ||
(!empty($_SERVER['QUERY_STRING']) &&
(false === strpos($_SERVER['REQUEST_URI'], ‘?’))) ) ) {
    $wp_query->set_404();
    status_header( 404 );
    nocache_headers();
} elseif( is_404() != true ) {
    status_header( 200 );
}

Nothing quite compares to the vi editor when performing fast edits of files on a Unix command line. Tip “#0″ would be to know your modes. Command mode (press ESC key) interprets your keystrokes as commands (for example, “j” moves down). Insert mode (press I key) lets you actually type stuff into your file. Line mode (press “:” key) lets you do cool stuff like search and replace. Here are my favorite tips.

1. In Command mode, CTRL+g shows you current line information.
2. In Command mode, forward slash “/search_term” searches down. Question mark “?search_term” searches up.
3. In Command mode, “Number” followed by capital G takes you directly to the line number (23G takes you to line 23).
4. Need to delete pesky ^M characters from a Windows text file? In Line mode you can do “:%s/^M//g” (to type the ^M you need to hold down CTRL and then press V then press M)
5. Need to quickly comment out the next bunch of lines in a Perl script? In Line mode, this will comment out the next 5 lines starting with the current line. “:.,+5 s/^/# /g”
6. Need to uncomment those same lines? “.,+5 s/^# //g”
7. In Line mode “:set ic” will make searches case insensitive. “:set noic” will change them back to case sensitive.
8. In Command mode, capital “G” takes you directly to the end of the file. “$” takes you to the end of the current line.
9. In Line mode, use “c” with a search and replace to make vi ask you to confirm each replacement (example: “:%s/Breed/Bread/gc”).
10. In Line mode, you can delete all empty lines with “:g/^$/ d”
11. To search for characters such as the Microsoft Word curly quotes or any non-standard character that displays something like “\xe2\xe2\xe3″, you can use CTRL+x to type them (example: CTRL+x followed by “e” followed by “2″ will print “\xe2″)

Apparently there is some logic built into the Microsoft Access 2007 find/replace tool that will automatically select “search fields as formatted” if it thinks you need to do that. From what I read on Microsoft’s site, it sounds to me like it should only automatically select this option if you have certain input filters defined. However, on a table and form I used today that had no input filters, the “search fields as formatted” option simply would not go away. If I turned it off, Access would turn it right back on with the next search. This can be a real problem because a Find action can take close to 10 seconds with this option on and rarely takes more than 1 second with this option off.

The only “solution” I could figure out is equally stupid as the problem. However, following these steps did make the problem go away for the remainder of the session.


1) Open your form, click on the field you normally search on and press CTRL+F to bring up the Find tool

2) Turn the “search fields as formatted” option OFF and then perform a search for something that won’t be found (some random string of 30 numbers should do the trick).

3) Access will tell you it couldn’t find anything. Close the Find tool. Close your form. Re-open your form and the “search fields as formatted” option will stay off for the rest of the session.


If this doesn’t work for you, the “input filters” thing might be where you want to investigate next. Access will turn this option on if you have input filters. Also, if you search the entire form as opposed to just a single field, Access will turn this option on so it may be unavoidable in that scenario as well.