.NET, Code, Infragistics, WinGrid

Infragistics WinGrid – Tips and Tricks #1 – Right Click Row Select

I’ve been working with Infragistics tools, specifically the UltraWinGrid for 10 years or more (worked with the Sheridan grid before that, anyone remember those tools?), and outside of the Infragistics forums there seems to be very little in the way of information on this very powerful and complex tool.  Perhaps I can leverage my experiences with these tools into a nice little series of posts on things I’ve discovered over the years.

I came upon a situation where I wanted to right click on a grid, have it select the row under the mouse and bring up a context menu to act on that selected row.  As another requirement I wanted it to only act upon data rows.

I came up with the following extension method.

  1. First get the element under the mouse and determine if it’s a row element.
  2. If it’s a row, is it a datarow?
  3. Make it the active row.
  4. if the row is not already selected, select it and deselect any other row.
  5. if the row is already selected, then do nothing else special with the selection properties.
  6. if we’ve clicked somewhere not a datarow, I clear any selected rows in the grid.
21 public static void RightClickRowSelect(thisUltraGrid grid, Point mouseLocation)  
22 {  
23     UIElement element = grid.DisplayLayout.UIElement.ElementFromPoint(mouseLocation);  
24     var row = element.GetContext(typeof(UltraGridRow)) asUltraGridRow;  
25     if (row != null && row.IsDataRow)  
26     {  
27         grid.ActiveRow = row;  
28         if (!row.Selected)  
29         {  
30            grid.Selected.Rows.Clear();  
31            row.Selected = true;  
32         }  
33     }  
34     else  
35     {   
36        grid.Selected.Rows.Clear();  
37     }  
38  }

Then to use this, I simply call it in the MouseDown event on the grid as follows.

    1     privatevoid grdLabsMouseDown(object sender, MouseEventArgs e)
    2     {
    3       if (e.Button == MouseButtons.Right)
    4       {
    5         grdLabs.RightClickRowSelect(e.Location);
    6       }
    7    }

Pretty basic really, but knowing how to determine what element is under the mouse is a critical tool in your belt when dealing with the WinGrid and opens up the door for a lot of advanced features.

Code, SQL

SQL Server – Fixing Orphaned Users after restore

I was tasked with migrating a SQL 7 box (yes still heavily used) to SQL 2008.  Really wasn’t that difficult, perhaps I’ll make another post about the process and issues I ran into.  But for now let me talk about something real quick. 

When restoring a database to a new server you may not have your security setup properly.  For example, the database will have users that don’t exist on the server.  Or perhaps they do but they are not linked properly.  This is the issue I ran into. 

Sometimes it’s just as easy to delete the users from the database and recreate them on the server to relink.  This is fine if you have simple permissions.  But if you have a complex set of permissions on a large number of tables, this get’s difficult to recreate properly and of course you always have the potential to create errors in multiple applications that may connect as that user.

Then I found sp_change_users_login, this has saved the day.  This allowed me to fix the orphaned users after the restore.


EXEC sp_change_users_login 'Auto_Fix', 'orphaned-user-name'

How do we quickly determine if we have this issue?

EXEC sp_change_users_login 'Report'

This will give us a list of orphaned users.  Very handy indeed.


Setting MDIParent results in “Error creating window handle” exception

This was a tricky bug I ran into recently.  First a bit of back history.  I’m working on a largish win-forms MDI application.  Early on in the development I received the  exception “Error creating window handle”  when trying to show the MDI child.  I’m using a 3rd party tab control and I originally thought it was a bug in there.  I found a work-around that if I switched back to the first tab (tab index 0) before showing the new child, the error seemed to go away.  For many months, this worked fine.  Recently I went through a bit of refactoring of the application and suddenly this bug reappeared despite my hack.   Well to make  a long story short some more research ensued and I found the fix (hopefully the true fix now)…actually it is a bit of workaround as well, but we’ll just have to live with it for now.  It appears that .NET MDI applications hates a maximized child window.  To bring another tab to the front, it has to restore the active child window from the maximized state, which triggers the forms layout method to re-layout the form.  This causes a series of events (not interested in digging too deep) that basically seems to create your form twice causing a NullReference exception at some point.  More details here.

Some code that might help me in the future:

    public void DisplayChild(Form child) {
bool max = false;
if (this.ActiveMdiChild != null && this.ActiveMdiChild.WindowState == FormWindowState.Maximized) {
this.ActiveMdiChild.WindowState = FormWindowState.Normal;
max = true;
child.MdiParent = this;
if (max) child.WindowState = FormWindowState.Maximized;

.NET, Code

ActiveControl to tell me the control gaining focus.

I ran into a situation where I needed to know what control was gaining focus in the Leave() event of another control.  The situation I was working with is as follows;  I have a multi-line text box that when it gains focus I want a listview of potential values to popup below it.  When the textbox loses focus, the listview should be hidden.   The user should be able to click on the listview to select items to input into the textbox.  The problem was when the user clicked on the listview, the textbox lost focus and was hiding the listview.

Enter the ActiveControl property on the form.  This handy property allows me to check, in the Leave() event, what is the new active control with focus.  Thus I can check to see if the textbox lost the focus to the listview control and if so, skip the hiding of it.

Here we have the textbox named txtComplaint, when it gets the focus we make listView visible.

private void txtComplaint_Enter(object sender, System.EventArgs e)
  listView.Visible = true;

When the textbox loses focus we see if the ActiveControl is the listView, if not we hide it.

private void txtComplaint_Leave(object sender, System.EventArgs e)
  if (ActiveControl.Name != "listView")
    treeComplaint.Visible = false;
.NET, Code

Delimited String to Generic List<>

This is something that I tend to forget even though it’s pretty basic and probably obvious to most.  I have a comma delimited string which I wanted to put into a List<>. Here’s a one-liner to get the job done.

List aList = new List();

Where myString is my comma-delimited string.  Pretty basic, but very handy.