|
Hey Colin,
That's true, it does extend hashtable - but the real value of the Properties class comes in the utilities it provides for saving/loading that hashtable's contents to streams in different formats (XML, flat file, etc.) This capability is what I am looking for. If I don't find it I'll have to write it and post it here 
|
|
|
|
|
using application/ user settings in c# is at least as easy as properties in java. however, c# settings are serialized in xml, whereas properties are not.
|
|
|
|
|
I have a predefined user control designed at design time, and want it to load a form at runtime
it seems simple but i can't get it to work
pls help
|
|
|
|
|
Don't you just make an instance of the control and the add it to the form, like so:
MyCtrl control = new MyCtrl();
control.ClientSize = new Size(100,25);
control.Location = new Point(3,3);
...
myMainForm.Controls.Add(control);
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
Yes thanks!!!
I used the same way but made an error in the namespace
|
|
|
|
|
I put a binary file into a table in a dataset. I then write my dataset as a XMLfile using DataSet.WriteXML
When I look at the field with my file-content I have a string wich look like this ...
"<content>/9j/4AAQSkZJRgABAgEAYABgAAD/7ABzRHVja3kAAQAEAAAAPAADAF4AAAAtA<"
What kind of string is that? How can I get it without using dataset/writexml to get it?
I have a special solution where I need to get that string.
Please hekp // henrik
|
|
|
|
|
How are you storing your binary file before putting in the datatable? If you store binary file in byte[] then Google for 'convert byte array to string' You can use BinaryReader class for reading binary data.
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
I think the DataSet uses Base64 encoding when it serializes binary fields into XML. I may be wrong, but it is the most common way to encode binary data in XML.
To read it, you could use a System.Xml.XmlReader (and its ReadElementContentAsBase64 method once you've located the correct field). However, the normal way to do it would be to recreate the dataset from the XML file, though (using ReadXml on a new dataset)...
If for some reason you don't want to use the system-provided XML tools and instead want to read the file as text and do your own decoding, you can either google for base64 or use, for example, System.Convert.FromBase64String.
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
Yeap ... It is base64 ...
Found the solution yesterday ...
Thanks // HenrikDaSwede 
|
|
|
|
|
MaWeRic wrote: Thanks // HenrikDaSwede
We are the turnips[^]. You will be assimilated. Resistance is futile... 
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
The app I'm working on has quite a lot of collections, some of which will hold several thousand items that have numerous fields - some of which are collections themselves.
At the moment I'm leaving everything to GC automatically and it's working, but I'm concerned that it may cause problems in production on lower spec machines if GC doesn't reclaim the memory.
Would I be better implementing IDisposable? Are there any pitfalls to doing so?
Dave
|
|
|
|
|
Since you don't have code that access unmanaged memory, no need of implementing a dispose pattern. GC is efficient and it will take care AFAIK.
|
|
|
|
|
Well...that's only partially true. If any of the objects in the collection implement IDisposable then he should also implement IDisposable so that those objects can get cleaned up when the collection goes out of scope or gets collected.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
You are correct scott. Thanks for pointing it out.
|
|
|
|
|
The short and simple answer is: "Probably, yes." However, you haven't really provided a lot of details.
A couple of questions to think about:
1. Do any of the objects that will be contained in the collections implement IDisposable?
2. How large are the objects that will be contained in the collections?
If any of the collection items implement IDisposable, then yes, you definately should implement IDisposable so your collection can call Dispose on the items.
If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
You can take a look at this article[^] for more information on IDisposable in general.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Thanks Scott.
None of the objects implement IDisposable directly but use methods that use objects that do - although these are all in using blocks.
Most of the items will be greater than 85K so I'll implement it.
Article bookmarked for investigation! 
Dave
|
|
|
|
|
Scott Dorman wrote: If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
Setting the items to null serves no purpose at all. It's just a lot of work that doesn't result in the items being collectable any earlier.
Just set the reference to the collection to null, and everything that it contains (that isn't referenced from anywhere else) is immediately collectable.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Setting the items to null serves no purpose at all
Not entierely true. Since large objects (greater than 85,000 bytes) don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use. This only applies to large objects...anything smaller and it is extra work but also causes no harm.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use.
Haven't heard of that one before. AFAIK, no GC related action happens when a reference is set to null and I don't see how it could be different for large and small objects.
Do you have any reference for that claim?
|
|
|
|
|
S. Senthil Kumar wrote: Do you have any reference for that claim?
Take a look at this article from Joe Duffy: http://www.bluebytesoftware.com/blog/PermaLink,guid,88e62cdf-5919-4ac7-bc33-20c06ae539ae.aspx[^]
Consider nulling out large managed object fields in your Dispose method. This is seldom necessary, but should be considered when a field is expensive to keep around, yet its owning object might be held on to longer than necessary. Simply because Dispose was called does not mean that its reference is being released. This could happen, for example, if its container (the object being disposed) is referred to from within a long-running scope (or stored in a static variable), and not explicitly nulled out. Doing this could help to reduce the lifetime of the object by making it eligible for garbage collection sooner. The definition of large and expensive is of course subjective and should be based on performance profiling and measurement. There were also a set of MSDN articles by Jeff Richter, but those appear to have been removed from the MSDN website...still looking around for other copies.
Also, take a look at this article, and specifically the comments from Wesner: http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx[^]
Or the second paragraph http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/10/128999.aspx[^]
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: ince large objects (greater than 85,000 bytes) don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use.
Do you have any documentation to back that up?
AFAIK, it doesn't matter att all where the objects are allocated. The garbage collector only looks at the active references. If an inactive reference points to an object on the large objects heap, that doesn't turn it into an active reference.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Do you have any documentation to back that up?
Take a look at this article from Joe Duffy: http://www.bluebytesoftware.com/blog/PermaLink,guid,88e62cdf-5919-4ac7-bc33-20c06ae539ae.aspx[^]
Consider nulling out large managed object fields in your Dispose method. This is seldom necessary, but should be considered when a field is expensive to keep around, yet its owning object might be held on to longer than necessary. Simply because Dispose was called does not mean that its reference is being released. This could happen, for example, if its container (the object being disposed) is referred to from within a long-running scope (or stored in a static variable), and not explicitly nulled out. Doing this could help to reduce the lifetime of the object by making it eligible for garbage collection sooner. The definition of large and expensive is of course subjective and should be based on performance profiling and measurement. There were also a set of MSDN articles by Jeff Richter, but those appear to have been removed from the MSDN website...still looking around for other copies.
Also, take a look at this article, and specifically the comments from Wesner: http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx[^]
Or the second paragraph here[^]
Guffa wrote: AFAIK, it doesn't matter att all where the objects are allocated. The garbage collector only looks at the active references. If an inactive reference points to an object on the large objects heap, that doesn't turn it into an active reference.
It does matter where objects are allocated since objects in the LOB are still collected but the LOB itself is not compacted like the regular heap. I never said that "If an inactive reference points to an object on the large objects heap" it turns it into an active reference. What I did say was that you should set the large object to null, not necessarily anything that points to it.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Take a look at this article from Joe Duffy
He's talking about setting references to null if you are going to keep the object that is containing the references. Does not apply.
Scott Dorman wrote: Also, take a look at this article, and specifically the comments from Wesner
He's talking about replacing a reference with a reference to a newly created object. Does not apply.
Scott Dorman wrote: Or the second paragraph here
He's talking about when the large objects heap is collected. Setting a reference to null doesn't change when that happens.
Scott Dorman wrote: It does matter where objects are allocated since objects in the LOB are still collected but the LOB itself is not compacted like the regular heap.
There is of course differences depending on where the object is allocated, but nothing that affects how the garbage collector finds out if the object is collectable or not.
Scott Dorman wrote: I never said that "If an inactive reference points to an object on the large objects heap" it turns it into an active reference.
You said that setting the reference to null would help the garbage collector if the object is on the large objects heap. The only way that would be helpful would be if the garbage collector treats references to large objects differently, which is doesn't.
Scott Dorman wrote: What I did say was that you should set the large object to null, not necessarily anything that points to it.
The discussion was about a collection of objects, so that's what I assumed that you were also talking about. If you are talking about something completely different, you will only be causing confusion if you don't specify what it is that you are talking about.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: you will only be causing confusion
I'm confused - not by you Scott or Guffa - but by the conflicting info around.
Results of 'Googling' have basically said if using unmanaged memory then it should be used, if not then there's no need - but it won't hurt.
If I'm getting the last point correctly - it doesn't matter how large the Collection object is, it's the objects (items) it holds? If any of them are large then there may be a case for implementing?
If so, the point that if any of the items implement Idisposable then the collection should too means that I should implement it on any potentialy large objects and collections that may hold them?
Dave
|
|
|
|
|
DaveyM69 wrote: I'm confused - not by you Scott or Guffa - but by the conflicting info around.
Results of 'Googling' have basically said if using unmanaged memory then it should be used, if not then there's no need - but it won't hurt.
Sorry...trying to make sure I'm as clear as possible. (The conflicting information is actually what prompted my article.)
The primary purpose for the GC is to manage memory, which is actually different than managing resources. The Dispose pattern is for managing resources. That being said, the simplest rules are:
- If you are using/managing/maintaining any unmanaged memory it should be considered mandatory to use the Dispose pattern.
- If you are using/managing/maintining any objects that implement IDisposable, it should be considered mandatory to use the Dispose pattern.
- Anything else, it should be evaluated on an "as-needed" basis based on the semantics of the object and how it is intended to be used.
DaveyM69 wrote: If I'm getting the last point correctly - it doesn't matter how large the Collection object is, it's the objects (items) it holds? If any of them are large then there may be a case for implementing?
Yes, that's pretty much correct. Obviously, if the runtime allocates more than 85KB of memory to hold the actual collection object (the object itself, plus the pointers necessary for each of the "slots" in the collection) you should set it to null when you're done using the collection, but the collection itself isn't disposable per say. However, if any of the objects you maintain inside that collection implement IDisposable (or are larger than 85K themselves) you should implement IDisposable on the collection.
DaveyM69 wrote: If so, the point that if any of the items implement Idisposable then the collection should too means that I should implement it on any potentialy large objects and collections that may hold them?
Yes, that's also correct...for largely the same reasons I mentioned above.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
