|
donsolms wrote: it does, but you can use it in a normal class as well
You can - but it doesn't actually accomplish much.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes.
Robert
|
|
|
|
|
Robert Rohde wrote: You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes.
Only from .NET 3.5 onwards. At the time of replying to this post, we had no idea that the poster was using Orcas and not asking questions about current versions of .Net.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
donsolms wrote: Which is better according to coding standard for c#?
this:
public bool isDraggable
{
get { return _draggable; }
set { _draggable = value; }
}
or this:
public bool isDraggable{ get; set; }
without using private members? Or is this a matter of personal choice?
Well - the 1st is a better coding standard because it actually does something. The second doesn't actually accomplish anything. You would normally use the second one in an interface.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
donsolms wrote: Which is better according to coding standard for c#?
this:
public bool isDraggable
{
get { return _draggable; }
set { _draggable = value; }
}
or this:
public bool isDraggable{ get; set; }
without using private members? Or is this a matter of personal choice?
Hi,
For Orcas, I thought that these were essentially identical, that the compiler would generate some private fields for you. Perhaps I've missed something - I'm living in a .NET 2.0 world - but, that was my understanding of it. I suspect someone will correct me if I'm wrong.
Hope that helps.
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
that's what I thought as I'm in Orcas. I'll just stick to my usual style. Thanks for everyone's feedback
rather have something you don't need, than need something you don't have
|
|
|
|
|
as a general comment if you're asking about something new in a beta/just released version it's generally best to indicate it to avoid confusion.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
Matthew Cuba wrote: the compiler would generate some private fields
Ew, I wouldn't want that. Having the compiler create a default constructor is one thing, but generating fields? Yuck!
|
|
|
|
|
Matthew Cuba wrote: For Orcas, I thought that these were essentially identical
That is true, .NET 3.5 introduced the idea of automatic properties. The only drawback is that it doesn't provide any way to do validation and you must always have both a get and a set.
|
|
|
|
|
My preference would almost always be the first example. The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter. Both of thees example are equivalent, with the second one allowing the compiler to automatically generate the backing variable.
I have used both styles, and generally only use the second for very simple classes and structs.
For future reference, you should be clear that you are referring to a .NET 3.5 (Orcas) feature, especially with this question as the second example is also the way a property is defined in an interface.
|
|
|
|
|
Scott Dorman wrote: with the second one allowing the compiler to automatically generate the backing variable.
<rant>
Man, that's gotta be about the dumbest thing I've heard Microsoft do recently. Does that mean even the class itself is required to use the property? I hope the calls will be inlined.
</rant>
On the other hand, maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal.
|
|
|
|
|
PIEBALDconsult wrote: maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal
That's polluting the gene pool - we wouldn't want that.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
In theory, I agree with you. In practice, however, I don't mainly because there are already a lot of cases where Microsoft is generating code for you. If you use any .NET remoting or serialization, the JIT is compiling an entire assembly on-the-fly at runtime for you; the using statement, ~T (finalizer), anonymous delegates, and generics all generate code at compile time on your behalf. There really isn't a way around it anymore...if you use .NET at somepoint Microsoft is generating code for you either at compile time, run time, or both.
PIEBALDconsult wrote: Does that mean even the class itself is required to use the property?
I'm not sure what you mean by this. In the class, when you want to reference the property you use it just like you would any other property. The only difference is that there isn't an excplict backing variable that you could access instead, so you always use the property.
PIEBALDconsult wrote: I hope the calls will be inlined.
How would this matter? I don't believe they are, since this is really just more syntatic sugar, the compiler treats them just like it would any other property.
|
|
|
|
|
Scott Dorman wrote: The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter.
Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference.
Robert
|
|
|
|
|
Robert Rohde wrote: Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference.
Yes, you can change it to a "real" property anytime you want without affecting the callers. My only issue with automatic properties is that it forces both a get and a set on the property and they must both be at the same access level.
|
|
|
|
|
Another issue is newbies who learn the lazy way and never learn the "better" way, and therefore wind up giving more access to their classes because they don't know any better.
|
|
|
|
|
So I wrote a clever little search tool for my list view that searches through all the items as you type. The Item.Select() and Item.EnsureVisible() work fine at runtime until I decide to TAB into the listview. At which point if I try browsing the listview using the arrow keys, I start browsing from the Item that was selected BEFORE I did my search.
Here's the basic gist of my search:
for(int i = 0; i < listView1.Items.Count;i++)<br />
{<br />
if (itemContains(targetstring, (ListViewItem)listView1.Items[i].Clone()))<br />
{<br />
listView1.Items[i].Selected = true;<br />
listView1.Items[i].EnsureVisible();<br />
return;<br />
}<br />
}
I've tried unselecting the previous selected item when a valid item was found, but that didn't seem to work. When I output SelectedItems[0].ToString() it output the correct Item. It's only when I gain focus to the listview using TAB that it treats the last item selected by mouse click as the selected item.
Any ideas here? It'd be much appreciated.
-J.Chalfant
|
|
|
|
|
Well, I figured this out.
Selected != Focus
and setting item[i].Focus = true won't take focus away from my textbox. So I can type away to my hearts content and set focus to however many listview items I want to. And when I TAB to select my listview, my selected item will still have focus.
Here's the new code:
for(int i = 0; i < listView1.Items.Count;i++)<br />
{<br />
if (itemContains(target, (ListViewItem)listView1.Items[i].Clone()))<br />
{<br />
listView1.Items[i].Focused = true;<br />
listView1.Items[i].Selected = true;<br />
listView1.Items[i].EnsureVisible();<br />
return;<br />
}<br />
}
Yay.
|
|
|
|
|
I tried to use modeless lookup form for DataGridView custom ComboBoxColumn without success.
Steps to reproduce issue:
1. Run code
2. Enter some character
3. Press Tab
Observed:
1. Next row receives focus
2. Current form remains active
Expected:
1. Focus should remain in current combobox.
2. Lookup form must become active form.
How to fix ?
Andrus.
using System;<br />
using System.Windows.Forms;<br />
<br />
class ComboBoxColumn : DataGridViewComboBoxColumn {<br />
}<br />
<br />
class ComboBoxCell : DataGridViewComboBoxCell {<br />
<br />
public override Type EditType {<br />
<br />
get {<br />
return typeof(ComboBoxEditingControl);<br />
}<br />
}<br />
<br />
}<br />
<br />
class ComboBoxEditingControl : MyComboBox, IDataGridViewEditingControl {<br />
<br />
protected int rowIndex;<br />
protected DataGridView dataGridView;<br />
protected bool valueChanged = false;<br />
<br />
protected override void OnTextChanged(EventArgs e) {<br />
<br />
base.OnTextChanged(e);<br />
NotifyDataGridViewOfValueChange();<br />
}<br />
<br />
protected virtual void NotifyDataGridViewOfValueChange() {<br />
this.valueChanged = true;<br />
<br />
if (this.dataGridView != null) {<br />
this.dataGridView.NotifyCurrentCellDirty(true);<br />
}<br />
<br />
}<br />
<br />
public Cursor EditingPanelCursor {<br />
<br />
get {<br />
return Cursors.IBeam;<br />
}<br />
<br />
}<br />
<br />
public DataGridView EditingControlDataGridView {<br />
get {<br />
return this.dataGridView;<br />
}<br />
<br />
set {<br />
this.dataGridView = value;<br />
}<br />
}<br />
<br />
public object EditingControlFormattedValue {<br />
<br />
set {<br />
<br />
if (value.ToString() != this.Text) {<br />
<br />
this.Text = value.ToString();<br />
<br />
NotifyDataGridViewOfValueChange();<br />
<br />
}<br />
<br />
}<br />
<br />
get {<br />
<br />
return this.Text;<br />
<br />
}<br />
<br />
}<br />
<br />
public object GetEditingControlFormattedValue(DataGridViewDataErrorContexts <br />
context) {<br />
<br />
return this.Text;<br />
<br />
}<br />
<br />
<br />
<br />
public void PrepareEditingControlForEdit(bool selectAll) {<br />
<br />
}<br />
<br />
public bool RepositionEditingControlOnValueChange {<br />
<br />
get {<br />
return false;<br />
}<br />
}<br />
<br />
public int EditingControlRowIndex {<br />
<br />
get {<br />
return rowIndex;<br />
}<br />
<br />
set {<br />
this.rowIndex = value;<br />
}<br />
}<br />
<br />
public void ApplyCellStyleToEditingControl(DataGridViewCellStyle <br />
dataGridViewCellStyle) {<br />
DropDownStyle = ComboBoxStyle.DropDown;<br />
}<br />
<br />
public bool EditingControlWantsInputKey(Keys keyData, bool <br />
dataGridViewWantsInputKey) {<br />
return !dataGridViewWantsInputKey;<br />
}<br />
<br />
public bool EditingControlValueChanged {<br />
<br />
get {<br />
return valueChanged;<br />
}<br />
<br />
set {<br />
valueChanged = value;<br />
}<br />
}<br />
<br />
<br />
<br />
public class Form1 : Form {<br />
<br />
private DataGridView dataGridView1 = new myDataGridView();<br />
<br />
[STAThread]<br />
public static void Main() {<br />
try {<br />
Application.Run(new Form1());<br />
}<br />
catch (Exception e) {<br />
MessageBox.Show(e.ToString());<br />
}<br />
}<br />
<br />
public Form1() {<br />
this.Controls.Add(this.dataGridView1);<br />
this.Load += new EventHandler(Form1_Load);<br />
}<br />
<br />
private void Form1_Load(object sender, EventArgs e) {<br />
<br />
ComboBoxColumn comboBoxColumn = new ComboBoxColumn();<br />
ComboBoxCell ComboBoxCell = new ComboBoxCell();<br />
comboBoxColumn.CellTemplate = ComboBoxCell;<br />
dataGridView1.Columns.Add(comboBoxColumn);<br />
}<br />
}<br />
}<br />
<br />
public class MyComboBox : ComboBox {<br />
<br />
protected override void OnValidating(System.ComponentModel.CancelEventArgs <br />
e) {<br />
<br />
e.Cancel = true;<br />
base.OnValidating(e);<br />
Form f = new Form();<br />
f.Text = "Modeless lookup form";<br />
f.Show();<br />
}<br />
}<br />
<br />
public class myDataGridView : DataGridView {<br />
<br />
protected override void OnDataError(bool displayErrorDialogIfNoHandler, <br />
DataGridViewDataErrorEventArgs e) {<br />
e.Cancel = false;<br />
}<br />
}
Andrus
|
|
|
|
|
Am trying to add a new row to the gridview. I have found articles where they use footerrow to add new row. The samples are using template columns but am using bound columns.
Can I use footer for adding new row for bound columns too?
Is there any other way to add a row to Gridview which is a better practice?
Thanks
|
|
|
|
|
Insert and empty row in to your datasource, then set that row as editable in the datagrid.
only two letters away from being an asset
|
|
|
|
|
Thank you Mark. That is excellent.
From button click event, how do I found out the editindex of a particular row?
Thanks
|
|
|
|
|
What button are you clicking? Check the eventarg.
only two letters away from being an asset
|
|
|
|
|
You can set the EditIndex like this:
GridView.EditIndex = GridView.Rows.Count;
Hope this helps!!!
____________________________
"The only true wisdom is in knowing you know nothing."
-- Socrates
|
|
|
|
|
Thank you.
Thanks
|
|
|
|