|
yes, I can see it with code dates next week, how can I make the loop, but how,
DateTime dt = DateTime.Now;
int a = (int)dt.DayOfWeek;
if (a == 0) a = 14;
DateTime pazartesigun = dt.AddDays(8 - a);
DateTime saligun = dt.AddDays(9 - a);
DateTime carsambagun = dt.AddDays(10- a);
DateTime persembegun = dt.AddDays(11- a);
DateTime cumagun = dt.AddDays(12 - a);
DateTime cumartesigun = dt.AddDays(13 - a);
DateTime songun = dt.AddDays(14-a);
pazartesilbl.Text = pazartesigun.ToShortDateString();
salilbl.Text = saligun.ToShortDateString();
carsambalbl.Text = carsambagun.ToShortDateString();
persembelbl.Text = persembegun.ToShortDateString();
cumalbl.Text = cumagun.ToShortDateString();
cumartesilbl.Text = cumartesigun.ToShortDateString();
pazarlbl.Text = songun.ToShortDateString();
|
|
|
|
|
This may be a translation problem, but you can't make that code into a loop, unless you create an array of labels - containing pazartesilbl, salilbl ... in the order you want to display them.
Which I think you know...so what is it you are trying to get help with?
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 – ∞)
|
|
|
|
|
Can I send the program solves the problem?
|
|
|
|
|
No - but if it's solved, why would I need it anyway?
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'm not looking at that: I don't download and run EXE files from unknown websites! 
And particularly when they are "download managers"...
I'm not surprised it doesn't change any dates when you press a button - you are using DateTime.Now, so at best it will be a week before anything changes!
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 – ∞)
|
|
|
|
|
area code next week dates this. now you need the area code of the previous week dates
DateTime strtdt = DateTime.ParseExact(mondaylbl.Text, "dd/MM/yyyy", null);
GregorianCalendar cal = new GregorianCalendar(GregorianCalendarTypes.Localized);
int week = cal.GetWeekOfYear(strtdt, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday);
int year = strtdt.Year;
DayOfWeek day = DayOfWeek.Monday;
DateTime startOfYear = new DateTime(year, 1, 1);
int daysToFirstCorrectDay = (((int)day - (int)startOfYear.DayOfWeek) + 7) % 7;
DateTime FirstDay = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay);
DateTime sonrakiikincigun = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay).AddDays(1);
DateTime sonrakiucuncugun = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay).AddDays(2);
DateTime sonrakidorduncugun = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay).AddDays(3);
DateTime sonrakibesincigun = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay).AddDays(4);
DateTime sonrakialtincigun = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay).AddDays(5);
DateTime Endaday = startOfYear.AddDays(7 * (week - 1) + daysToFirstCorrectDay).AddDays(6);
mondaylbl.Text=FirstDay.ToString("dd/MM/yyyy");
tuesdaylbl.Text = sonrakiikincigun.ToString("dd/MM/yyyy");
wednesdaylbl.Text = sonrakiucuncugun.ToString("dd/MM/yyyy");
thursdaylbl.Text = sonrakidorduncugun.ToString("dd/MM/yyyy");
fridaylbl.Text = sonrakibesincigun.ToString("dd/MM/yyyy");
saturdaylbl.Text = sonrakialtincigun.ToString("dd/MM/yyyy");
sundaylbl.Text=Endaday.ToString("dd/MM/yyyy");
|
|
|
|
|
OK - a quick check says that works. I put a date in monday, press the button, I get a monday, and so forth.
What's the problem?
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 – ∞)
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
