|
problem, can not list the previous week
|
|
|
|
|
I'd probably do it something like this:
DateTime strtdt = DateTime.ParseExact(mondaylbl.Text, "dd/MM/yyyy", null);
DateTime thisWeekMonday = strtdt.AddDays(1 - (int) strtdt.DayOfWeek );
DateTime nextWeekMonday = thisWeekMonday.AddDays(7);
DateTime lastWeekMonday = thisWeekMonday.AddDays(-7);
mondaylbl.Text = lastWeekMonday.ToString("dd/MM/yyyy");
tuesdaylbl.Text = lastWeekMonday.AddDays(1).ToString("dd/MM/yyyy");
wednesdaylbl.Text = lastWeekMonday.AddDays(2).ToString("dd/MM/yyyy");
thursdaylbl.Text = lastWeekMonday.AddDays(3).ToString("dd/MM/yyyy");
fridaylbl.Text = lastWeekMonday.AddDays(4).ToString("dd/MM/yyyy");
saturdaylbl.Text = lastWeekMonday.AddDays(5).ToString("dd/MM/yyyy");
sundaylbl.Text = lastWeekMonday.AddDays(6).ToString("dd/MM/yyyy");
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I've solved the problem, thank u OriginalGriff
|
|
|
|
|
It seems to me these three things are very quite similar. Can someone explain why you would use one over the others in given situations. Here I wrote a silly console app in which I was able to get all three types of methods to perform a simple math expression.
Are there advantages / disadvantages to using one over another?
class Program
{
delegate int GimmeTwoInts(int x, int y);
static void Main(string[] args)
{
GimmeTwoInts addThemUp = delegate(int x, int y)
{ return x + y; };
Console.WriteLine(addThemUp(5, 5));
GimmeTwoInts addAgain = (c, d) => { return c + d; };
Console.WriteLine(addAgain(10, 10));
Console.WriteLine(Program.AddingMachine(20, 20));
Console.ReadLine();
}
public static int AddingMachine(int f, int g)
{
return f + g;
}
}
|
|
|
|
|
Anonymous has it's own obvious advantages and would be used for a specific requirement but I don't see any benefit either way on the other 2. I would always use the "static" method but then I don't normally consider linq by default.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
The three aren't "very quite similar" - the static method is a different animal altogether from the other two. Anonymous and Lambda methods cannot be static: they are always instance related.
A static method is not instance related: you cannot use the this reference inside a static method explicitly or implicitly - which means you can't access non-static class properties, fields, or methods at all. So you can't do this:
private int myInt = 666;
public static void MyStaticMethod()
{
Console.WriteLine(myInt);
}Because the compiler will complain that "An object reference is required for the non-static field, method, or property '... .myInt'"
And there is no way to find the object reference because it is never, ever provided for a static method.
If you remove the keyword static from your example, then the three calls become equivalent.
But... you wouldn't normally do that!
The Lambda you use for a very simple method that you are going to do in one place only, and it is frequently used for Linq to process all the elements in a collection - outside that context it's a bit overkill (why not just do the code inline?)
Delegates are different: while you can use them the way you show, you would have to agree it's very "clumsy"! That's partly why Lambdas were introduced with Linq - to give a "cleaner" syntax to doing the same thing, and that's effectively what a Lambda is: an anonymous Delegate!
But Delegates are move powerful that that: you can use the delegate repeatedly, or pass it through to a method. This allows you to write code which calls the delegate to "do something" without knowing exactly what the delegate is going to do! For example, you could set up a method to list out a log from a DB, and give it a delegate which does the actual output - then call the same method to output to the console, a textbox, a file,... without changing the actual method in any way!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: Anonymous and Lambda methods cannot be static: they are always instance related.
Are you sure?
As I understand it, there are three possibilities:
- If the method captures local variables, it will be compiled as an instance method on a nested private class with fields to represent all of the captured variables;
- Otherwise, if the method references instance fields, properties or methods of the current instance, it will be created as a private instance method;
- Finally, if it only references static fields, properties or methods, or doesn't reference anything beyond its parameters, it will be created as a private static method;
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Very interesting.
Just to make sure I pull the nugget of info I was mining for. In regards to how anonymous/lambda compare to named functions in general is the following true?
It seems to me the delegate is really kind of like a contract in which you provide parameters types and a potential return type without any method body. Then you can subsequently use that delegate(contract) in combination with an anonymous/lambda expression to perform the given instructions.
If I understand this correctly then, I still fail to see the benefit of the delegates and the anonymous/lambda functions. Could you not just create named functions for all the processing you will complete? If you still have to provide instructions to every anonymous/lambda expression call, then how are they even advantageous?
I can't see how it would either reduce the amount of code, improve readability, or make it any easier to call particular functionality.
|
|
|
|
|
A delegate doesn't have to be a lambda or anonymous function - it can be a named function as well: in fact it can be a list of functions, provided the method signature matches the delegate template and all of them will be called.
Try it:
public delegate int MyDelegate(string x);
public MyDelegate theDelegate;
theDelegate += (x) => {Console.WriteLine("Lambda {0}", x); return x.Length; };
theDelegate += delegate(string x) { Console.WriteLine("Anonymous {0}", x); return x.Length; };
theDelegate += Named;
theDelegate("hello");
}
private int Named(string x)
{
Console.WriteLine("Named {0}", x);
return x.Length;
}And you will get:
Lambda hello
Anonymous hello
Named hello So you can use delegates to "chain" methods together - and in fact you use this all the time: delegates are what makes Events work!
So yes, in a way a delegate is a "contract" in that it specifies the method signature which it can accept - but don't really think of it like that, because it's main task is as a function pointer: it allows you to write code that doesn't need to know exactly what it is calling, just that "it takes these parameters and it returns such-and-such". So it would be (relatively) easy to write code which used delegates to work (seamlessly) with SQL Server, MySql and CSV files - without the code needing to know what kind of storage medium is behind it: it just calls the "write this to this table" and "get this from that table" delegates and the outside world sorts out the actual code to do that. Without delegates, you couldn't do that in C# - you have to write code which explicitly checked:
if (usingMSSQL) ReadFromMsSQL(table, columnlist);
else if (usingMySQL) ReadFromMySQL(table, columnlist);
else if (usingCSV) ReadFromCSV(table, columnlist);
else Throw new IDontKnowWhatToDoException("HELP!");ANd write similar code for every other method you need: INSERT, DELETE, UPDATE, and so forth. Then to add another (Excel perhaps) you have to change the code to support it - and risk missing one, or messing up, or otherwise getting it wrong.
OK, that's an advanced form, that you probably won't need to use for years, if ever - but Events are handled via exactly the same mechanism - and it just isn't possible to "add methods" to .NET code to include your event handler methods because (most of us) didn't even have access to the .NET source until fairly recently.
So accept delegates as needed, and we'll go from there.
So why use anonymous functions and lambdas at all? Well, if your code is tiny, you can improve the readability of your code by including it inline:
theDelegate += delegate(string x) { Console.WriteLine("Anonymous {0}", x); return x.Length + 1; };instead of:
theDelegate += delegate(string x) { PrintItAndGetLength(x); };when PrintItAndGetLength is miles away or in a different file completely - it breaks your concentration to go there, look ate the method, find it does two simple things, and then come back to continue reading. Since this code isn't going to be used anywhere else, it's simpler and easier just to use an anonymous method - especially as most of them are one line of code, is all. (Certainly in the real world I wouldn't use two lines of code or more in an anonymous method - I'd move it to a named method).
So why lambdas? Ah...well.
The delegate syntax is clumsy, and messy, and Microsoft wanted to introduce Linq - which really, really needs anonymous methods - because you can use anonymous classes within Linq, which means you can't write a named method to use them at all!
So they invented Lambdas to "clean up" the syntax: the lambda is a generic (but strongly typed) delegate that doesn't need an external delegate to define the method signature - it is inferred from usage (as is var, which was invented at the same time and for exactly the same reason).
And now you can use Linq in a clean, tidy way:
List<int> myList = new List<int>() { 1, 2, 4, 7, 2, 13, 16, 5 };
var output = myList.Where(x => x < 6).Distinct().OrderBy(x => x).Select(x => x.ToString());In that one line of code you have three delegates none of which require any external declarations, and you can see immediately what it all does: Selects only items less than 6, throws away duplicates, sorts by the value itself, and the converts each of them to a string, before returning a collection of the strings.
The equivalent "true delegate" code would be a lot longer, and a lot, lot harder to read. And as I mentioned - sometimes you can't even declare an instance of the class, because you can create anonymous classes in Linq! So you can't use named methods even if you wanted to!
I'm going to stop there, for the moment - that's way too long! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Wow thank you so very much! That was enlightening. Totally had that epiphany moment looking at your examples. K+
|
|
|
|
|
You're welcome!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Hi,
I want to retrieve a list of all public contacts (email addresses in particular), as listed in exchange server when you click the "To" button while composing an email. The reason I'm doing this is so I can have an auto-complete text field in my C#/wpf application.
Initially I thought this would be simple, but after trying, I'm still stumped.
The main thing I'm trying now is using EWS Managed api to connect to Exchange server, I can provide more details if needed, basically I'm not getting email adrresses.
So my question is: is there any simple, tried-and-true method of doing this? There are so many practical uses of having Exchange contacts in a .NET application -- so surely this has been done before and documented!
Any comments?
|
|
|
|
|
|
My team and I were assigned this year a project at our faculty in which we need to make desktop WPF application like some kind of CV generator with functionality to import information from a Linkedin profile.
So, if you have any knowldege about it, any good books, tutorials or whatever you can think of and that can help us, please share, it would be very appreciated.
|
|
|
|
|
If you want books or tutorials in general, then you (and your team) should learn how to make full use of Google, Bing etc, to search the internet. If you want articles on WPF then start at http://www.codeproject.com/KB/WPF/[^]. If you have specific technical questions then please use the appropriate forum for the subject in question; this forum is for C# questions.
|
|
|
|
|
I have an windows service where I load several assemblies through reflection.
I load the these assemblies into separate AppDomains so I can unload them in runtime and load a newer published version.
The the load/execute asssembly operations are done inside a MarshalByRefObject and everything works on.
The problem is that all the assemblies I'm loading have a Run Method that receives a class, which has a TcpClient object inside.
When I call the method I get a assembly.
System.Runtime.Serialization.SerializationException: Type 'System.Net.Sockets.TcpClient' in assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.
public class ApplicationConnection : MarshalByRefObject
{
public TcpClient Socket { get; set;};
}
public void Run(ApplicationConnection pInApplicationConnection) {
Object applicationInstance = applicationType.InvokeMember(null, BindingFlags.Public | BindingFlags.Instance | BindingFlags.CreateInstance, null, null, null);
applicationType.InvokeMember("Run", BindingFlags.InvokeMethod, null, applicationInstance, new object[] { pInApplicationConnection });
}
Inside the Run method, when I try to use the TCP client I get the serialization error.
How can I pass the TCP client object across AppDomains?
|
|
|
|
|
Good question, but I fear the answer is you can't.
AppDomains are there to isolate things from each other in the scope of a process. MarshalByRefObject is a thing for exchanging messages between domains which is why its trying to serialise the TcpClient. You don't talk to it, you talk to a proxy which looks like it that serializes the data back and forth.
Something like TcpClient, which is just a wrapper around some OS resources can't really be serialized. It's not a piece of data.
I've done quite a bit of this stuff before but not for years and years so I'm trying to think back how I did it. I think life is quite a bit simpler if you only try to pass primitive types between boundaries, and as the error suggests if you can't serialise it then you just can't.
So, what to do? Can you change the code so that it accepts and IpEndpoint rather than a TcpClient? Perhaps you could create some sort of decorator class wrapping up the TcpClient which inherits from MarshalByRefObject, but I have to say that idea makes me feel a little ill.
Tricky, and it'd be good to get some input from others.
Regards,
Rob Philpott.
|
|
|
|
|
Firs of al thanks.
The thing is I have a thread where the tcpListener is working, whenever a new connection is accepted I take the tcpClient object and I pass it to the loaded assembly which is in onother appdomain.
So, I believe that sending the IpEndPoint wouldn't do. Am I not right?
What if.... and stop when I start saying some idiot thing...
Could I let the tcpClient on the appdomain who created it and expose some static methods that would implement the functions I need. Just some basic send/receive wrappers.
Could the assemblies loaded in separate appdomains access the static methods I have on the primary appdomain? And if so, wouldn't I have some problems with the static class being instantiated multiples times?
|
|
|
|
|
OK, so the listener gets given a TcpClient on an incoming connection and you want to pass that to the AppDomain. Yes, you have a connected socket at that point so an end point would be no use. Is it possible to move the listener into the app domain at all?
Static methods AFAIK are global within the AppDomain, and cannot cross boundaries. So if you have a static class, each domain would get its own copy.
The only other approach I can think of is something like WCF port sharing. It is a separate process that listens on one port and then can route messages to different processes.
Or, rather than try to pass the TcpClient over boundaries, can't you keep it in the host domain, and just send packets of data to the AppDomain instead? Are you using the network stream on it? What sort of stream operations are you using?
Regards,
Rob Philpott.
|
|
|
|
|
On a design point of view doesn't make much sense to move the endpoint to the thread. Basically the app starts the listener and depending on the data it receives it executes the correct assembly.
At this point I'm just using the TcpClient.Socket.Send and the TcpClient.Socket.Receive methods.
After all this discussion I was thinking in the main thread (the one with the listener) to implement some communication mechanism that allows the tcp client to live in the main appdomain and just send/receive data to the assemblies appdomains.
What can I use?? NamedPipes or something like that?
|
|
|
|
|
Carlos Sousa wrote: How can I pass the TCP client object across AppDomains?
You can't. The reason is that the app domain barrier despite looking magical ONLY works via serialization. And noted by the other response a TCPClient represents resources (not data) which cannot be serialized.
You can however proxy the TCPClient. You create a proxy and it passes data across the barrier and gets data back. That data of course used by the real TCPClient to send receive messages. Note of course that given that all of the normal restrictions with threads applies it might be easier to create the TCPClient in the AppDomain though.
|
|
|
|
|
I can't create the TcpClient in the final appdomain
the main appdomain as a listener that when accepts a connection and based on the data it receives chooses on of the multiple assemblies loaded.
I then run the correct assembly in a separate appdomain and passing the tcpclient that the assembly should use to comunicate.
Since I can't pass the tcpclient I was planning to keep the tcpclients in the main thread and then implement somekind of mechanism that allows the assembly to send and receive data using a proxy implementation in the main thread.
what do you suggest me using for the implementation? Pipes for example?
|
|
|
|
|
Carlos Sousa wrote: implement somekind of mechanism that allows the assembly to send and receive data using a proxy implementation in the main thread.
A proxy.
Carlos Sousa wrote: what do you suggest me using for the implementation?
It just isn't that complicated if you are already familiar with app domains. You proxy a method call to 'send' data and another to 'get' data. That is what it does in the app domain. Outside the app domain those methods are implemented to send/get using the TCP client.
|
|
|
|
|
When you say "proxy" are talking about using the same "CreateInstanceAndUnwrap" method?
So in the new appdomains I would create a proxy to a class in the default appdomain, is that what you're talking about?
Thanks in advance.
|
|
|
|
|
Ok. It works.
In the secondary appDomain I created a proxy (through AppDomain.CreateInstanceAndUnwrap) to a class with static properties in the process default appdomain.
This class performs all the communication through the socket and just return the messages data.
Thanks for all the help.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
