|
Hey, thanks for the link. Glad to hear that the .NET framework does handle the threading issues automatically and that my VS.NET was not possessed, that the object is only created when first accessed  They are really making some things a lot easier in .NET. Can hardly wait for a few more versions down the road.
Anyone know how Mono handles this situation?
Rocky Moore <><
|
|
|
|
|
James, the singleton implementation works absolutely great, that's just what I needed. Thanks again. 
-Nick Parker
|
|
|
|
|
Singletons are  .
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
get
{
if( instance == null)
{ lock( lockObject)
{
if( instance == null )
{
instance = new A();
}
}
}
}
James, in the above code, why do you have to check for null two times, isn't that because of the threading issue, like before locking up the object if some other thread has accessed the property thus creating an instance 
thanks,
Kannan
|
|
|
|
|
Kannan Kalyanaraman wrote:
isn't that because of the threading issue, like before locking up the object if some other thread has accessed the property thus creating an instance
You got it 
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
Thank you, James
- Kannan
|
|
|
|
|
When printing a DataGrid using InvokePaint(myGrid, myPaintArgs) there is a small artifact in the upper left of the print-out. It goes away if the ColumnHeadersVisible property is set to false. I have tried setting the DataSource before setting this property to true thinking it might be a re-size issue.
Is anyone aware of a fix for this problem? Or have any other ideas of what might be causing it?
Thanx...
>>>-----> MikeO
|
|
|
|
|
I've been through several books on C# and its data types but I haven't found how to create records. If I have a definitions/classes where I'm trying to define addresses, everything about addresses is consistent between a shipping address, personal address, billing address, etc.
Please bear with the example and qualify/disqualify my understanding since I am converting from Delphi/Pascal.
My understanding of the C# implementation says I can't do something like (Delphi/Pascal structure):
Type TAddress = Record
AddressID : Integer;
Address : String;
City : String;
State : String;
ZipCode : String;
Country : String;
end; {TAddress}
and then define the variables:
private string PersonName;
private TAddress PersonAddress;
The impression is that I must create a class called TAddress with each field being a property that has a Set and Get attribute. Is this the case? I cannot create a new datatype without it being a class?
Along those same lines, if I want a "Globals" or "Constants" file, I would need to create a class and define each Global/Constant as a public variable. Are there pros/cons between creating a them as public variables verses as properties with a Get.
Thanks.
|
|
|
|
|
Well, here's what it sounds like: You need an Address type that you can use for shipping, billing, and personal addresses. You want to know if you can define a type without it being a class, you want to know the differences between properties and fields, and you want to know about globals...right? (If not, correct me. )
1) As for the address type. The proper way to define that in C# as a class would be:
public class Address
{
public int addressID;
public string address;
public string city;
public string state;
public string zipCode;
public string country;
}
However, because you don't really have any methods that belong to the Address class, and because you are really just holding data in this class, I would make it a struct. This makes it a value type that gets created on the stack rather than the managed heap. So just change the word class to struct.
Then somewhere else in your code you could do something like this:
Address personalAddress = new Address();<br />
personalAddress.addressID = 1;<br />
personalAddress.address = "123 Anywhere St."
Or even better, you could define a constructor for your struct/class that would let you specify some of the fields so that you don't have to do so much typing.
2) The difference between a property and a field is that the property is really just a pair of accessor methods for the field. You still need to define the field so that the property can store information. But the benefit of properties is that you can perform validation on the data that gets passed in or perform some action at the same time. They're really quite useful.
3) There isn't any concept of a global field/method/property/whatever in C#. The closest you're going to get is to define a class and have each member be public static. That way you don't have to instantiate a member of the class in order to act on that field/method/...
If you need any further clarification don't hesitate to ask. Hope that helps.
Hawaian shirts and shorts work too in Summer.
People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage...
-Anna-Jayne Metcalfe on Paintballing
|
|
|
|
|
for globals which is an insanely ugly world in programming and leads to all sorts of foobar'd results.
but the constants or actually enums I use I store in a main namespace, constants is more of a Java thing I think
namespace myIgnorantEnums
{
public enum Mine
{
None,First,Second,Third
}
}
then in your class file
using System;
using myIgnorantEnums;
Thats all there is to it but I would organize it in which the namespace it actually belongs to.
Look at the Data library, especially SqlTypes of that particular namespace.
|
|
|
|
|
Dave & Ista -
Thanks. That is exactly what I was looking for. Didn't even recognize the structs as the tool to use but, after reading on them, I believe that is exactly what I need. As for "Globals", you are right. "Constants" is the proper term. None of what I am referring are variables. The constants file will consist of the struct/classes, as discussed, enums and constants that are used through out the program but are not specific to a certain class.
Thanks.
|
|
|
|
|
My code is littered with DataSets and DataAdapters all over the place, with bound controls on various forms (and lots of duplication). I'm trying to create a more organized program by encapulating all the data access stuff in my own classes which will then handle their own data. So if I need, say a customer's name and account number, I can just say currCust.Name, currcust.AcctNum rather than having to go thru all the dataset stuff every place I need the info. I've been researching IBindingList but it looks like that is designed to work with DataGrids. Is that the right direction, though, or am I totally off-base? Is it even possible to do what I want or will I be forced to write all the data access in my classes rather than binding the controls?
|
|
|
|
|
I currently use several different layers of abstraction:
SAL – Server Abstraction Layer
This contains all the DataAdapters and raw access to a SQL server. Nothing server specific goes beyond this layer. This layer can be swapped out for a module that communicates via Web Services or other avenues of data maneuvering without effecting any other part of the program.
DAL – Data Abstraction Layer
This layer moves data. It uses the SAL layer to obtain data in datasets and provides data caching when required. No access to the SAL layer is available beyond this point.
BOL – Business Object Layer
I use these objects throughout the application. They communicate with the DAL layer and at their core is a DataSet which contains the actual data. At the cost of a little extra work, I make a DSD (Data Structure Definition) file that contains the actual field and table names in the DataSets. I access them by their members when I need to pull data from the datasets so that there is no direct reference to the fields inside the application. This means that if a change is made to the database, I would have to change to DLLs. The DataAdapters in the SAL would have to change and the field or table definition in the DSD DLL would change. The rest of the application would remain the same. It is usually best to have a single point of change but for my purposes, the DSD works fine.
To access data in a BOL DataItem derived class I simply use the global DSD such as:
public class DSD
{
public class DSDItem
{
private string dataBaseItemName=null;
private string itemName=null;
public string DataBaseItemName
{
get { return dataBaseItemName; }
}
public string ItemName
{
get { return itemName; }
}
public DSDItem(string dbItem, string Item)
{
dataBaseItemName=dbItem;
itemName=Item;
}
}
public class Books
{
public static DSDItem DataBaseTableName = new DSDItem("Books","Books");
public static DSDItem Book_ID = new DSDItem("Book_ID","Book_ID");
public static DSDItem BookTitle = new DSDItem("BookTitle","BookTitle");
public static DSDItem BookTitle = new DSDItem("BookAuthor","BookAuthor");
}
public class Stores
{
public static DSDItem DataBaseTableName = new DSDItem("Stores","Stores");
public static DSDItem Store_ID = new DSDItem("Store_ID","Store_ID");
public static DSDItem StoreName = new DSDItem("Name","Name");
}
public class Inventory
{
public static DSDItem DataBaseTableName = new DSDItem("Inventory","Inventory");
public static DSDItem Store_ID = new DSDItem("Store_ID","Store_ID");
public static DSDItem Book_ID = new DSDItem("Book_ID","Book_ID");
public static DSDItem Quantity = new DSDItem("Quantity","Quan");
}
}
DSD.Books.DataBaseTableName.ItemName - for access the table name
myDataRow[DSD.Books.Book_ID] – to access the actual fields to the dataset.
If the fields or table names change in the database I change the DSD DatabaseDataItem. Ther reason I have the DatabaseDataItem even included is that the DSD is also used in lower levels when querying the server. Thus, they all rely on the DSD.
If a person does not care about the other functionality, they can use a simple DSD type structure to access data in generic datasets and move all their queries into layer by themselves (similar to the SAL). Then throughout the application call that layer to move data in and out of datasets. When you want data, just use the DSD to access the fields or in data binding. I personally need much more functionality (such as caching and being able to use Web Services and even xml data sources) than that would provide along with having objects that contains the actual business logic.
They normally contain the business logic. Some times though you might want the business logic to be moved into a lower level, but for my purposes, it works well to have the business logic in these objects.
The BOL objects are derived from a DataManager object and a DataItem object.. The DataManagerItem object contains some handy routines to manipulate the data such as conversions to different types, null checking and stuff like that. The DataManager implements a IList and ITypedList interface. In my actual BOL objects, they will override the indexer ([]) and provide a type specific object.
Of course, there is more to it than mentioned, for example I have attributes on my DataItem fields to denote if they are bindable, read only, etc. The caching is provided on several levels so that I do not hit the server when I already have the data or when I want to maintain an array of data throughout the applications (such as State names) which will be used in popups or combos.
It took me the best part of a month (changed many times during that time ) to get mine all tied together and functioning with Caching as I required, but the end result allows the data to be modified or switched to difference sources without a lot of changes (if any) to the application.
The standard ORM's may be a better bet for most, but I am waiting to see what the new ORM in .NET 2.0 actually handles before going down that path. The method I used was strictly built out of need rather than a structured plan. I would rather had a more dynamic approach than fixed sets but time was limited.
Rocky Moore <><
|
|
|
|
|
Thank you very much for the detailed answer. Unfortunately, getting anything purchased around here is next to impossible so I'll have to wing it. Maybe on the next version of my software I'll be able to do something like this.
Thanks again.
|
|
|
|
|
For a ListView with MultiSelect = false how do I find the label of the selected Icon?
I’m hooking the SelectedIndexChanged event. And then it looks like I’m forced to iterate the SelectedItems collection with a foreach loop.
This seems stupid since only one item can be selected when MultiSelect = false.
I would like to do something like:
MyListView.Items(MyListView.SelectedIndex).Name
But there is no SelectedIndex property and does not look like I can use MyListView.Items in that way.
Do I have to iterate the SelectedItems collection for the single selected Item? How do you guys do this?
|
|
|
|
|
This gives access to the "Selected Index".
listView1.FocusedItem.SubItems[0]
|
|
|
|
|
Thanks Draco,
Not sure how I missed that one.
I added this to the click event:
listView1.FocusedItem.Text
|
|
|
|
|
albean wrote:
Not sure how I missed that one.
Because it's not really a standard thing in the framework. Usually it's SelectedIndex or SelectedItem. You could also use the SelectedIndices property...and then the first selected index would be listView1.SelectedIndices[0].
Hawaian shirts and shorts work too in Summer.
People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage...
-Anna-Jayne Metcalfe on Paintballing
|
|
|
|
|
How can I write a Datatable to and XML file.
|
|
|
|
|
check out the intellisense its in black and white. Good luck with school
|
|
|
|
|
Hey all,
I'm wondering how I can get the version and build info from AssemblyInfo.cs to display in my program. I'm making an "About Box" and I'd like to be able to display this info on a label in the box. Can anyone help me out?
|
|
|
|
|
Application.ProductVersion
|
|
|
|
|
Is there a way to make it just show the major/minor version? Or only the build number?
|
|
|
|
|
Version ver = new Version(Application.ProductVersion);
string s = String.Format("v. {0:#}.{1:#}.{2:#}.{3:#}", ver.Major, ver.Minor, ver.Build, ver.Revision);
Check out the Version class in Help for more info.
|
|
|
|
|
I have CodeObjectList class in which I implmeneted IBindingList, ITypedList, IComponent, IListSource
When I do this
(ComboBox named cboCode)
(cList is the above class)
cboCode.DataSource = cList;
cboCode.DisplayMember = "Description";
it works fine
but
cboCode.DataBindings.Add("Text", cList, "Description");
the it just shows the first item as text and no drop down menu selections.
How come, how do I modify it to use the data bindings collection?
thanks
nick
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
