|
Hello All!!
I want to write the objects on file. I know how to do this in C++ but i m not geting the equvalent way in .net
e.g pseudocode is like
class MyClass{<br />
int a;<br />
int b;<br />
string c;<br />
}<br />
<br />
MyClass obj = new MyClass();<br />
obj.a=0;<br />
obj.b=1;<br />
obj.c = "can i do this";
In C++ I used to do it like
ofstream out(fileName,ios::binary | ios::trunc); <br />
out.write((char*)obj,sizeof(*obj));
But what is equivalent of ofstream in .net
Thanx in Advance.
sorry for my bad English.
|
|
|
|
|
Not gonna try like I am an expert by an means here but you should look at this article here on Codeproject http://www.codeproject.com/aspnet/fileupload.asp?target=Upload%7CFile[^] about uploading files with ASP.net/C#, I know it sounds off topic but it shows reading in and writing out a file using the FileStream class. Maybe it will help you on the right track?
|
|
|
|
|
Thanx Kluch!!
Well! I can find the overloaded methods to write bytes, strings, integers on files using different streams such as filestream, binarywriter etc but i want to write my custom class object on file, as mentioned in VC++ code in my question. It is quite easy in VC++ and there must be an equivalent function in C# as well. But I coudln't trace it out. 
Regards
Farrukh
sorry for my bad English.
|
|
|
|
|
Writing objects into a stream is called "Serialization", C# contains two different foramtters:
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter for binary formatting, and
System.Runtime.Serialization.Formatters.Soap.SoapFormatter for XML formatting.
The SerializableAttribute marks a class as serializable:
[Serializable()]
public class MyClass{
public int a;
public int b;
public string c;
}
To write an object of that class to a file stream, you can use the Serialize-method:
BinaryFormatter formatter = new BinaryFormatter();
FileStream stream = new FileStream(myFileName, FileMode.Create);
formatter.Serialize(stream, obj);
Later you can read teh object from the file with Deserialize():
MyClass obj = (MyClass)formatter.Deserialize(stream);
Itanium wrote:
sorry for my bad English.
Sorry for my even worse English. Have I understood the question, or is this an off-topic posting? 
|
|
|
|
|
Thanx John!
101% what i needed.
Reagards
Farrukh
sorry for my bad English.
|
|
|
|
|
Didn't really know what forum to post this in, but I thought this would be as good as any.
What exactly constitues a "command bar"? To me it seems that almost anything can be one; menus, toolbars, popup menus, tabbed interfaces, etc. So what makes something a command bar?
Thanks
- monrobot13
|
|
|
|
|
The term "command bar" typically refers to a component that can act as both a menu and a toolbar. A good example of this is the command bars in the Office suite. Using the Customize dialog, try dragging a built-in menu structure onto a commandbar toolbar. Notice that it becomes a dropdown button. Now drag a menu item onto the toolbar, or a toolbar item onto a menu - they're the same thing.
"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
|
|
|
|
|
Is there any chance of Microsoft fixing the problem with inconsistent casing in names of classes, namespaces, enums, what have you? Here's a sampling of things I've noticed lately:
System.Data.DbType
System.Data.DBConcurrencyException
System.Text.Encoding.UTF8
System.Web.Mail.MailMessage.Cc
System.Web.Mail.MailMessage.Bcc
Here's a good place to start reading about Microsoft's preferred casing styles:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconCapitalizationStyles.asp
The guidelines clearly state that two-letter names should be uppercased, but this is inherently flawed because it leads to impossible situations like in the MailMessage class: how to satisfy the naming 'guidelines' but still remain consistent within the class? This two-letter rule is nutso. (I think that the designers of the MailMessage class did a good thing by being consistent within the class, though.)
Does this bother anyone but me? I don't mind adapting to ANY convention, but it makes it a headache when there is no clear convention in actual practice, and you have to integrate with or extend an existing API.
Thank you.
Jeff Varszegi
|
|
|
|
|
Jeff Varszegi wrote:
System.Text.Encoding.UTF8
UTF8 is an RFC[^] so it wouldn't make much sense to change the case.
-Nick Parker
DeveloperNotes.com
|
|
|
|
|
AFAIK, whether something describes part of an RFC or not has nothing to do with the Microsoft casing guidelines. I'm not trying to be curt, I just don't think that your criterion applies. I could easily be wrong-- I'm not a walking encyclopedia of Microsoft documentation.
If it were me, I would never have cased XML as 'Xml' either, so I agree with your design ethic for sure! There are lots of other naming inconsistencies besides the ones I posted, too. I just picked a handful.
Thank you.
Jeff Varszegi
|
|
|
|
|
Jeff Varszegi wrote:
AFAIK, whether something describes part of an RFC or not has nothing to do with the Microsoft casing guidelines.
I agree, what I was suggesting was simply why change the name of something that is actually described as an acronym somewhere else, in this case it is an RFC. Who knows the exact reasoning behind some of this; maybe someone from Microsoft will read this thread and offer some insight?
-Nick Parker
DeveloperNotes.com
|
|
|
|
|
If they do, it'll break all code. So no, they won't (at least they better not, and they're smart enough not to).
BTW, Cc and Bcc do not conflict: in most cases in the .NET Framework BCL, they use camel case even when using acronyms. Bcc and Cc both start with upper-case characters and proceed to use lower case.
As someone that's followed the .NET Framework since early beta days, I can tell you the case changed a couple times. System.Xml used to be System.XML. Almost all acronyms were completely upper-case. Perhaps they felt that developers didn't want to hold down the shift key for so long. Why they didn't remain consistent on everything, I don't know.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I agree with you. What I'm really fumbling my way to saying, I guess, is that they should ditch this dumb two-letter-is-always-uppercase rule that they seem to have invented just to explain the name of the System.IO namespace. The standard should be heads-up camel, all the time. Of course, this would require them to admit that they made a few mistakes.
I also don't see Microsoft deprecating whole classes and namespaces in an effort to clean up the mess, and it's best that they don't!
Regards,
Jeff Varszegi
|
|
|
|
|
I am trying to take a byte array and cast it to a string.
The closest I have come is:
<br />
ASCIIEncoding.GetString Method (Byte[])<br />
However, there is a restriction:
"Any element of the bytes array that is greater than
hexadecimal 0x7F is translated to a Unicode question mark
('?')."
I need to keep that extra bit.
Tym!
|
|
|
|
|
Where are you getting the byte array from? If it involves multi-byte characters, shouldn't you be using a char[] array instead?
"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
|
|
|
|
|
I am creating the byte array from individual bytes that don't represent chars, simply 8-bit values. They are being put in a struct as a string and the struct is sent by reference to a win api function (interop).
|
|
|
|
|
Take a look at cultures and globalization. I assume you need an 8 bit encoder/decoder using some codepage.
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
I'm not too familiar with the encoders/decoders or how unicode particularly works, but my concern here is that if i have for example:
byte b1=0x85;
byte b2=0x7f;
the data i want to actually send should be:
0x857f
which I believe would be a valid unicode char.
first of all, i don't want and encoder to "pad" my bytes when building a string (0x0085007f), nor do I want a decoder interpretting the bytes and apparent chars... thereby messing up the raw bits.
I tried forgetting about building the array as a string and just defining it as a byte[] in the struct, but I couldn't get the marshalling right (unable to marshal struct as unmanaged type; cannot determine size...) When using a string, I am not getting a runtime error, I am just not building the string properly because I am getting incorrect results.
I am open for any and all suggestions!
Thanks
|
|
|
|
|
Well.. what is the byte array made of? Do you know what character set it is made of?
The ASCII character set is 7-bit only, therefore anything above 0x7f is "invalid" and not representable by using that character set.
Please see Encoding.GetEncoding() it should solve your problem.
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
The byte array is made of bytes. They do not represent characters.
|
|
|
|
|
Then... uhm. why, if I may ask, on earth are you trying to cast an array of bytes into a string? 
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
Well, that is not necessarily my ultimate solution, but I have gotten runtime errors when trying to pass the data as arrays. I may be able to, but I can't quite get everything right.
I chose a string at first because it is in a struct that mimics an unmanaged struct and the original, unmanaged struct defines it as a string. The whole struct is then passed by reference in an interop call to a windows API function. When I use a string, the code runs, but the data in the string is incorrect and I get incorrect results.
When I have used byte[] or char[] or even StringBuilder, I got runtime errors, saying the struct cannot converted to unmanaged.... the size cannot be determined.
I might be able to do it both ways, I just need to figure out what I'm missing...
|
|
|
|
|
Tym! wrote:
Well, that is not necessarily my ultimate solution, but I have gotten runtime errors when trying to pass the data as arrays. I may be able to, but I can't quite get everything right.
I'm still confident though that this is the right way to do it. God knows what the .NET runtime does to strings when you're not watching... 
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
While it is counter-intuitive, what you want in this case is UnicodeEncoding.GetString(byte[]). Because the data inside a string is natively stored using that UnicodeEncoding, it is a null transform, leaving your bytes alone.
(I suspect you'd better have an even number of bytes in your array if you want this to work. Herein lies a subtle inconsistency between BSTR's and System.Strings. BSTR's kind of admit to being used to pass random data around, and hence support odd numbers of bytes even though they are supposedly a strings of 16bit values. Your API hopefully won't care if you pad an extra null on the end if the length was odd.)
-Blake
|
|
|
|
|
yeah, it's always going to be a multiple of 4 bytes, so I don't need to worry about padding. I used the UnicodeEncoding and get a different, yet still incorrect, result.
I wonder if I am not declaring the struct correctly or I don't know, I feel that I am so close, but am just missing something...
Thanks for your help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
