I don't know why they took this option out of the settings within Outlook, but the registry setting for this is still there.

To minimize it to the system tray, start regedit and follow the steps below:

HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ 10.0 \ Outlook \ Preferences
New Data Type: REG_DWORD
Value Name: MinToTray
Data: 1 (0 to disable MinToTray)

The number in red above is the MS-Office version number; 10 is Office 2000; 11 is Office 2003.

This error is a permissions problem. This is a very frustrating problem for someone who doesn't know Windows Server 2003 very well.

Heres is a workaround:
1. go to Administrative Tools> Component Services
2. expand COM Services
3. expand My Computer.
4. expand COM+ Applications.
5. Right click on your Application, select Properties 
6. Go to the Security tab
7. In the Authorization frame, uncheck “Enforce access checks for this application“

This isn't the best, since it grants every account on the machine access to create the objects in this application, but it's a quick/easy work around.

Color the background of items in a Dropdown box in your HTML pages. It's very easy to do, just look at the below example.

Highlight Black Gray DarkGray LightGray White Aquamarine Blue Navy Purple DeepPink Violet Pink DarkGreen Green YellowGreen Yellow Orange Red Brown BurlyWood Beige

<select>
<option value="">Highlight</option>
<option value="#000000" style="background-color: Black;color: #FFFFFF;">Black</option>
<option value="#808080" style="background-color: Gray;">Gray</option>
<option value="#A9A9A9" style="background-color: DarkGray;">DarkGray</option>
<option value="#D3D3D3" style="background-color: LightGrey;">LightGray</option>
<option value="#FFFFFF" style="background-color: White;">White</option>
<option value="#7FFFD4" style="background-color: Aquamarine;">Aquamarine</option>
<option value="#0000FF" style="background-color: Blue;">Blue</option>
<option value="#000080" style="background-color: Navy;color: #FFFFFF;">Navy</option>
<option value="#800080" style="background-color: Purple;color: #FFFFFF;">Purple</option>
<option value="#FF1493" style="background-color: DeepPink;">DeepPink</option>
<option value="#EE82EE" style="background-color: Violet;">Violet</option>
<option value="#FFC0CB" style="background-color: Pink;">Pink</option>
<option value="#006400" style="background-color: DarkGreen;color: #FFFFFF;">DarkGreen</option>
<option value="#008000" style="background-color: Green;color: #FFFFFF;">Green</option>
<option value="#9ACD32" style="background-color: YellowGreen;">YellowGreen</option>
<option value="#FFFF00" style="background-color: Yellow;">Yellow</option>
<option value="#FFA500" style="background-color: Orange;">Orange</option>
<option value="#FF0000" style="background-color: Red;">Red</option>
<option value="#A52A2A" style="background-color: Brown;">Brown</option>
<option value="#DEB887" style="background-color: BurlyWood;">BurlyWood</option>
<option value="#F5F5DC" style="background-color: Beige;">Beige</option>
</select>

When you wrote essays in school, didn’t you plan out what you were going to write about before you started writing? The same needs to be done with software development.

Specifications documents need to be written out for all new features/enhancements, before any development begins.  That way the developers have a blueprint to work with of how the feature/enhancement is to work. This should be written from the original description that is gotten from the client that is requesting it. Something that’s not too bad of an idea is to send this specs document to the client and have them approve it. Preferably the Specs document would also include a simple layout of how the user interface and any reports are desired to look.

Then when the developer gets these specs, they need to create something like a “plan of attack”, which is basically how they plan on implementing the feature/enhancement described in the Specs document. This “plan of attack” would include any database schema changes, DLL functions that already exist and new ones that need to be created, etc. that are necessary to implement this feature/enhancement. Preferably the “plan of attack” would be done by the developer that is going to code the feature/enhancement and at least one other developer, this way the best architectural decisions can be made.

Both of these documents should be saved and used for later reference (like: writing the product manual, fixing a bug, and TESTING to see that it works properly).

Have you ever found a bug in a piece of software you were using? If so, what did you think about that that piece of software or the company that wrote the software? A user sees a bug, and says in their head, “This software sucks.” Do we want users thinking our software sucks?

I don’t know exactly what percentage of bugs we miss and the clients find, but I think it’s something like 50%. That is a terrible number; we NEED to do more TESTING of things before they go live. At a job I used to have doing software testing (Time and Attendance/Payroll software) I was able to catch 70-90% of the bugs. The developer to Tester ratio their was 50% of Programming time was done Testing, if it took 8 hrs to program then there was 4 hrs spent testing. I tested every single part of the specs document pertaining to the feature/enhancement and related areas. I also tested inputting weird data into the application to make sure that it handled it correctly. When testing you need to test every single possibility of a setting, and as many possibilities of data as you can think of.

I don't know if this is legit for sure, but it is pretty funny. Microsoft Windows for only $99, that's right $99!!!!!

http://www.energyradio.fm/content/ballmer.asx

Today, I started creating my own implementation of the VB.NET 2005 “My“ namespace. The target platforms for my implementation are .NET v1.1 and Mono v1.x  Heck, maybe eventually I could convince the folks over at the Mono project to put my code into their implementation of the .NET Framework, but I suppose I'll have to get alot more done on it first.

If you don't know what the “My” namespace is check this out: http://channel9.msdn.com/ShowPost.aspx?PostID=13368

If you would like to get your hands on my implementation of the “My” namespace for .NET 1.1 and Mono, you will have to wait since it is no where near complete enough to even let anyone play with it.

Here is a VB.NET version of a C# example that I found to do just that. It's really simple to do.

<%@ Page Language="vb" %>
<%@ Import Namespace="System.Diagnostics" %>
<%
      ''Get a file name relative to the current Web app.
      Dim file As String = Server.MapPath("Program.exe")
      Dim info As ProcessStartInfo = new ProcessStartInfo(file, "/arguments")
      ''Redirect output so we can read it.
      info.RedirectStandardOutput = true
      ''To redirect, we must not use shell execute.
      info.UseShellExecute = false
      ''Create and execute the process.
      Dim p As Process = Process.Start(info) p.Start()
      ''Send whatever was returned through the output to the client.
      Response.Write(Replace(Replace(p.StandardOutput.ReadToEnd(), vbCrLf, " "), " ", " "))
%>

I went to the MSDN Event in Milwaukee yesterday, and got the FREE DVD with Visual Studio 2005 Beta 1. This is just awesome, anyone attending the MSDN Events in August - September 2004 get this DVD. If you're not an MSDN subscriber, but want to get your hands on VS2005 Beta 1, just go to one of these MSDN Events. Hell, even if you are an MSDN subscriber, go to one of these events. Very informative.

http://MSDNEvents.com