|
Right. I'm definitely not using BindingFlags.DeclaredOnly. I know that inherited members aren't being returned because they're not being serialized (the output is XML), and I can even check by stepping through with a debugger.
I'm not at work right now, but the code is basically:
<br />
MemberInfo[] members = obj.GetType().GetMembers(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);<br />
<br />
foreach (Member member in members)<br />
{<br />
if (member is FieldInfo)<br />
{<br />
...<br />
}<br />
else if (member is PropertyInfo)<br />
{<br />
...<br />
}<br />
}<br />
Inside each block, I store the member if the conditions are proper. But even if I remove those conditions, I'm still only getting the non-inherited types.
I'm a little concerned that a previous version of my assembly is being used. I'll check for that on Monday, but again, I doubt that's the case since I was even stepping through with VS.
|
|
|
|
|
Well, it looks like I can't get access to private fields of inherited types through GetMembers(). I guess that makes sense. Using Reflector, I see that System.Runtime.Serialization also has to ascend the inheritance tree to get the list of serializable members, so I will, too.
Thanks,
Arun
|
|
|
|
|
hi,
where can i find all integer values of all WM_... messages?
for example:
int WM_CHAR = 0x0102;
|
|
|
|
|
|
|
jdunlap wrote:
Windows Message ID constants[^]
I just came across this one today, just thought I would point the user to the source.
-Nick Parker
DeveloperNotes.com
|
|
|
|
|
Hi,
I was trying to make a language selection of the Day-name. When I get the date with DateTime.Now.DayOfWeek, is there a posibility in System.Globalization to return the name of a day in another language then the Windows language?
Writing a switch case doesn't seems me to be the .NET way .
<br />
System.DateTime myDate = System.DateTime.Now;<br />
System.Globalization.CultureInfo ci = new CultureInfo("nl-BE");<br />
myDate.DayOfWeek.ToString(ci);<br />
above code still returns the English Name, not the Dutch name.
Thanks,
|
|
|
|
|
I found it by myself
It seems that .DayOfWeek only returns the english name.
When you use to formatted string DateTime.Now.ToString("dddd") it returns the day with the name in the language from the windows settings (not the windows language itsels).
To force it to another language you can use.
<br />
System.Globalization.CultureInfo ci = new CultureInfo("fr-BE");<br />
DateTime.Now.ToString("dddd", ci)<br />
And it will return the day of the week in the language specified in the CultureInfo.
So I was right to suppose a switch structure was not he .Net way.
|
|
|
|
|
This time they have rewritten the texteditor.
Lets see if they live up to the promise....
[edit]
Pros:
text editor looks tons better
bugs appeared to be fixed
Cons:
Hungry : 90mb RAM - one file opened
leppie::AllocCPArticle("Zee blog"); Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
|
|
About what product is this thread? Any link?
|
|
|
|
|
|
leppie wrote:
90mb RAM - one file opened
60 MB for me. The good thing is, each additional file doesn't take much more memory. I have a 48-file project (Fluid - whaddaya think? ), and can afford to have all the files open at once. (FYI, I have 256MB RAM, Win98, and 1GHZ CPU on my main machine, but it now works just fine on another PC w/ 128MB RAM, Win98, and a 500MHZ CPU - in pre-0.96 builds it did not.)
Anyhow, #D has greatly improved in the last 3 releases especially, and I hope to see it continue that way.
Someone asked "Have you worked in it? What's it like?". Well, I work in it every day, and here's what I have to say: 0.95 was a nightmare to work with, but 0.98 is so much better - all of the nightmare bugs are gone. I like it a whole lot.
It is definitely growing into a viable alternative to VS.NET, although it doesn't have the all the features yet. What I miss right now is:
* no built-in ASP.NET designer
* no deployment features
* no data access designer features
* poor ActiveX control support
When these are finished, I'll consider it a fully-viable alternative to VS.NET - i.e. good enough to say "Why spend your money on VS.NET?". Plus, we really need MC++ support and a VB.NET forms designer - both of which are underway.
#D has some features that aren't available in VS.NET - for example, compiling to a .netmodule. This is because anyone can volunteer to integrate their own special touches into it.
|
|
|
|
|
|
Hmm... haven't experienced any mousewheel bug - what is it?
|
|
|
|
|
My mousewheel live in an evil pararel reverse dimension. iow its scrolls the wrong way around
leppie::AllocCPArticle("Zee blog"); Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
Only with SharpDevelop, or w/everything? 'Cause I don't have this problem.
|
|
|
|
|
Heh, now there's one to add to the list of ways to punish annoying coworkers. I like it already.
-Blake
|
|
|
|
|
I want to transfer n number of binary files from a server to a client one by one.
I am using TcpListener and TcpClient.
Any suggestions?
mE
---------------------
A gasp of breath,
A sudden death:
The tale begun.
A rustled page
Passes an age:
The tale is done.
|
|
|
|
|
Didn't we already have this conversation, about not loading them into Bitmap's and such?
Which side decides which files are to be transfered, i.e. does the client pass a list of names to the server and it responds with the files, or does the server just send some set of files of its own chosing?
-Blake
|
|
|
|
|
Here is a naive implementation. A more robust solution needs to add exception handling, threading and checksums, but this should get you started.
Note: I wouldn't recommend using TcpListener and TcpClient at all, the async methods on Socket are the way to go, but you said that's what you said you were using, so that's what I used below.
Server.cs
using System;
using System.Net;
using System.Net.Sockets;
using System.IO;
class Server {
static int Main(string[] args)
{
TcpListener listener = new TcpListener(IPAddress.Any, 0xF00);
listener.Start();
using (TcpClient client = listener.AcceptTcpClient()) {
NetworkStream stream = client.GetStream();
StreamWriter writer = new StreamWriter(stream);
StreamReader reader = new StreamReader(stream);
string line;
writer.WriteLine("FileSender:1.0");
writer.Flush();
if ((line = reader.ReadLine()) != "FileReciever:1.0") {
Console.WriteLine("Unrecognized Client:{0}", line);
return 1;
}
foreach (string fileName in args) {
FileStream file = new FileStream(fileName, FileMode.Open);
byte[] buffer = new byte[file.Length];
string fileSize = file.Length.ToString();
file.Read(buffer, 0, (int)file.Length);
writer.WriteLine("FileName:{0}\r\nFileSize:{1}",
fileName, fileSize);
writer.Flush();
if ((line = reader.ReadLine()) != "Send:" + fileSize) {
Console.WriteLine("Protocol Error:{0}", line);
return 1;
}
stream.Write(buffer, 0, (int)file.Length);
if ((line = reader.ReadLine()) != "Recieved:" + fileSize) {
Console.WriteLine("Send {0} Failed:{1}", fileName, line);
return 1;
} else {
Console.WriteLine("Send {0} Complete", fileName);
}
}
}
return 0;
}
}
client.cs
using System;
using System.Net;
using System.Net.Sockets;
using System.IO;
class Client {
static int Main(string[] args)
{
using (TcpClient client = new TcpClient(args[0], 0xF00)) {
NetworkStream stream = client.GetStream();
StreamWriter writer = new StreamWriter(stream);
StreamReader reader = new StreamReader(stream);
string line;
if ((line = reader.ReadLine()) != "FileSender:1.0") {
Console.WriteLine("Unrecognized Server:{0}", line);
return 1;
}
writer.WriteLine("FileReciever:1.0");
writer.Flush();
while ((line = reader.ReadLine()) != null) {
if (!line.StartsWith("FileName:")) {
Console.WriteLine("Expected FileName:{0}", line);
return 1;
}
string fileName = line.Substring(9);
line = reader.ReadLine();
if (!line.StartsWith("FileSize:")) {
Console.WriteLine("Expected FileSize:{0}", line);
return 1;
}
int fileSize = int.Parse(line.Substring(9));
byte[] buffer = new byte[fileSize];
using (FileStream file =
new FileStream(fileName, FileMode.CreateNew)) {
writer.WriteLine("Send:{0}", fileSize);
writer.Flush();
stream.Read(buffer, 0, fileSize);
file.Write(buffer, 0, fileSize);
}
writer.WriteLine("Recieved:{0}", fileSize);
writer.Flush();
}
}
return 0;
}
}
Compile and then run 'server test1.dat test2.dat' in one window, and 'client localhost' in another.
-Blake
|
|
|
|
|
ha ha ha... yes I did and I remember you.... but you remembered me? So nice of you to help me out a lot. Actually its kind of a project where I have to send files from client to server... in a loop and those files are, fortunately or unfortunately image files . I mean its kind of streaming. I am not that much good in very low level programing... but thank you very much for your prompt reply and help.
I really appreciate this act of yours.
If, I mean just a request, tell me resource (are there any on CP? let me check out...) for low level performance oriented network programming in C# .NET.
May God Bless you with more;
mE
---------------------
A gasp of breath,
A sudden death:
The tale begun.
A rustled page
Passes an age:
The tale is done.
|
|
|
|
|
Glad I could help.
Performance is likely only important on the server. Given that, the best bet might actually be to change your approach a bit and let Microsoft do that work for you. Is there any reason you could not use a webpage hosted in IIS to recieve your files? (I do not mean a web form that the user would access via their browser, but rather an HttpHandler that would access uploads from your client application.)
-Blake
|
|
|
|
|
Since I'm in a sample writing mood, here's an example of what I'm describing in the post above.
Usage:
~ Edit upload.aspx and change the savePath to the location you want the files saved in. (Better yet, move the path to your web.config file.)
~ Check the ACLs on that path and make sure the ASPNET user (or whatever user you are running ASP.NET under) has permissions to write files there.
~ Save upload.aspx in your webroot somewhere.
~ Compile client.cs and test with "client http://yourserver/yourpath/upload.aspx testfile.dat"
Notes:
~ Since this uses standard HTTP file uploading, you can test it with a web page as well using an <input type='file'> tag in a form.
~ Also because this is standard HTTP you can easily add security as well, if this is an intranet application have a look at WebClient.Credentials and CredentialsCache.DefaultCredentials.
~ As is, the client is in control of the filename used to save the file. As this permits on client to overwrite files from another it is probably not good idea. Perhaps a folder per client, or generate unique names yourself.
~ If you want to save the files in a database instead of the filesystem, use HttpPostedFile.GetInputStream() instead of HttpPostedFile.SaveAs() and you won't need to write anything to a working directory at all.
~ By default ASP.NET will not let you upload more than 4MB per file, if your situation requires larger files you can change that default in your web.config under system.web/httpRuntime/maxRequestLength.
client.cs
using System;
using System.Net;
using System.Text;
class Upload {
static int Main(string[] args) {
try {
Console.WriteLine(Encoding.UTF8.GetString(
new WebClient().UploadFile(args[0], args[1])));
return 0;
} catch (Exception e) {
Console.WriteLine(e.Message);
return 1;
}
}
}
upload.ashx
<%@WebHandler class='Upload'%>
using System.IO;
using System.Web;
public class Upload : IHttpHandler {
const string savePath = @"D:\src\FileTransfer\output";
public void ProcessRequest(HttpContext context) {
HttpFileCollection files = context.Request.Files;
if (files.Count == 0) {
context.AddError(new HttpException(400, "not multipart/form-data"));
return;
}
for(int i = 0; i < files.Count; ++i) {
string fileName = Path.Combine(savePath,
Path.GetFileName(files[i].FileName));
files[i].SaveAs(fileName);
context.Response.Write(string.Format(
"File Saved As {0} ({1} bytes)",
fileName, files[i].ContentLength));
}
}
public bool IsReusable { get { return false; } }
}
-Blake
|
|
|
|