Posts made by louthy

louthy

For a bit of background. LINQ facilitates functors and monads (concepts from functional programming). Simplified: functors are types that 'map' (Select), monads are types that 'bind' (SelectMany). When you do 'from x in y' you're lifting the value out of the monad (get the value wrapped up *in* the monad), doing an operation on it, and then wrapping it back up in the monad. The monad in this case being IEnumerable/IQueryable. There are other types, like Option, Either, Try - see this library: [language-ext] 'let' is essentially the non-monadic assign, it's essentially exactly the same as declaring a local variable. It doesn't do the lifting, and therefore if you did 'let x = list', then it wouldn't extract the value from the list, it will just assign the list. It's most useful in query expressions to pre-calculate a value that will be used many times in subsequent parts of the query; but it can very much allow full functional programming within LINQ expressions.

louthy

I use Trello for managing our very large web application. We track everything from in-coming feature requests, backlogs, bugs, research, etc. It's free as well, so can't complain there. http://goo.gl/U8YnoO[^] It's got a great API too, which we've used to build a whole test-plan system that then generates 'Issue' tasks automatically when QA finds bugs, and deals with severities, state, etc. A note of warning though, I'd only use it if you're in an Agile environment. Or if your waterfall project is small.

louthy

The point is you shouldn't be typecasting very often - it's a sign of a broken design (an exception would be serialisation). If you are then you're not using the OO features of the language to their full extent. If I ever see a cast from one type to another then I tend to treat the code with suspicion. Fair enough sometimes the framework itself doesn't always have the support required for strongly typed objects (like DataRow), that however isn't a failing of the language, it's a failing of the framework. It really isn't tough to write wrappers for the times when you need to do this. You posted this: int _ownerid = ((dsApartmentHouse.OwnerLookupRow)((DataRowView)OwnerLookupBindingSource.Current).Row).OwnerId; That is exactly the situation I'm talking about. A proper OO solution wouldn't return a reference to an Object for 'Current'. So this is a failure of the framework. You could in this instance subclass BindingSource and provide a property called CurrentRow which returns a type of dsApartmentHouse.OwnerLookupRow. You can then do: int ownerId = OwnerLookupBindingSource.CurrentRow.OwnerId; Which keeps the code nice and clean, and hides the papering over the cracks between your code and the framework. You could even create a template version which does it for all types of BindingSource.

louthy

Which is why most professional C# programmers don't work directly with Object, and work with strongly typed objects. They will use various polymorphism techniques to handle type specialism. If the entire issue with C# is "how do I tell one type from another" then I'd say there are bigger issues for the programmer to deal with. Like, education, training, reading. I posted this on another reply if that's all you need in C#;

public static class ObjectExtensions
{
public static bool IsNumeric(this object @this)
{
return Microsoft.VisualBasic.Information.IsNumeric(@this);
}

public static T ConvertTo(this object @this)
{
    return (T)System.Convert.ChangeType(@this, typeof(T));
}

}

Usage:

string test = "123";
if (test.IsNumeric())
{
// Woah! I can extend the functionality of systems
// by writing code.
}

int number = test.ConvertTo<int>();

But I would argue you should very, very rarely have to do this kind of thing. Perhaps when deserialising, but definitely not in general case coding. Subclasses should be used to provide type specific functionality, and objects should be held with references of the type they represent, or in base-type references with virtual methods for accessing subclass functionality.

louthy

OriginalGriff wrote:

Char.IsNumber anyone?

If he really wants IsNumeric, just add an extension method to the Object class.

public static class ObjectExtensions
{
public static bool IsNumeric(this object @this)
{
return Microsoft.VisualBasic.Information.IsNumeric(@this);
}
}

Usage:

string test = "123";
if (test.IsNumeric())
{
// Woah! I can extend the functionality of systems by writing code.
}

Then every object will have the functionality which is clearly stopping such a talented individual from getting the most out of C#.

louthy

Use a barcode font: http://www.barcodesinc.com/free-barcode-font/[^]

louthy

Or even easier (if you're using .NET 2.0) is to drop a BackgroundWorker process onto the form. It's DoWork event will fire a method on the form where you can do your processing. Be warned however, that Windows Forms aren't thread safe, so any manipulation of the form controls requires jumping back onto the main thread using Control.Invoke or Control.BeginInvoke to call a delegate. Eg. public partial class MyForm { // Your delegate definition. It basically defines the prototype of the method. delegate void AddItemDelegate(string text); // Method for adding a single item to your list private void AddItem(string text) { if (InvokeRequired) { // We're not in the UI thread, so we need to call BeginInvoke BeginInvoke(new AddItemDelegate(AddItem), new object[] { text }); return; } myListBox.Items.Add(text); } // Your DoWork event private void myListBox_DoWork(object sender, DoWorkEventArgs e) { foreach( string item in myList ) { AddItem(item); } } }

louthy