|
Hello,
i have DataGridView, with ComboBox cell in it.
i want that after the client clicked a button, the combo will be cleaned like at the moment it was first created (index = -1).
how can i do it?
the only property that the cell exposes is Value, but when i set it to "null" or to empty string, it does not do the work. can i get the inner ComboBox somehow?
i spent a few good hours on this but no success so far.
Thank you, Liran.
|
|
|
|
|
have you tried casting the cell to a DataGridViewComboBoxCell first and then setting it through that?
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
I don't think you have Index property for DataGridViewComboBoxCell. MSDN link[^]
जय हिंद
|
|
|
|
|
Oh right, that's not very good then... suppose could just set the value to "" then (providing the style is not set to DropDownList) but then you could clear Items then reload them, that should reset it to it's default.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
The problem is, that the BindingSource behind the CurrentValue does not accept nulls, so it yells at me with exceptions that the value is not valid..
|
|
|
|
|
Set AllowDBNull property to true.
जय हिंद
|
|
|
|
|
If the column is databound, then:
1. Set the AllowDBNull property of the Valuemember column to true.
2. Create a DataRow with ValueMember column value as null and DisplayMember as "--Select--" or " ".
3. Insert this row at the first position of your datatable.
जय हिंद
|
|
|
|
|
Hi,
I have a User control,which have a textbox and a button,this user control is being used in a windows form.
The windows form have a method, which I want to call in user control.
can someone help me in doing this, code sample will be appreciated.
Thanks in Advance.
Regards
Mahesh
modified on Thursday, May 28, 2009 5:26 AM
|
|
|
|
|
well, in user control...
FormMain mainForm = (FormMain)this.Parent;
mainForm.CallFunction();
or you could store a static instance of your main form somewhere, then...
ClassStatic.MainForm.CallFunction();
or, probably what i would go for, create an event handler in the usercontrol that the main form is listening for... Then you just fire the event in your usercontrol... In user control class...
public delegate void MyUCEventHandler(object sender, EventArgs e);
public event MyUCEventHandler UCEvent;
protected virtual void OnEventCall(EventArgs e)
{
if(UCEvent != null)
UCEvent(this, e);
}
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Option 3 is the better from an OO point of view.
It is a better design aproach to 'inform' the outside when the state within a class changes. That way there is little or no coupling from the referenced class, in this case the control, and the referencing class, the form.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
ok, I admit I was assuming that the control was intended to be used in multiple forms. So how would you 'inform' the form of a change?
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
musefan wrote: So how would you 'inform' the form of a change?
An event! I said, and Wavey Davey concurred, the event approach is the safestest.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
Oh right, I misunderstood your post thinking you were saying that an event would not be the best option in this case. i.e if a control is only intended to be used in one form then it should talk directly with the form itself...
Nevermind
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Use musefan's 3rd option above - the event driven one. If you're just wanting the signature to be the standard
object sender, EventArgs e then you don't need to create your own delegate, just use EventHandler like this:
public event EventHandler UCEvent;
protected virtual void OnUCEvent(EventArgs e)
{
EventHandler eh = UCEvent;
if(eh != null)
eh(this, e);
}
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
I agree with all of them! Use option 3.
If this is your first time doing this, then you may need more detail:
In your child form:
public partial class frmDetail : Form
{
public delegate void OnChangeHandler(object sender, EventArgs e);
public static event OnChangeHandler OnChange;
private void DoSomethingToChangeData()
{
OnChange(file, null);
}
}
In your main form:
public frmMain()
{
frmDetail.OnChange += new frmDetail.OnChangeHandler(OnChanged);
}
private void ChangeCards()
{
frmDetail fd = new frmDetail(currentDetail);
fd.ShowDialog();
}
private void OnChanged(object sender, EventArgs e)
{
FileChanged = true;
}
It is pretty simple when you get your head around it!
[edit] Changed to move add event handler out of frmDetail instance create - we don't want another event each time ChangeCards is called, do we? My brain is not working - it must be thursday [/edit]
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
A few problems. Avoid the Onxxx for the event name, that should be saved for the method that raises the event - in your example the event should be either Changing or Changed dependending on when it's fired.
An inheritor of your class may need to add functionality so the event itself should be raised in a separate protected virtual method OnChanging or OnChanged with that method taking the event args.
In your child form snippet, you call the event directly. If there are no subscribers, this will generate a NullReferenceException. At a minimum you should null check.
protected virtual void OnChanged(EventArgs e)
{
if(Changed != null)
Changed(this, e);
} There is a possibility (unlikely) that 'Changed' could change between the null check and the event raise line, so either a copy should be created and work on that copy:
EventHandler eh = Changed;
if(eh != null)
eh(this, e); or it should be put in a try/catch block.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
Sorry. (I feel really small, now)
Your comments are (as always) correct, so I modified it.
In the child form:
public partial class frmDetail : Form
{
public delegate void ChangeHandler(object sender, EventArgs e);
public static event ChangeHandler Changed;
protected virtual void OnChanged(EventArgs e)
{
ChangeHandler ch = Changed;
if (ch != null)
{
ch(this, e);
}
}
private void DoSomethingToChangeData()
{
OnChanged(null);
}
}
I am not sure a try - catch block would be a good idea: it's not an error to not have a handler, and the throw/catch will be slow. But that is just me.
In the main form:
public frmMain()
{
frmDetail.Change += new frmDetail.ChangeHandler(Changed);
}
private void ChangeCards()
{
frmDetail fd = new frmDetail(currentDetail);
fd.ShowDialog();
}
private void Changed(object sender, EventArgs e)
{
FileChanged = true;
}
Better?
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Yeah
Static events are pretty dangerous, unless you explicitly unsubscribe from the event, the subscribing object will stay in memory even when you think it's gone as a reference is held to it in the delegate's invocation list!
Normally it's better to use instance ones, in which case you'd need a class level member variable
frmDetails fd; and then (possibly in the constructor)
fd = new frmDetails;
fd.Changed += ...
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
DaveyM69 wrote: Static events are pretty dangerous, unless you explicitly unsubscribe from the event, the subscribing object will stay in memory even when you think it's gone as a reference is held to it in the delegate's invocation list!
Normally it's better to use instance ones, in which case you'd need a class level member variable
frmDetails fd;
Yeeeees... I think I'd rather unsubscribe, or you will always have the memory allocated to the form instance anyway...
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Thanks to all for the help,
I am able to implement it.
Regards
Mahesh
|
|
|
|
|
Hi all,
I was browsing the net and stumbled upon the following piece of code and stated to wonder, is it better to open a connection to the database once and make use of it until the application closes or open and close it after each use during the application life cycle?
Code snippet[^] being referred to.
Many thanks in advance
Kind regards,
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|
|
Easy one... Open and close it each time. Don't keep an unused connection open, it's just a waste of resources. Once a connection has been made, it will get put in the pool anyway (providing you have connection pooling on) so the next time it connects it won't take as long.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Thanks for the response.
Just a quick one though.... Even if you have to insert X amount of records every couple of seconds / minutes?
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|
|
Well it depends... if you don't know how long between inserts then yes still open close each time, actually even if you know it will be every second on the dot I would still go for Open/Close each time. The only time I would keep it open is if I was going to do all the inserts at the same time with no other stuff being done in between.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Thanks for the info.
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|