ThickBox Demo Project

As a follow-up to my recent postings about ThickBox, I've created a demonstration page, which succinctly summarizes my work on ThickBox to date. It also provides some improvements over what I've written previously. Plus, you're able to download all of the code as well, which should especially help people learning jQuery and ThickBox anew.

Further Thoughts on ModalPopupExtender to ThickBox Conversion

I added an important paragraph to my earlier post on this subject, which reads as follows:

Let me also say from the outset that not all dialog boxes can be converted over easily. To date I have not found a way to get rid of the Modal Popup Extender if the dialog box depends on server-side code for its operation. The basic problem is that if a postback has to occur then the ThickBox dialog box will disappear, at least temporarily, which is unacceptable. Perhaps there's a way around this but I have not yet discovered it. So make sure you have a good backup before you proceed with any conversion attempt!

ThickBox was clearly not created with ASP.Net in mind. My conclusion is that it works great for simple dialog boxes. You'll end up with a smaller footprint, which will speed up your app. But if there's something more sophisticated necessary, whether it be more complex validation or any server-side code that needs to be run, then I do believe that the ModalPopupExtender is the preferred choice.

I hate the idea of having to include both jQuery and the AJAX Control Toolkit but I don't see a way around it at this time. Perhaps a developer, much more Javascript savvy than me, will build a jQuery Plugin that will truly replace the ModalPopupExtender!

Visible = false vs. display:none

I learned a painful little lesson today which hopefully will benefit others.

Most every ASP.Net control has a Visible property, which can be set to either 'true' or 'false'. If you've ever set it to 'false' and look at how it's rendered, you'll see this HTML property: style="display:none"

But when you're using the AJAX Control Toolkit, the two ways of hiding a control are not always equal.

For example, when I use the ModalPopupExtender to display a dialog box, I frequently define the TargetControlID with a dummy button. Why? So that I can programmatically control when the dialog box is displayed. Here's a very straightfoward example:




The only reason that buttonDummy exists is because the ModalPopupExtender must have a TargetControlID defined. And since you don't want the user to see this dummy button, you need to hide it. But doing so by setting Visible="false" internally seems to mess up the logic of the ModalPopupExtender. When you're expecting the dialog box to display, the code runs but nothing happens.

Modal Popup Extender, StreamWriter

I've made a small, but useful enhancement to the Waikiki condo rental site I built. The owners of the condo have reservations well in advance so only need to find new people a few times a year. As such, they don't want people constantly writing them, saying such things as, "Hey, can I rent it next week?" This is a waste of time for the writer and for the condo owners.

One way to solve this would be for them to keep me updated about when it was available. But that would mean that I'd have to constantly update the site every few months. Sorry, not interested.

So I built a mechanism whereby they can customize a special message that appears when the user clicks on the Contact page. You can view the current message here:

What you're seeing is an effect provided by the ASP.Net AJAX Control Toolkit. It's called the Modal Popup Extender. It lets you display a Panel (ASP.Net's equivalent of a "Div") that contains whatever controls you want in it. In the example, there are only 3 objects:

1. The panel, which displays a background image
2. A label, whose text is customized
3. An "OK" button

The "disabled" background effect behind the popup panel is caused by the extender referring to this simple CSS entry:

.modalBackground
{
background-color:Gray;
filter:alpha(opacity=70); /* For IE */
opacity:0.7; /* For Firefox */
}

There's a new Admin page that I added, that is accessed via a link at the bottom of the page, followed by a required password. I could have implemented a full Login mechanism but thought it overkill for this simple application that will forever be used by only 2 people. With that said, I did not embed the password directly in the code for all code files get compiled into a DLL, which is normally accessible by a hacker via the ASP.net "bin" folder. So instead, I embedded the password in the very secure "web.config" file like this:Arriving on the Admin page, one can only add/edit text and press "Submit" :
Implementing all of this was very simple. For example, the code that writes the text out to a file is this:

if (File.Exists(srcFile))
{
StreamReader streamReader;
string txt;
streamReader = File.OpenText(srcFile);
txt = streamReader.ReadToEnd();
streamReader.Close();

if (txt != "")
textBox1.Text = txt;
}

In my local test environment it worked perfectly. But intuitively I knew it wouldn't work right away on my GoDaddy hosted web server. Why? Three words: File write permissions

The text file in question resides in its own folder. This keeps it separate from the code and markup files. What I had to do was go into the GoDaddy File Manager, select this folder, and alter its Permissions so that Write was enabled and not just Read. Without doing that, the file is forever locked from any changes, short of FTP'ing in a new file.

Just some simple techniques here but together they allow for a nice and useful web application!