My IQueryableSearch class has been infinitely useful to me and saved me a ton of time. I have also gotten some good feedback on how useful it is. For those of you that don't know what it does (probably most of you) it is simply a universal search for Linq IQueryable collections; a way to search a bunch of fields/properties on a bunch of objects with one simple interface, like google for your own objects.

With that said, I decided to put it up on CodePlex to better track source code and releases; as just posting them as zips on my blog is a pain when the code is being updated. I am also hoping maybe some of you might want to critique/fix/add to my code to make it better - any interest is appreciated. As always, I hope it helps.

To make it easier it is now available in a dll which you can simply put into your bin, add a:

using Naspinski.IQueryableSearch;

And you are ready to start using it.

On a somewhat related note, I am getting close to releasing another large open-source project I have been working on for quite some time that should prove to save huge amounts of time for ASP.net programmer - stay tuned!

I love extensions, they make my life so much easier. Simple things that I can do in a coupole lines of code, I now do in even fewer thanks to my almighty extensions. Here are a couple of super simple ones for easy interaction with DropDownLists

Sometimes it is a pain to set the selected value of a DropDownList, if it is there, it works fine, but if not, it is a pain in the butt. Here is what I use to set mine:

DropDownList1.Set("some_value");

It's just that easy, and if it's not in the ddl, it will work just as well. Here is the extension code:

public static void Set(this DropDownList ddl,
 string findByVal)
{ // attempts to set a DDL to the 'findByVal'
  try
  { 
    ddl.SelectedIndex = ddl.Items
     .IndexOf(ddl.Items.FindByValue(findByVal)); 
  }
    catch { };
}

Once again, we all know the code for this, but an extension makes it easier, and also hanldes it if the item is not there:

DropDownList1.RemoveItem("Any");

And the code:

public static void RemoveItem(this DropDownList ddl, 
 string item)
{
  try { ddl.Items.Remove(ddl.Items.FindByText(item)); }
  catch { }
}

Normally I discourage a blank catch{} but in this case, the only error you would be encountering is if the item is not there, so unless you are worried bout that, you should be fine.

A little bit ago, I came out with this post: Universal IQueryable Search Usable by Linq-to-SQL and Linq-to-Entities and it worked great, but it got me thinking: if I could implement Reflection, it could be even easier to use and require less code to run as it would get the property names/types automatically. So here I am with the new version and it is working great, it has already saved me lots of time. All of the old overloads work as they did previously, I have just added some more. Here is how a few of them work:

Now that reflection is being used, you can pass any sorts of objects to the search and it will only compare like-types, no need to specify. If you are trying to search a collection of 'car' objects in an IQueryable named 'cars' you can just do something like this:

Search(object[] keywords)

var results = cars.Search(new object[] {"chevy", 2007});

That will run through all of the properties of 'car', and if any of them are string variables, they will get compared against "chevy" and if they are Int32 variables, they will get compared against 2007. So this search would pull out all 2007 models made by Chevy.

The above search will search all the properties of an object, but what if 'car' has 100 properties, and you only want to search 2, that is simple as well with this overload:

Search(string[] properties_to_search, object[] keywords)

var results = cars.Search(
  new string[] {"make", "year"},
  new object[] {"chevy", 2007});

Which will only search the properties 'make' and 'year' for the objects; only comparing like Types.

Now let's say that the object 'car' has a some objects that you want to dig into as properties. The 'car' object has an 'engine' property, but if we run the searches above, it will not drill down into the 'engine' object (though it would compare it if you sent an 'engine' as part of the search array). To get it to drill into the engine object, we need to add another parameter, the Type[] types_to_explore so the Search knows to drill down into objects of that type:

Search(object[] keywords, Type[] types_to_explore)

var results = cars.Search(
  new object[] {"V8"}, new Type[] { typeof(engine) });

Now the Search will search anything in the 'car' object and/or in the 'engine' since it now knows to look inside of it; not to mention it will recursively search down into the objects. This would even find something nested like this:

car
  -engine
    -engine
      -style:"V8"

Since you told it to explore all 'engine' types. This would work even if you wanted to search into string, Int32, bool, etc. Types as they all have lots of properties in the world of Reflection - could be a whole new use for this extension?

Basically combine what was covered above:

Search(string[] types_to_explore, object[] keywords, Type[] types_to_explore)

var results = cars.Search(
  new string[] {"engine", "style"}, new object[] {"V8"}, new Type[] { typeof(engine) });

I like this one the least as you have to be most verbose (but not as verbose as the other overloads). If you simply try to search for 'style' here, it will not be found, because you did not tell it to search 'engine' (the property, not the type).

If you haven't looked at the last post, I highly recommend you do, as it is still the most detailed search overloads are explained there (though a bit tougher to use). This is very hard to explain, so I hope you just take a look at the code yourself or better yet, just try it out, you can see with trial and error how it works better than I can explain in a wordy blog. As always, I am very interested in feedback and improvements!

Now this is something that may or may not be useful to a lot of people, depending on you situation, you may want the user to elect to refresh their Session or not (like banks usually do); but this is for applications that may have a lot of idle time and users are annoyed with their Sessions dying... considering most users don't know what a Session is, but they know that the application stops working correctly.

It uses jQuery and is incredibly simple, just a few lines of code, and no screen flicker or any annoyance to the user at all; ignorance is bliss. First I include the following in the code-behind in any page you need to keep refreshed (works on masterpages as well):

code-behind

protected int timeout;
protected void Page_Load(object sender, EventArgs e)
{
    // one minute prior to timeout (milliseconds)
    timeout = (Session.Timeout * 60000) - 60000; 
}

Then add this jQuery to your script:

aspx or master

var to;
$().ready(function() {
  to = setTimeout("TimedOut()", <%= timeout %> );
});
            
function TimedOut() {
  $.post( "refresh_session.aspx", null,
    function(data) { 
      if(data == "success") {
        to = setTimeout("TimedOut()", <%= timeout %>);
      }
      else { $("#timeout").slideDown('fast'); }
    }
  );
}

Notice that the jQuery calls the $.post() function, where it calls the page refresh_session.aspx. That page does only one thing: Response.Write("success"); so if data comes back and it does not equal 'success' (something went wrong) it then stops the cycle of checking for timeout and shows my 'timeout' div that tells the user it is not a current session.

infinitely refreshing session...

Yup, it is just that easy. The code-behind gets the Session.Timeout, and subtracts one minute from it, this is when the refresh will be triggered. Inside the script, the setTimeout() call will then wait that amount of time and use the jQuery $.post() to hit the page in in turn refresh the Session; once that is done, it starts the cycle over again, so it should repeat on into infinite. And since this is all done via a jQuery ajax call, there is no evidence to the user this is even happening, no flicker or popup, nothing.