Debugging WCF Services

Here's a link to a some very useful information on debugging WCF Services

Javascript to stop Editing of a Textbox

Here's a quick bit of Javascript to stop someone from entering data into a text box. Why would you need this when you can use a label or a read only text box?

1. The label is not a control you can get the .text from with code behind.
2. The read only text box will always return String.Empty when referenced with the code behind

Warning, that this code does not stop the delete key from being hit.



//Do not allow user to enter data into Fleet Type
function FleetKeyPress()
{
window.event.keyCode = 0;
}

and

{{ asp:textbox onkeypress="javascript:FleetKeyPress();" id="txtFleetType" cssclass="txtbox" columns="8" runat="server" }}

MIDL_USER_ALLOCATE and strcpy_s

I recently converted one of our very critical applications from Visual Studio 2003 to Visual Studio 2005. The application is RPC based and written in C++. In doing the conversion, I inadvertantly introduced a bug (is there any other way to introduce a bug?).

The original code looked like the following

*szResponse = (unsigned char *) midl_user_allocate(sizeof(unsigned char *) * (strlen(szTempResp)+1));
strcpy((char *)*szResponse, szTempResp);

After my conversion, the code looked like the following

*szResponse = (unsigned char *) midl_user_allocate(sizeof(unsigned char *) * (strlen(szTempResp)+1));
strcpy_s((char *)*szResponse, sizeof(szResponse)-1, szTempResp);

What it should have looked like is the following (I hope)

*szResponse = (unsigned char *) midl_user_allocate(sizeof(unsigned char *) * (strlen(szTempResp)+1));
memset(*szResponse, '\0', sizeof(unsigned char *) * (strlen(szTempResp)+1));
strcpy_s((char *)*szResponse, sizeof(unsigned char *) * strlen(szTempResp), szTempResp);

The problem was with the sizeof command. The szResponse variable is just a pointer, and therefore only a long is allocated, not a array of longs.

This one had me baffled for a couple of months, mainly because it would never show up in debug mode on my PC, but hit at random intervals in production under release mode. To compound the problem, the try catch block the code was in was missing a catch (...) clause, which meant the error fell through to the application instead of the thread handler, and caused a fatal error in the application.

Just another reason to convert to managed code!

Current Projects

My current projects involve a lot of old projects, that is, bringing old code up to new standards, bringing them in-line with the new build process and making sure we actually have the code for all the old programs. It's not as easy as it sounds, but it is pretty valuable to the organization, though it's a hard sell to the business customers and to management.

Most of the old code I work on is in C++, though some is a simple upgrade from C# in .NET Framework 1.1 to C# in .NET Framework 2.0. In some places, we have converted code from C++ to C# with the C++ doing a COM Callable Wrapper call to the C#. This has proven to not be the most easy way to do things, nor the most reliable, and we spend a lot of time trying to debug the interface. In my view, the shorter the amount of time you can can spend supporting that dual code environments, the better.

Welcome!

Welcome to DevScape, my journal of my exploits through the world of Software Engineering. Here, I hope to keep both a record of the projects I've worked on, the tricks and tips that I've used to solve problems, and a list of websites which I find essential to getting work done.

My focus, as of now, is .NET and C#. I'll also have stuff on C++, Informix, Accurev, CruiseControl.NET and the plethora of other languages and tools I use on the job. If you find any any 'Good God, that's wrong!' stuff out here, let me know.