matthew ephraim

It’s a (Firefox) bug!

September 30th, 2008

Sometimes it’s a relief when you find that a bug you’re trying to fix in your own code is actually related to someone else’s code. I’ve been trying to figure out why large text blocks inside of an xml file keep getting truncated when I read the file in with JavaScript. Turns out it’s Firefox Bug 452675.

Bug
FF 3 creates multiple #text nodes for elements with well under 
4096 characters of text data

Good to know I’m not crazy…

Keep tinyMCEPopup From Loading the Popup CSS File

July 12th, 2008

This week I have been developing my first TinyMCE plugin. One of the first steps was designing the popup dialog box that would be associated with the plugin. Initially, everything was going smoothly. I had the XHTML and CSS just the way I wanted it and I was ready to move on to the next step of developing the JavaScript that would power the functionality of the plugin.

One of the utility files that TinyMCE allows you to include is a file called tiny_mce_popup.js. Including this file gives you access to a class called tinyMCEPopup. This class provides you with some helper functions that come in handy when developing the dialog box for a TinyMCE plugin. Unfortunately, including the helper file also has a side effect: the helper class will automatically include the current theme’s css file. In the case of my plugin, the css file for the current theme completely changed the way my plugin’s XHTML was styled. And not in a good way.

One solution would have been to modify my stylesheet or alter my XHTML so that the stylesheet didn’t interfere with the way I wanted the page to look. I tried to do this initially, but what I really wanted was for the theme stylesheet not to be included at all. As far as I can tell there’s no built in way to do force the tinyMCEPopup class to not include the stylesheet. So, I developed a workaround that seems to keep the stylesheet from loading without causing any side effects.

The first thing I needed to do was to unset the property that defined the theme stylesheet for popup dialogs. That way when the tinyMCEPopup class tried to include the file, it wouldn’t find anything to include. The location of the popup stylesheet is stored in the settings for the editor instance under editor.settings.popup_css. I figured out that the property could be unset at the beginning of the command that was executed when the button for my plugin was clicked.

JavaScript
editor.addCommand('mceMyPluginCommand', function() 
{		
	// Set the popup css to null while page loads 
	// because my plugin uses its own css
	editor.settings.popup_css = null; 
	...
});

This worked fine, but setting the popup_css property to null caused the stylesheet for any other plugin’s popup dialog to not load correctly. To get around this problem I needed to restore the original popup_css property once my plugin’s dialog box was finished loading. To do this, I simply added a command to the editor that would restore the original popup_css property.

JavaScript
// Registers an event that will 
// Add command to restore the original css file
ed.onInit.add(function() 
{ 
	var origCss = editor.settings.popup_css;
	editor.addCommand("mceMyPlugin_restoreCss", 
                       function() { editor.settings.popup_css = origCss; });
});

The previous two pieces of code could be run during the initialization of my plugin. Finally, I needed to use the tinyMCEPopup class inside of my popup dialog to call the function that restored the css.

JavaScript
// Restore the popup css to the original theme css
tinyMCEPopup.execCommand("mceMyPlugin_restoreCss");

It’s not the most elegant solution to the problem, but so far it’s the only way I’ve been able to figure out how to force the tinyMCEPopup class not to load the theme css file.

Miracle Fruit Experiment Part 3: Fail

July 1st, 2008

Miracle Fruit needs warmth and humidity to grow (so I’m told). My apartment is sunny, but when I started trying to grow Miracle Fruit I didn’t think it would be warm enough to get the seeds started. So, I decided that it might be a good idea to set the seeds out on the windowsill, where it was nice and sunny and warm. I had been doing that for about 2 weeks now, without any trouble.

Unfortunately, it was too good to last. When I came home tonight my roommate told me, with a look of sadness, that something had happened to my seeds. Somehow, my mini green houses had fallen off the windowsill and onto the deck, spilling the seeds and the soil all over the place. By the time I came home my roommate and cleaned up the mess. A lot of the soil was gone and it appeared that the seeds had blown into a hole where no one can escape.

Miracle Fail

To be continued…?

Miracle Fruit Experiment Part 2: Mini Greenhouses

June 21st, 2008

This week, I made some mini greenhouses for my Miracle Fruit. I’m hoping that they keep the seeds warm and hold in the humidity. More waiting…

Miracle Fruit Experiment Part 1: Planting the Seeds

June 15th, 2008

A few weeks ago I read this article in the New York Times about a berry called Miracle Fruit. About Miracle Fruit, Wikipedia says:

The berry is sweet, and contains an active glycoprotein molecule, with some trailing carbohydrate chains, called miraculin. When the fleshy part of the fruit is eaten, this molecule binds to the tongue’s taste buds, causing bitter and sour foods (such as lemons and limes) consumed later to taste sweet. This effect lasts between thirty minutes and two hours. It is not a sweetener, as its effects depend on what is eaten afterwards, but has been used to cause bitter medicine to taste sweet.

I was intrigued, so I bought some seeds. They arrived this week and I started planting them right away.

I bought my seeds from Gold Crystal Garden via Amazon. They took a few weeks to arrive, and, when I they finally came, the instructions indicated that they needed to be planted right away.

I’m not much of a green thumb, so I followed the instructions that someone named Putzer posted at Instructables. Putzer said I needed 50/50 mix of Perlite and Peat Moss. So I mixed up a batch and planted each seed in a small biodegradable carton.

Now I wait…

Add a Folder Menu Item to Start Visual Studio’s Web Server

May 28th, 2008

Most days at work, I spend my time coding with Visual Studio 2008. I do ASP.Net development, and Visual Studio is pretty swell for working with ASP.Net. However, sometimes it’s a little bit…heavy for what I need. Sometimes, I’m just writing some JavaScript and I feel like using a nice text editor (like my current favorite TextMate clone). Unfortunately, when I’m not using Visual Studio it’s not as easy to use one of my favorite features of Visual Studio: the built in web server.

While it’s fairly well known that the Visual Studio web server can be run from the command line, it’s a little awkward to type out the full path to the directory I’m working in when I want to start the server up. Luckily, this can be easily remedied with a quick registry edit that creates a folder contextual menu that will open the web server for a directory.

First, if you’re going to be making changes to your registry Back It Up First

Creating a new contextual menu

Once you’ve backed up your registry, you will need open the registry editor. Click on the start menu and choose “Run…”. Type “regedit” in the prompt and hit enter. Next, you will need to navigate to the registry entry that needs to be modified. The key you will be modifying is located at:

Registry
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell

When you find the key, right click on the shell entry under Folder and choose New->Key from the menu. Whatever you name your new key will be the name of the option that shows up in the contextual menu. When you’ve named your key, right click on it and choose New->Key and this time name the new key “Command”.

registry entry

Click on the Command and you should see a key named (Default) to the right of it. This is the key that tells Windows which application to pass your folder to when you choose your new contextual menu option. You will need to edit the new (Default) key, but the value you enter will depend on which version of Windows you are using and which version of Visual Studio you are using. I entered a key for Windows XP x64 with Visual Studio 2008, but you may need to modify the key for your specific environment.

Registry
"C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\9.0\
WebDev.WebServer.EXE" /port:80 /path:"%1"

The real key, of course, needs to be one line

The first part of the key:
“C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.EXE”
specifies where the web server application is located. This is the part that may be different on your computer.

The second part of the key:
/port:80 /path:”%1″
is the parameter string for the application.
%1 represents the path to the folder that is tied to the contextual menu.

If you’ve done everything correctly, you should immediately see a contextual menu that looks like one below when you right click on a folder.

Contextual menu

Clicking on this new menu option should start up the Visual Studio web server with the folder you selected as the root folder for the site. One caveat is that the web server will throw an error if an instance of the web server is already running for the same port. I still haven’t figured out a way around that.

Windows Contextual Menus Are Inconsistent

May 20th, 2008

One of the many little things that annoys me about Windows is the inconsistency of where items are placed in contextual menus. Case in point: the menu that pops up when you right click on a taskbar item or window. I haven’t done a scientific study, but I’m going to guess that 80% of the time or more the last item in this particular contextual menu is the option to close the window that is being right clicked on. This is what the majority of the contextual menus look like:

Having it as the last item makes sense. It’s probably the most commonly used menu item and it’s an easy target when it’s the last item in the list. The problem is: because that item is listed as the last item over 80% of the time, I start to expect that it’s always going to be the last item in the list. Unfortunately, that’s not always the case.

For whatever reason, some applications list other options below the Close option. Here’s an example of the right click menu for a cmd.exe window:

When I want to close that window, I right click on the cmd.exe item in the taskbar and choose the last item that pops up. But it’s not going to close the window. Instead it’s going to bring up the properties dialog for the cmd.exe window. Now, not only do I need to close 2 windows instead of 1, I also need to always remember that cmd.exe breaks the convention and lists Close as the 4th item up from the bottom of the menu.

Here’s another example:

That’s the right click menu for SQL Server Enterprise Manager. It’s outdated now, but it used to be the main tool for dealing with SQL Server databases. Like cmd.exe, this application also lists an item below Close in the contextual menu. What’s even more annoying in this case is that the item listed below Close is Help Topics. It’s another option that I will accidentally click on instead of the option I wanted, but, this time, choosing the wrong item will start up another application. And, no matter what computer I’m working on, the help application always seems to take a painfully long amount of time to open up.

Now, I would be able to excuse all of this if it was just 3rd party developers who weren’t following the conventions set up by other Windows applications. The problem is: cmd.exe is a integral part of Windows and Enterprise Manager was Microsoft’s official application for SQL Server Databases. So it’s Microsoft that’s disregarding an informal convention and randomly placing items below the Close option. I can only hope that Microsoft plans on dealing with this problem with Windows 7.

Estate Sale Bounty

May 19th, 2008

On Saturday I woke up early and headed to an estate sale down the block from me. I was hoping to find some cheap records or a CD shelf or something. Instead, I found a Fender Vibrosonic amplifier and a Miller Custom pedal steel guitar. I placed a bid on both, thinking that my bid was way too low. But the other guy who had placed a bid didn’t show up, so I won both!

Headstock Pedal steel Packed up Amp Vibrosonic! Tubes Vibrev!

Tame Visual Studio’s Web Server (With Ruby)

May 15th, 2008

Here’s a little Ruby script that can be run on a new Visual Studio solution file. It will turn off dynamic ports and set the root of your site immediately after the hostname.

Ruby
File.open(ARGV[1], 'w') do |modified|
  File.open(ARGV[0]).each do |line|
    modified.puts line =~ /VWDPort/ ?
    %{\t\tVWDPort = "80"
\t\tVWDDynamicPort = "false"
\t\tVWDVirtualPath = "/"} : line
  end
end

Run it from the command line with the input solution file first and the name for the new solution file second.

ruby fix_solution.rb MyProject.sln FixedProject.sln

Taming Visual Studio’s Web Server

May 14th, 2008

When I develop my sites locally using Visual Studio, I like to have the conditions on my local machine match the conditions on the actual web server as closely as possible. Part of doing that is making sure that my urls are formatted the same locally as they will be on the live site. Unfortunately, by default, Visual Studio’s built in web server makes the urls for a local project look a little bit different than they will when the site is actually deployed. This can be remedied quickly with a few changes to your project’s properties.

The Issue

When you first start a new project up in the debugger, Visual Studio will start the built in web server and open your default web browser with a url that looks something like this:

http://localhost:8080/Demo/Default.aspx

There are few problems with this url. First, the web server is not running on port 80, so the url contains the port number for the web server. This is an aesthetic problem, but it can also create issues if you plan on having your site behave different based on values that are found in the hostname. For example, if you have a site that has separate subdomains like “people.example.com” and “places.example.com”, and each of those subdomains shares the same codebase, it’s difficult to test that behavior locally if you don’t have your site running on port 80.

A second problem is that instead of having the root url immediately after the hostname, Visual Studio treats “/Demo” as the root of your site. This causes all kinds of problems if you want to use relative urls. It can also cause problems if you want use a url rewriter that relies on regular expressions to determine where a url goes.

Here’s how you can fix it.

Setting the Web Server Properties

To fix the port number and the site root problems, first open the Solution Explorer tab and select your project in the in the list of items.

Solution Explorer

Next, open the Properties tab and change the “Use dynamic ports” option from True to False. This should allow you to change the Port number to port 80. One issue that I’ve noticed with various versions of Visual Studio, both full and express, is that sometimes you need to close the Properties tab and reopen it before Visual Studio will allow you to change the port number. Finally, change “Virtual path” to “/” so that the root of your site will be immediately after the host name.

Properties

Now, when you start up the built in web server, you should be able to access your local site at “localhost”. No port number or project name after the url hostname necessary.

Creating some urls

At this point, the only url where you will be able to access your local site at is “localhost”. This is fine for simple sites, but I always lke to have a url like “matt.dev” where I can access any sites that I’m running on my localhost. That way, if I need to use subdomains, I can access my localhost using a url like “people.matt.dev” or “places.matt.dev”.

To set up these urls you will need to make some entries in your hosts file. Your hosts file is located at “C:\WINDOWS\system32\Drivers\etc\hosts”. I’ll assume that if you’re running Visual Studio under something other than Windows you already know how to get to your hosts file. Open the file with a text editor like notepad. You will see that an entry like this is already there for localhost:

hosts
127.0.0.1 localhost

Underneath this entry you can add your own urls that will point to your local web server. Like this:

hosts
127.0.0.1 people.matt.dev
127.0.0.1 places.matt.dev


Once you’ve saved your changes to the hosts file, your urls should point to your local webserver.

Finally, if you’d like Visual Studio to use your new urls when opening a website in the debugger, open right click on your project in the Solution Explorer and choose “Property Pages” (what’s the difference between “Properties” and “Property Pages”? That’s just one of life’s little mysteries). Choose “Start Options” and then “Start URL:”. Now you can enter the url you would like the site to start at when you open it in the debugger.

Property pages

And just for fun, here’s a Ruby script that will do most of this for you.