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

Good to know I’m not crazy…

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.

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.

// 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.

// 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.

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…?

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…

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:

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”.

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.

"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.

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.

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.

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