Re: Setting Datagridview combobox column value to null. - C# Discussion Boards

12-Jun-10 4:09

Why on earth it's so difficult to find a sample on the web for this topic? Nobody has ever tried putting a checkbox on a datagridview on a winform? Or my search is wrong? This thread's subject has been my search key. Gettin nothin.

What's wrong with the below code?

<br />
      DataGridViewCheckBoxCell chk = (DataGridViewCheckBoxCell)dataGridView1.Rows[0].Cells[0];<br />
      if (chk.Selected)<br />
      {<br />
          MessageBox.Show("Selected!");<br />
       }<br />

It's always checking the "cells" selected state. I want to know if the check box has been selected(Checked!) or not.
Yes, I added column 0 to be a DataGridViewCheckBoxCell.

Anybody can help?

dan!sh 12-Jun-10 4:25

dan!sh

12-Jun-10 4:25

The Value property would give the checked state of the cell. Smile | :)

BTW, instead of casting, you can use as keyword along with the null check.

Smith#12-Jun-10 4:49

12-Jun-10 4:49

How do I access it's value? The below attempt is successfuly throwing a cast exception.

<br />
  if (CheckState.Checked == (CheckState)dataGridView1.Rows[0].Cells[0].Value)<br />
                {<br />
                    MessageBox.Show("ok");<br />
                }<br />

Luc Pattyn12-Jun-10 5:01

12-Jun-10 5:01

so look at dataGridView1.Rows[0].Cells[0].Value.ToString() to discover what might be wrong.
everything responds well to ToString(), except null of course.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

Smith#12-Jun-10 5:24

12-Jun-10 5:24

Something's troubling. It requires me to "check" the checkbox at least once before checking it's VALUE to stop it from whining.
If I call

<br />
 dataGridView1.Rows[0].Cells[0].Value.ToString()<br />

straight, without touching the grid, it's throwing NULL object exception.

Luc Pattyn12-Jun-10 5:40

12-Jun-10 5:40

Smith# wrote:
It requires me to "check" the checkbox at least once before checking it's VALUE

Not quite. There must be many ways to make Value hold an appropriate value, or to overcome a possible null.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

dan!sh 12-Jun-10 5:07

dan!sh

12-Jun-10 5:07

The property Value will have value as true or false. Try casting that to boolean.

Smith#12-Jun-10 5:25

12-Jun-10 5:25

Please check my reply to Luc.

Dr.Walt Fair, PE12-Jun-10 6:04

Dr.Walt Fair, PE

12-Jun-10 6:04

Essentially .Value can have 3 values in the case of a CheckBox: true, false and null. Whenever you deal with DataGridView cell values, you need to check for null. Whether it's a CheckBox cell or not, accessing a null is bad.

CQ de W5ALT

Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software

Smith#12-Jun-10 23:31

12-Jun-10 23:31

Hi Walt Fair, thanks for your reply. Well,I'm still not convinced with the replies.
The grid has been drawn on the screen, the rows have been created, the cells are displayed beautifully with checkboxes. Then why the "Value" has to be NULL? and why it's not NULL after I check the cell once?

Threading Question

LimitedAtonement11-Jun-10 7:25

LimitedAtonement

11-Jun-10 7:25

Dear Sirs,

I've read google, MSDN and this site quite a bit and can't quite come up with the answer.

I've created a program (server) that is multi-threaded. Here are some descriptions:

Listener thread: This thread sits and listens for TCP connections. When it gets one, it creates a thread for that connection which gets data from that connection and interacts with the database, spawns processes, whatever the client asks for.
Scheduler thread: Certain tasks are scheduled to occur on the server, this thread sits tight and when the appropriate time (specified in config file) comes, it executes the tasks that need to happen one at a time (which then probably connect via the listener).
I would also like a GUI to monitor progress from the clients.

I currently have the following main method:

//[System.STAThread]
public static void Main(string[] args)
{
   _con = new DW_DB_Connection();//establishes connection with SQL database in ctor for use by clients.
   Start_Threads(); //starts listener and scheduler
   //System.Windows.Forms.Application.Run(new UI());
}

If I use a GUI, I need STA Thread, right?

My question is this: does STAThreadAttribute diminish the power of my application to multi-thread aggressively (and allow it to scale quite large)?

From what I've read, it might be the case that STA only has an effect when the application uses COM (here). The scheduler and listener do not...I think, but Windows Forms certainly does. But other sources say it changes the apartment state of the current thread to be single threaded.

Let me know what you think.

In Christ,
Aaron Laws

http://ProCure.com

#realJSOP11-Jun-10 7:29

#realJSOP

11-Jun-10 7:29

If you just create a new WinForms project, everything you need will be included. However,your threads cannot modify the UI directly. You need to use Invoke for that.There are several very good articles here on CodeProject about .Net multi-threading in a GUI.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

LimitedAtonement11-Jun-10 8:23

LimitedAtonement

11-Jun-10 8:23

Dear Mr. Simmons,

Thanks for the response. I'm not really multi-threading in a GUI, but my multi-threaded application uses a GUI. The UI is the last thing to be initialized. It's not much of a difference if any, but I thought I would point that out.

Beyond that, I'm just trying to make sure that my program in fact uses the .Net Free-Threading (right?) model, not a scheduled single-thread when I use the STAThreadAttribute. Thanks again.

In Christ,
Aaron Laws

http://ProCure.com

Luc Pattyn11-Jun-10 8:31

11-Jun-10 8:31

Hi,

this is how I understand the issue: the STA/MTA choice does not affect managed code; it exists in order to orchestrate how COM objects are used, i.e. in STA all COM accesses are sequenced, so no two threads are actively executing COM code. That would be relevant only in a few cases; only some GUI Controls force you to use STA, OpenFileDialog and similar dialogs are the most popular ones.

For a server application, STA typically will be fine. If you need further convincing, just create a little project (default is STA) and give it a few (say 10) threads containing a while(true) loop including (1) a for loop counting to 1 billion and (2) a Console.WriteLine(string) statement with a different string for each thread.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

LimitedAtonement11-Jun-10 8:48

LimitedAtonement

11-Jun-10 8:48

Dear Mr. Pattyn,

I hope you're right, and I'll assume you are. I'm not so sure the example really proves the point, though, because there could be some scheduling or something that causes the example to look multi-threaded when in fact, the one thread's slice is actually being sliced up more or something like that. As you can probably see from my comments, it's all a mystery to me, but I'll keep the STAThreadAttribute up and contact you when it messes up.
Wink | ;-)

In Christ,
Aaron Laws

http://ProCure.com

Luc Pattyn11-Jun-10 9:03

11-Jun-10 9:03

I'm pretty confident my take on the matter is right; I understood they invented the apartment stuff to allow multi-threaded apps to use COM components that had been designed without thread-safety in mind. Therefore STA enforces sequential access. And then they decided to make STA the default in .NET, since otherwise too many people would fall in the OpenFileDialog trap.

If you encounter clear proof otherwise, I sure want to hear from you and investigate.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).