ASP.NET "Invalid postback or callback argument. Event validation is enabled ..." error

I'm working on a page which features a user control which contains a datagrid with "Select" buttons in each row.

During initial development of the page the same datagrid was placed directly in the content section of a page and its behavior was normal; when this datagrid and other controls were put into a user control and the user control added to the page I began getting this error;

"Invalid postback or callback argument. Event validation is enabled using in configuration or <%@ Page EnableEventValidation="true" %>in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation."

I checked to make sure that the user control was registered in the page that was hosting it -- it was -- so I was a little puzzled at why the host page wasn't recognizing the user control.

Googling the problem turned up a lot of responses saying that changes could be made in the config file to turn off this security feature but this seemed a little kludgy.

Tracing the problem in the debugger I found that the failure was occuring during the Page_Load event in the page lifecycle of the user control and failing on the code in that event handler. I moved the code that was in the "Page_Load" event handler into the 'Page_Prerender" event handler and this problem stopped.

I am not quite sure why this worked, I'll write a comment to this blog entry if I figure it out.

The problem of Microsoft C# Datasets and SQL Server stored procedures which use temporary tables

In certain cases when coding up stored procedures I sometimes needed to create a temporary table "on the fly" to hold specialized output (generally I've done this when I needed to scan several tables looking for "most recent" records from each or needed to compose a table of summary information gathered from various tables in the database). To date I've been used to using the T-SQL "create #temptable" syntax.

Traditionally the coding of these small sprocs consisted of 1) creating this temp table, 2) adding rows to it, and 3) ending the sproc with a "select * #temptable" statement to output the results.

This has worked fine for me for years for handling custom summary queries but I discovered that if I tried adding these types of sprocs to a C# dataset I couldn't get them to work. Specifically, when I added the sproc to a project's dataset in Visual Studio 2008 the "wizard" would dutifully add the procedure itself to a "QueriesTableAdapter" collection but would not create an associated table.

This made sense, I guess, since ADO really has no idea what the schema of "#temptable" is in the sproc and could not create a strongly-typed table object from it.

The solutions found in Google searches were not satisfactory until I came across the new (for me at least -- it's actually been around since SQL Server 2005) SQL Server "table variable." It's a significantly more elegant solution than "temptables."

Start the coding of the sproc with the definition of a "table variable" to hold the summary information, e.g.:

DECLARE @AGENCYSUMMARY TABLE
(
agencycode varchar(50)
, entitycode varchar(50) PRIMARY KEY
, scanjobid int
, rows int
, timein datetime
, timeout datetime
)

then write the code to add rows to this table and, at the end of the sproc, add a SELECT statement to dump all the information in the table variable to the output stream:

SELECT agencycode
, entitycode
, scanjobid
, rows
, timein
, timeout
from @AGENCYSUMMARY

Now when you edit a dataset using Visual Studio and add this sproc to the design screen the tableadapter AND the table will appear. Evidently the initial definition of the schema of the table variable provides the dataset with what it needs to handle this "temporary" table and it creates a strongly-type table object just as it would for any other table defined in the database.

Grep'ing files in Windows 2008 with PowerShell

For the life of me I can't get the windows search function to work correctly under Windows 2008 to do full-text recursive searches of a directory tree -- supposedly you need to reset the folder options under Windows to search file contents but it just doesn't work right.

Here's a simple way to do it using PowerShell:

PS> get-childitem d:\ -include *.aspx -recurse select-string -pattern '.toggle'

Here I'm doing a recursive full-text search of a directory tree for files containing the string '.toggle' (it's a JQuery function I used sometime over the last year that I needed an example of).

This works well and, unlike the built-in Windows "search" function (quotes are intentional), its operations are transparent and actually work.

Reminder - Enumerating column names of a dataviewrow

So that I don't waste another hour trying to remember this ... to quickly enumerate the column names in a DataRowView object, use this collection.

((System.Data.DataRowView)(data_userBindingSource.Current)).Row.Table.Columns

Reminder: Regex "greedy" matching in gVIM

To remind myself -- when using gVIM, "greedy" matching doesn't use the "?" question mark character used in PERL but, instead, the string "\{-}". I need this about once every three months and completely forget what the string is -- well, here it is to remind me.

Example:

   [DoT PO Uninstall Number] [nvarchar](255) NULL
   :%s/^\[.\{-}\].*/\1/

results in:

   DoT PO Uninstall Number

From the best gVIM cheatsheet available: www.rayninfo.co.uk/vimtips.html

"The RPC server is unavailable" problem demoting a domain controller in an NT domain

When using HyperV for an enterprise development task I needed to rapidly create, promote, and then demote servers. The promotions went fine but I ran into problems doing the demotions -- I kept running into a problem where I got the message claiming that "The RPC server is unavailable." The error message claimed that it couldn't contact another DC in the domain to complete AD replication before it did the demotion, which seemed unlikely since DNS was set up correctly.

I don't know why this solution worked, but ... the way to get this fixed was to go to another DC in the devdomain, bring up the "Active Directory Sites and Servers" admin tool, select the server I was trying to demote, expand the "NTDS" child icon, then right-click on it to get the "Replicate Now" context menu option.

I clicked on that to force a replication then tried the demotion opration again. This time it worked.

"CLR has been unable to transition from COM context for 60 seconds" error in Visual Studio

This is an error in VS2008 I've gotten infrequently that appears when running a really long process (in my case, a recursive treewalk of a very large Active Directory structure) in the Visual Studio Debugger.

The title of the messagebox is ""ContextSwitchDeadlock was detected" and the text reads like: "The CLR has been unable to transition from COM context 0x12345 to COM context 0x54321 for 60 seconds ..."

The code is not the problem, it's the debugger being helpful when it thinks there's a runaway process.

The answer is to change some settings in the debugger to stop Visual Studio from halting on long processes: "Debug", then "Exceptions", then "Managed Debug Assistants". Uncheck the box for "ContextSwitchDeadlock."

One note -- this is not a system-wide settings change, it seems to be in the project's .suo file and specific to the project you're debugging.