Winforms
Ran into a performance issue in a .Net remoting situation. A Winforms app is calling an application server asking for data. A relatively large DataSet (>10,000 rows, <6 columns) being passed over the wire was causing a performance problem. The database and application servers processed it quickly. Examining the transfer with WireShark showed that the transfer wasn't so bad either. There was a flurry of data passed, and then a bunch of waiting on the client-side, with the client CPU usage around 50% the entire duration of the wait. Turns out there is a calculated column in one of the data tables. The column is not calculated on the application server-side, so as not to pass a bunch of data across the wire that would be unnecessary. The calc happens on the client. That was the source of the slowdown and CPU usage. In the end the solution to the problem was not using the calculated column, we found a different solution to fix the business problem. I suppose you could perform the calculation in the SQL statement that was ultimately filling the DataSet. That might take longer to transfer, but won't slow down the client app.
I've seen it many times in the past,
now it has a name
Learn how to leverage Active Directory in your .Net apps:
The .NET Developer's Guide to Identity
The standard combobox control doesn't support the double-click event, as it is actually a combination of more than one control itself. In my case, I am using the combobox in simple mode with a textbox at the top and a permanently open list directly below the textbox. I needed for the listbox below to respond to the user double-clicking a list item. I found a great solution in a Usenet post by Jacques Bourgeois in microsoft.public.dotnet.framework.windowsforms.controls. Essentially the code simulates a double-click using the single-click event and a timer control.
Declare a timer control in your class, and in the load event of the form instantiate the timer set the interval of the timer to the interval of the double-click as set in the user's system:
this.comboDoubleClick = newTimer();
this.comboDoubleClick.Interval = SystemInformation.DoubleClickTime;
In the event handler for the timer, set the code to stop the timer:
this
.comboDoubleClick.Enabled = false;
Add code to the single-click event handler to handle the double-click. When the event handler fires, if the timer is not enabled, start the timer (the first click). If the timer is enabled, a previous click has occurred within the system set interval for a double-click. This must be the second click of the double-click, so do whatever you needed the double-click to do and then disable the timer for the next single-click event.
private void Combo_MouseClick(object sender, MouseEventArgs e)
{
if (this.comboDoubleClick.Enabled == true)
{
//Do double-click work here
this.comboDoubleClick.Enabled = false;
}
else
{
this.comboDoubleClick.Start();
}
}
Today we are migrating my project from Whidbey Beta1 to Beta 2 (if you know why this is happening today, go ahead and laugh with us), and our biggest hurdle so far is Typed Datasets.
We used dozens of XSD schemas to create typed datasets. Of course, Beta 2 no longer gives a menu option for creating a typed dataset directly from a schema (see this post in the Fedback Center for Visual Studio). The prospect of converting to the Dataset type of schema was daunting, and moving to the command line for xsd.exe was not going over so well either.
We did discover, however, that you can still generate the dataset using the IDE. In the properties of the XSD file, you can set the custom tool to MSDataSetGenerator. Then you can right-click the XSD file and choose Run Custom Tool. The IDE generates the code for the dataset. Whew!
In my last post I described a “Select Distinct“ function for a datatable. This is a whole lot easier using Whidbey. You can get a distinct table based on a column in the DefaultView of the datatable:
DataTable d = dataSetName.dataTableName.DefaultView.ToTable(true, new string[] { "ColumnName" });
There is an excellent “Hello World”
article for getting started with the UIAB at
CodeProject by
Roy Clemmons. If you have checked the docs that come with the block, you can appreciate a simplistic example. The block is a powerful piece of code, but you have to get started before harnessing the monster. I had a very difficult time distilling the example code from the block down to something simple that worked. The article from CodeProject did the trick.
If you would like an overview of Smart Clients, try this overview, the Microsoft overview, an other articles at the Smart Client Developer Center. For my puposes, a Smart Client is a locally-run application that is connected to part of a distributed solution, and it is capable of functioning when the connection is unavailable (disconnected).
The Offline Application Block (OAB) is a framework for managing a Smart Client's disconnected state. In a nutshell, the OAB checks for connected state, it provides a local cache for data already fetched from the central data source to be available when disconnected, and it provides a queue for sending changes back to the centralized data source when disconnected. The actual implementations of the cache and queue can be in-memory, the local file system, MSDE or Sql 2005 Express, MSMQ, or even something you design yourself.
The OAB utilizes other Application Blocks, including Caching, Data Access, and Exception Management. There are also some Quick Starts that come with the OAB to demonstrate some of the features.
The OAB itself and the on-line documents are available at the Patterns & Practices web site.
Other excellent resources:
Mark Brown posted his fix for a bug in the FillDataSet method of the SqlHelper in the Data Access Application Block. The problem occurs when trying to use the FillDataSet method to fill a typed dataset that contains more than two tables. It works great for the first two, not at all for the subsequent tables.
I gave Marks\'s fix a try, but it still didn't fix the problem for me. I did more digging and found a slightly different fix straight from the authors of the DAAB on the GotDotNet workspace for the DAAB. The fix is in the bug section (direct links don't seem to work) This cleared up my problem right away. Of course, the bug is fixed in version 3+ of the DAAB. If you are like me, the MSDN site has been my source for the code for the application blocks, and of course there is only 2.0 on the site.
I did not realize they were on version 3 of the DAAB. The authors have added support for an abastract factory to make the SqlHelper ADO.Net provider independant. I don't know about the rest of you, but the only projects I have ever had to change the database provider on have been Access upgrades. I have never had to move a database back end, say from SqlServer to Oracle. Is it more common than I realize?
As a small project, we were tasked with creating a data feed from a text report genereated by JD Edwards (not OneWorld, an older version) and our application. Instead of going the FTP and text file parsing route, I decided to try our first venture into a web service. Since the JD Edwards group were using Excel 2000 to manipulate the report before sending it to our system, I figured a VBA macro could send the data for them, using the XMLHTTP object.
'Notes: Using late binding so the project won't need explicit references
' Using MSXML 2.5 object model to be sure it will run on most PCs
Public Sub SendDataToEnCore()
Dim oXML As Object
Dim oDom As Object
Dim oNode As Object
Dim sXML As String
Dim nResult As Integer
Dim sResponse As String
On Error GoTo Handler
Set oXML = CreateObject("Microsoft.XMLHTTP")
Application.Cursor = xlWait 'Change the cursor to a wait cursor
Application.ScreenUpdating = False 'Stop screen redraw
With oXML
'Call the service, it only takes one parameter, the XML string
.Open "POST", & _
"http://test.com/Redeployment.asmx/Redeployment_Update", False
'The following line is necessary for the web service to recognize the post
.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
Application.StatusBar = "Waiting for a response..."
'Create XML is a function that loops the spreadsheet building an XML string
.Send CreateXML
End With
sResponse = oXML.responseText
With Application
.Cursor = xlDefault
.StatusBar = ""
.ScreenUpdating = False
End With
Set oDom = CreateObject("MSXML.DOMDocument")
oDom.loadXML (sResponse)
If oDom.hasChildNodes Then
'Display the resulting message from the web service
Set oNode = oDom.documentElement.firstChild
nResult = MsgBox(oNode.Text, vbInformation, "EnCore Data Transfer")
Else 'No response at all
MsgBox ("The JDE upload failed. Please contact Development for assistance.")
End If
Set oXML = Nothing
Set oDom = Nothing
Set oNode = Nothing
Exit Sub
Handler:
With Application
.Cursor = xlDefault
.StatusBar = ""
.ScreenUpdating = False
End With
MsgBox Err.Description
Set oXML = Nothing
Set oDom = Nothing
Set oNode = Nothing
End Sub
So far this has worked well for us. One of the issues we encountered was URLEncoding the XML string before sending it. Otherwise, it just won't parse properly on the web service end. Here is an abbreviated version of the web service function that is called by the above Excel VBA function.
Public Function Redeployment_Update(Byval sInput As string) As String
Dim dt As DataTable
dim n as Integer
sInput = cstr(sInput)
n = sInput.Length
If n <= 0 Then
return "File contains no data"
End If
' Load the input XML string into a DataTable
dt = LoadDataTable(sInput)
Dim drCurrent As DataRow
For Each drCurrent In dt.Rows
ProcessRow(drCurrent) 'Our custom function to parse a row
next
return "File received OK. Characters Received=" & n
End Function