|
I assume Winforms so here is one of the many results here on CP:
link1
Search is the key
Just an irritated, ranting son of ... an IT guy.
At your trolling services
|
|
|
|
|
Exactly what i was looking 4..
Tnx
Roy
|
|
|
|
|
If its web you may look forward to coolite [^]toolkit.
|
|
|
|
|
There's an editable datagridview populated from a table say tblItems. Among the columns of the datagridview there's a combobox column named 'Category'. This column is populated by the respective 'Category' column of tblItems. Now in the 'Category' column of the datagridview I want to set the value of a certain cell to Null programmatically. Suppose when I press keyboard Delete button over the cell or some other button on the form, the value of the cell becomes Null. Datagridview.keydown event isn't working as when the cell is selected the focus is actually on the editingcontrol of the cell and not the datagridview. Also the combobox editingcontrol doesn't have any 'SelectedIndex' property that can be set to -1. Any idea plz? Regards.
|
|
|
|
|
Add an item to your list in position 0 with a value 0 and a label of string.empty.
Set the selected index to 0.
Deal with the 0 value on the way out, when you write to the database.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
The thing is, the EditingControl property of the grid and the e.Control property in the EditingControlShowing event handler are both type Control, because they have to be able to refer to any control. If you're currently editing a combo box column though, you know that the actual object is type ComboBox (to be more precise, type DataGridViewComboBoxEditingControl) so you have to cast it as that type in order to access members of that type. This is the case no matter what objects you're dealing with: you must have a reference of the correct type to access members of that type. E.g.
ComboBox cbx = (ComboBox)myDataGridView.EditingControl;
cbx.SelectedIndex = -1;
modified on Monday, June 14, 2010 12:11 PM
|
|
|
|
|
You missed the point, this is all about managing your data not the control. The control does not deal with null so supply an alternative. It is your data, decide how you can do this, I would add a default data item into the underlying dataset and use that as the null substitue.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
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?
|
|
|
|
|
The Value property would give the checked state of the cell.
BTW, instead of casting, you can use as keyword along with the null check.
|
|
|
|
|
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 />
|
|
|
|
|
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.
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).
|
|
|
|
|
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.
|
|
|
|
|
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.
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).
|
|
|
|
|
The property Value will have value as true or false. Try casting that to boolean.
|
|
|
|
|
Please check my reply to Luc.
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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:
public static void Main(string[] args)
{
_con = new DW_DB_Connection();
Start_Threads();
}
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
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).
|
|
|
|
|
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.
In Christ,
Aaron Laws
http://ProCure.com
|
|
|
|
|
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.
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).
|
|
|
|
|
Then look at the CPU utilization, it can't go above 1 core if they're just using clever scheduling instead of true multithreading.
|
|
|
|
|
Dear Mr. Aptroot,
This is correct. I'll have to profile it that way later (when I get some clients). But I would hate to develop the application, then figure out I'm only getting one thread later and have to restructure!! That's why I wanted to know now.
In Christ,
Aaron Laws
http://ProCure.com
|
|
|
|