My dad and I went to the Menards yesterday and were looking for many household items including new shower fixtures and new patio furniture. Well, if anyone knows Menards, you know its emmensly huge, and finding things isn't that easy unless you ask. So, as we asked one of the guys working there where patio furniture, I couldn't resist and just say “Here's your sign...”

Dad: “Where's your patio furniture?”
Guy: “For ourside?”
Dad: “Umm, yeah”
Guy: “Ohh, its over there, (pointing) underneath our 2nd floor area”
Me: “Thanks, here's your sign...”

Ohh, good times. Now, whenever I'm around my dad, all I have to do is say “for outside?” and we both start cracking  up.

So, I'm not one to compete with WTF, but I just got the following email and it just completely irked me on how blatently obvious stupid people are:

“I am not able to get the Calendar and TimePicker to look reasonable.    The calendar is long, narrow and ugly.   I can't get the shape to change. The Timepicker does not focus on the times listed. The display area is much bigger than needed to hold the values and you must scroll to the right to ever see a number.  Also,  both Calendar and Timepicker displays allow underlying  'select' boxes to show through.

The controls were very easy to put in and work great but the displays are so bad that they cannot be used..”

How nice of this friendly guy...now, can you imagine what I wrote? Can you believe that it was somewhat nice? What's your verdict...

“I'll take this issue by issue...

 

"The calendar is long, narrow and ugly"

 

- There are many properties to solve this. First off, you can utilize the CalendarWidth property to set a reasonable width to make it not so "long"

- There are also a ton of Style properties (MonthHeaderStyle, DayHeaderStyle, SelectedDateStyle, etc.) that you can set to make it not "ugly"

 

"The Timepicker does not focus on the times listed"

 

- This is a known issue, and will be looked at for the next version.

 

 

"The display area is much bigger than needed to hold the values and you must scroll to the right to ever see a number."

 

- There are a multitude of properties to change how the Time Picker is displayed. For instance, you can change NumberOfColumns, PopupHeight, and PopupWidth to completely control how "big" it is as well as needing to scroll to the right to see all the numbers.

 

"Also,  both Calendar and Timepicker displays allow underlying  'select' boxes to show through."

 

- Yes, I'm aware of this. It's a known imperfection on how "windowing" takes place in the browser. Drop down lists, Listboxes, and IFrames all fall under this category, and take the highest Z-Index precedence no matter what. Consider using PopupLocation along with DisplayOffset[X/Y] properties to move the popups around. If you're still having troubles, you can always set EnableHideDropDown to True, which will hide the DropDownLists and ListBoxes from the page when the Popups are visible.

 

Now, I don't mind constructive critiscm, however it's blatently obvious that you didn't even bother reading the Help, or check out the properties to see if there were things that could alleviate your problems prior to complaining about them. The control is simple to use, yes, but sometimes (for more advanced webforms), more configuration is needed than normal. Others have expressed their concerns like you have (prior to a way of handling them), which is why these properties exist.

 

Also, I would like to point out another great resource, my forums. There are hundreds of posts about questions that you can find information about. You can find my forums at http://www.eworldui.net/forums”

 

How many of you have ever had to make some webpages that have page breaks. (Raising Hand!)

Ahh, I see a lot of you have raised your hand...now, keep you hand up if you've never known how to do this. (Still Raising Hand!)

Uhh huh, still a lot of you I see. Well, worry no more. As I was printing off my vouchers for our upcoming vacation to Florida, I noticed that the page broke at specified areas for printing. So, like a normal interested developer, I had to do a "View -> Source" to see how they did it...are you ready for it?

<DIV HEIGHT=6 STYLE="page-break-after:always">&nbsp;</DIV>

Simple, isn't it. Now, I'm wondering how supported this is across different browsers...

PS - you can put your hands down, you're starting to stink up the blogosphere  ...

So after DirectTV sold its shares of TiVo just the other day, TiVo announced that they'll be cutting prices of their DVR. According to this article, the monthly subscription will become $6.95, and TiVo will be giving price breaks to customers who already own a TiVo DVR. They also stated that the $99 Home Media Option will become part of the normal subscription! That rocks!

So I've had a bit of time to think about the new DataSources objects that are in ASP.NET 2.0, and I think I've come to the conclusion that ultimately they'll be more cumbersome than helpful. I state this in reference to how a lot of my applications are built, in which each page will have a TON of data access to do, all requiring their own business object to be called.

While the concept of using DataSources is very cool and easy to use when creating simplistic web applications, its going to be more cumbersome for more advanced applications. Now, why would it be cumbersome? Well, its taking the whole separation of code and design back to the old days, where its mixed together.  With the advent of .NET 1.0, we had a distinct separation, but it seems this distinction line is fading extremely fast in lue of Visual Studio 2005.

It is also going to be more cumbersome because instead of having distinct areas for server controls, and having your data binding methods in code, you're going to be adding more overhead to the HTML structure of a webform. So, instead of just having (in HTML):

Drop Down List 1: <asp:DropDownList runat="server" id="ddl1" />
<br>
Drop Down List 2: <asp:DropDownList runat="server" id="ddl2" />

you now have more HTML to write, which can be confusing to designers or newbies. In fact, I'm an advanced developer and I still get confused with all the extra HTML that is required:

Drop Down List 1: <asp:DropDownList runat="server" id="ddl1"  DataSourceID="..." />
<asp:SqlDataSource runat="server" ..... />
<br>
Drop Down List 2: <asp:DropDownList runat="server" id="ddl2" DataSourceID="..." />
<asp:SqlDataSource runat="server" ..... />

Sure, this isn't as complicated, because its simplistic. Imagine needing 15 drop down lists, all coming from different data sources, as well as binding a datagrid, and some detail information. That can amount to about 17 of those DataSource items, on top of your regular HTML. Now imaging that being step 1 of a wizard type UI, and having the same type of step 5 more times. Do you see what I'm getting at now?

So, is there any way of using these DataSource controls with regular HTML markup? Maybe, but I would have to propose a section that you define in your HTML page so that everything is contained in 1 place for ease. Other than that, I think I will be ultimately dreading using DataSources for future projects because of this primary problem.

Err - I have GMail, so what. I hardly use it because I don't need 3 dozen email addresses floating around. So, this means I *don't* get to see the "invite someone" link at all.

Why did I post this? Well, my original post "Got GMail?" continuously receives inquiries about getting invited. Currently, there stands about 30 people wanting an invite. Can I invite them? No. Why? Because I don't use it enough. It's just frustrating, and I darn well can't turn off comments for just one of my posts. I get these inquiries daily, and its just driving me nutz.

So, if you're thinking about asking me for an invite, think otherwise. *If* I do get around to seeing that "invite someone" link, you've got a long list ahead of you, so why bother asking me.

What is your favorite Whidbey DataSource. Mine happens to be the ObjectDataSource because most of what I do revolves around writing business logic components that ultimately retrieves and processes the data for me. With the advent of Generics in .NET 2.0, this is seemingly getting easier to do because you can pass back a List<T> instead of just a plain old DataSet. What's yours and why? Do we need more DataSources out of the box?

WebDeploy has hit v0.9 with some new features as well as some bug fixes. The user interface hasn't changed, but don't fret, here's the change log:

• Added "Cancel" to Folder Copy Dialog
• Added "Cancel" to File Copy Dialog
• Added ability to Save a copy of the configuration for backup.
• Added ability to Load a copy of a backed up configuration.
• Added a "Quick Deploy Profile" to allow for quick deployments of simple sets.
• Fixed application hang after successive "Cancels"
• Fixed error message accessing log file during deployment. Viewing log file is unavailable at that time.
• Fixed thread processes still running intermittently after exiting program.
• Modified status bar messages when cancelling.
• Modified listing of profiles to be sorted.

Like always, WebDeploy is freeware, and the source code is not available. If you have any further suggestions, comments, ideas, or problems, please do not hesitate to contact me or post them on this blog post.

If you wish to download WebDeploy, click here. You will need the .NET framework v1.1.4322 to run WebDeploy.

For those of you who keep track of and love using BlogJet, I'd like to state that there's a new Beta out, check out the red item! I've already submitted a few bugs, so help Dimitri out and give 19 BETA a try!

Release Notes

BlogJet 1.1.0.19 BETA Release

FEATURES 

* Spell checker:   
  English UK and English US dictionaries included, more to come. 
* Improved Preferences window (plus Spelling options). 
* Better blog providers list in Account Wizard. 
* Distinct icons for posts with voice attachments. 
* Right-click menu for Recent Posts list. 
* Delete key deletes entry from Recent Posts list. 

CHANGES 

* "View history" menu item changed to "Get Recent Posts". 
* Changed color scheme for Code editor.

BUG FIXES 

* Fixed a long-standing bug: Runtime Error 216. 
* Tab key now switches focus from editor to title. 
* The first post sometimes didn't become selected in Recent Posts window. 
* Posting to Blogware when a category has ampersand in it's name failed. 
* Fixed category list encoding (for non-English category names). 
* "Cannot connect to server" when Page address didn't have slash (/) prefix. 
* Other bug fixes.

Unfortuantely our user group in Bloomington will not be meeting tonight as it turns out that no one is available to stay at the Microsoft office. I've talked with Eric Sink and will be rescheduling the meeting for either June 9th or 30th. I'll update this entry after I find out tomorrow for sure.

Update: The meeting is re-scheduled for June 30th.