|
No its not the same thing..
"Delegate" is the baseclass that all delegates derive from.
(containing methods like DynamicInvoke etc)
The "delegate" keyword will tell the compiler that it should output a class deriving from Delegate.
(delegates are classes in IL)
So "Delegate" is more like object/Object.
While "delegate" is like the "class" keyword.
eg:
public class SomeClass : Object
public delegate void SomeDelegate () /* : Delegate */
|
|
|
|
|
Java's Properties class (http://java.sun.com/javase/6/docs/api/java/util/Properties.html[^]) is an easy way to serialize a bunch of properties to and from a file. I am trying to port a Java application that makes heavy use of this class, to C#. What is the easiest way to emulate this behavior?
I thought about XML serialization, but that doesn't work because all the field names have to be specified in advance. Any ideas?
|
|
|
|
|
How about a Hashtable. The Java properties class extends Java's implementation of a hashtable, so why not use a Hashtable in C# also?
|
|
|
|
|
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]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
