C# Discussion Boards - CodeProject

Dan Mos2-Dec-11 1:03

Dan Mos

2-Dec-11 1:03

That's wrong cause you set the color for the entire listbox.

The best/easiest way is to set the DrawMode to OwnerDarwVariable and handle the ListBox.DrawItem event.

There you could use any brush you like to draw the text.

Just look for listboxDrawItem on bingle and you'll find lots of examples.
Smile | :)

All the best,

Dan

Alan N2-Dec-11 1:49

Alan N

2-Dec-11 1:49

Have you considered the ListView as an alternative to the ListBox. When set to the 'Details' view it supports per item colouring via the ListViewItem.ForeColor and .BackColor properties.

Alan.

Dan Mos2-Dec-11 1:55

Dan Mos

2-Dec-11 1:55

All the best,

Dan

Wonde Tadesse2-Dec-11 17:05

Wonde Tadesse

2-Dec-11 17:05

Wonde Tadesse
MCTS

Luc Pattyn2-Dec-11 4:06

Luc Pattyn

2-Dec-11 4:06

Applying different ForeColors to the items of a ListBox is pretty easy; here[^] is an article that discusses an entirely different topic, however the download will show you how to get what you want.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

BobJanova2-Dec-11 5:46

What should be the Return Type?

2-Dec-11 5:46

You need to either custom draw the items or have a custom control (e.g. here is one by me[^]).

AmbiguousName1-Dec-11 23:40

AmbiguousName

1-Dec-11 23:40

hello guys.. I have a function in some class (actually its DAL). Now return type of this function can be either DataTable, DataSet or DataRow like this

public DataTable function(int myTableKey)
{
   DataTable dt;
   // some coding here
   return dt;
}

Now if everything goes right, this function returns me the data table.
But what if some goes wrong, like if I get some exception or I wanna return some string message in case of failure. What should I do? thnx

BobJanova1-Dec-11 23:55

1-Dec-11 23:55

Exceptions are thrown, not returned.

In the case of a user-defined failure you can choose to either throw an exception with a meaningful error message, if it's an exceptional condition that should be handled as an error, or return null from the function (obviously this should be defined in the contract for the function and calling methods should handle it appropriately).

AmbiguousName2-Dec-11 0:22

AmbiguousName

2-Dec-11 0:22

But how? Here is the code to make it more clear

public DataTable function(int myTableKey)
{
  string msg;
  try
  {
     DataTable dt;
     //some coding... with success
      return dt;
  }
  catch(Exception ex)
  {
      msg = ex.Message;
      return msg; //now here I dont know what to do
  }
}

Now focus on the return statement in catch block. This is what I was talking about.

Dan Mos2-Dec-11 0:54

Dan Mos

2-Dec-11 0:54

Just like said before/above either throw the exception and handle it on the calling client,
or log it, return null and check for null on client.

catch(Exception ex)
{
     //either throw it;
     throw;
     //or log it and make the dt null
     dt = null;
}
return dt;

I recommend throwing it and handle the exception on the client calling method.

All the best,

Dan

modified 2-Dec-11 17:16pm.

BobJanova2-Dec-11 5:44

2-Dec-11 5:44

Unless this is a top tier interface function where exceptions are bad (and since it's doing database stuff, it shouldn't be), you should just let the exception escape, to be handled by the calling function.

Rob Philpott2-Dec-11 1:07

Rob Philpott

2-Dec-11 1:07

I'd say do nothing, unless you want to do some custom exception handling in your function. Exceptions are for exceptional circumstances and in my mind there's always been little point in catching an exception just to rethrow it. The error message in an exception is often useless without the stack trace as well.

It's up to the *calling function* to decide what to do in the event of an error, so it may handle the exception there or let it pass further up the call stack.

In particular stuff like this

try
{
}
catch (Exception ex)
{
    throw ex;
}

is pointless and bad as you'll lose the stack trace.

Regards,
Rob Philpott.

BobJanova2-Dec-11 5:45

2-Dec-11 5:45

If you just use

try { ... }
catch(Exception) { throw; }

(note, 'throw' not 'throw ex'), you don't lose the stack trace. It's still pointless but at least it's not harmful.

Rob Philpott2-Dec-11 5:50

Rob Philpott

2-Dec-11 5:50

Indeededoody!

Regards,
Rob Philpott.

PIEBALDconsult2-Dec-11 2:08

PIEBALDconsult

2-Dec-11 2:08

I agree with allowing the Exception to be thrown. You may also add some context to the Exception if you choose:

catch (Exception ex)
{
   ex.Data.Add("Method", "function");
   ex.Data.Add("myTableKey", myTableKey);
   throw;
}

Personally, I like to determine what type of Exception it is (timeout, deadlock, duplicate key, etc.) and wrap it in a custom Exception.