Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
rtutus
Aged Yak Warrior
522 Posts |
Posted - 2006-05-20 : 00:51:49
|
I have my class with properties and methods.I create an instance of the class and get some of its properties in my forms. When I go back to the class and try to access that property from inside the class itself, I see that it has a NOTHING value. 1/ How do I keep the value of the property between calls and instantiations of the class when I sometimes instantiate the class from different forms in my application.2/ What is this technique called in Microsoft Jargon. I mean when I go back to the properties and finding them again not reset to nothing3/ What s the best way to design my class in order to keep its properties and also if I want it to reset its properties to nothing between instantiationsThanks |
|
dfiala
Posting Yak Master
116 Posts |
Posted - 2006-05-20 : 01:31:10
|
ASP.NET Web Forms answer:1) a class instance is like any other variable type on a page -- it disappears once the page completes renderingIn other words, it "goes out of scope", this is a generally used programming term. Web sites are scalable because they don't maintain a lot of state between calls. To get around this you have three basic places to maintain class instance information between calls, and a few options on how exactly to implement them.a) Page level, for information that is only valid for the pageb) session level, for information that is specific to a user session and needs to be shared among multiple pagesc) application level, information that can be or needs to be shared for ALL users throughout the application.For page level persistence you can use View State...'save itViewState.Add("SOmethingINeedLater",ImportantCLass(blah, blah, blah))'read itDim SomethingINeed as ImportantClass = ViewState("SomethingINeedLater")Note that the object needs to be serializable, and if it is really large, it will bloat your page. In which case you will want to use...'save itSession.Add("SOmethingINeedLater",new ImportantCLass(blah, blah, blah))'read itDim SomethingINeed as ImportantClass = Session("SomethingINeedLater")Session variables are available for all pages through the user session, and are best for large objects so you are not blowing bandwith and slowing page rendering to a crawl with viewstate. However, session variables DO eat server memory, so don't over do.For application level variables, you have three choices:i)Application variables, that look very similar to Session variablesii)Web Caching,fancy hashtables that have all kind of neat tricks for managing memoryiii)Shared (static in C#) classesApplication variables and Shared classes survive the life of the application. There is only one instance to each that is shared throughout the application, so they are best for static data that is not session or user dependent. Web caching, while neat, is probably not what you want here, because there is a possibility the cache will empty an object you want to perserve memory. I tend to use shared classes for this sort of thing. You don't have to worry about casting, and you don't need to create a class, stuff it in an app variable and then retrieve it for use. You just get the goodies by referencing a shared member of the class.Dim SomeString = MyLongLastingClass.APropertyNote you don't create an instance, you just use the class name to use a shared member.Win Forms answer:1) hide your forms instead of disposing them, then their contents don't go out of scope and disappear.2) use shared classes or application variables (See above)Dean FialaVery Practical Software, IncNow with Blogging...http://www.vpsw.com/blogbabyMicrosoft MVP |
 |
|
rtutus
Aged Yak Warrior
522 Posts |
Posted - 2006-05-20 : 14:03:22
|
Thanks a lot, one more question if u don t mind (a long one)Let's say I have an account form associated to the class (clsAccount). Each account has many phone numbers (different instances of the class: clsPhone). Also each account has instances of the class invoice (clsInvoice).But in my application I open several accounts at the same time, each is displayed on its own account form. The account objects are :objAccount1, objAccount2...Each account (objAccount) has different child objects : objPhone1, objPhone2,...., ObjPhoneNEach account (objAccount) has different child invoices instances (objInvoice1, objInvoice2....objInvoiceN)When the user is working on one of the account forms related to the account number 3: objAccount3 and he clicks on the Invoice number i button, I want to give the focus to the right invoice (number i) related to the right account (objAccount3)And when he is on an other account form related to the account number 4 for example (objAccount4) and he clicks on the invoice i button, I want to give the focus to the right invoice that belong to the current account (objAccount4).How do I design and go with all this?Thanks for your help. |
 |
|
dfiala
Posting Yak Master
116 Posts |
Posted - 2006-05-20 : 20:53:34
|
The simple way to organize this would be with collections.Each account object would have a collection of invoices and a collection of phone numbers.When you open up the form you would load your associated account object, which would in turn load its child invoice and phone number collections. By actually coding the relationship you will know that the objects are properly associated.Now, there are a number of collection classes you could use, but in this case I'd use either an ArrayList or a Hashtable. The ArrayList is fine if you just need a simple collection that you will usually just loop through. The Hashtable is better if you will not be working with all the objects in the collection at the same time and need to pull out specific objects via a key.So you'd end up with something like this....Public Class Account Private mInvoices as ArrayList Private mPhoneNumber as ArrayList Private mAccountNumber as String Public Sub New(AccountNumber as String) 'Your code to retrieve and populate the account object... mAccountNumber = AccountNumber LoadInvoices() LoadPhoneNumbers() End Sub Private Sub LoadInvoices() 'Create a new Array List mInvoices = new ArrayList 'Pull your invoices back from the db , loop through and create your child invoices Dim InvoiceData as DataTable = SomeFunctionThatGetInvoiceDataForAnAccount(mAccountNumber) Dim InvoiceRow as DataRow Dim InvoiceInfo as Invoice For Each InvoiceRow in InvoiceData.Rows 'create the object for the row, this is just an example, the important thing is to create a new object 'and fill it with the proper data InvoiceInfo = new Invoice(InvoiceRow) 'Add it to your collection mInvoices.Add(InvoiceInfo) NextEnd SubPublic Readonly Property Invoices() as ArrayList Get Return mInvoices End GetEnd Property'Repeat for Phone NumbersEnd ClassThat's basically the idea. Very classic OOP use of collections to relate child objects to a parent.Dean FialaVery Practical Software, IncNow with Blogging...http://www.vpsw.com/blogbabyMicrosoft MVP |
 |
|
rtutus
Aged Yak Warrior
522 Posts |
Posted - 2006-05-21 : 17:53:32
|
Thanks a lot dear Dean Fiala. Beautiful explanation (better than any university course:) )I ll try to implement and learn your sugested ideas when I do that.One little question in the meanwhile:What do u mean When u say: By actually coding the relationship you will know that the objects are properly associatedDo you mean that that s done by implementing the code y suggested above. I mean: what part of the code does implement that association between the objects. Is there anything else I should include in order to do so.Thanks a lot |
 |
|
dfiala
Posting Yak Master
116 Posts |
Posted - 2006-05-21 : 19:34:52
|
When you create a collection of invoice objects in the account object (assuming you only load invoices associated to the account) you are coding the relationship between the account and its invoices. So yes, the examples I sent you does attempt to show that.Dean FialaVery Practical Software, IncNow with Blogging...http://www.vpsw.com/blogbabyMicrosoft MVP |
 |
|
rtutus
Aged Yak Warrior
522 Posts |
Posted - 2006-05-21 : 20:39:39
|
Another question pls, In my account form, I have one tab for the phone object that the user wants to be displayed (phone number i in the phones collection)Each phone by itself has many properties: phone number, activation date, Equipment....and a set of features and options. The Equipment Object/Property of the Phone object has itself many properties : serial number, Technology, Manufacturer.....Each feature Object/Property has also itself many properties that I need to diplay to the user: Feature code poperty, Feature description property, Feature Activation date property.....My question: for better design practices, is it better to create in my classes all the properties that I need to diplay: Serial Number property, Manufacturer poperty, Phone Activation Date property. And for each feature, should I create as many properties as the textboxes that I need to diplay to the user: Feature code poperty, Feature description property, Feature Activation date property.....Because that d involve a huge number of properties in my classes.Or should I create just the textboxes and the labels in my forms without associating them necessarily to properties within my classes.(I hope I expressed my self in a way that made sence)Gracias amigos. |
 |
|
rtutus
Aged Yak Warrior
522 Posts |
|
dfiala
Posting Yak Master
116 Posts |
Posted - 2006-05-25 : 08:34:40
|
Thanks. In 2.0, they've formalized an approach for binding to custom business objects -- http://msdn2.microsoft.com/en-us/library/1se6685s.aspxYou can also check out Typed DataSets, http://msdn.microsoft.com/msdnmag/issues/04/12/DataPoints/default.aspx, though I always thought they were overkill and they seem to have been eclipsed by other approaches.Sorry I missed this post earlier -- glad you found a workable approach.Dean FialaVery Practical Software, IncNow with Blogging...http://www.vpsw.com/blogbabyMicrosoft MVP |
 |
|
|
|
|
|
|