C# Discussion Boards - CodeProject

Re: The dates of the next week and the previous week days

5-Apr-14 5:13

I'm not looking at that: I don't download and run EXE files from unknown websites! Laugh | :laugh:

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 – ∞)

ismail205-Apr-14 5:27

ismail20

5-Apr-14 5:27

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");

Re: The dates of the next week and the previous week days

OriginalGriff5-Apr-14 5:42

Re: The dates of the next week and the previous week days

5-Apr-14 5:42

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?

ismail205-Apr-14 5:47

ismail20

5-Apr-14 5:47

problem, can not list the previous week

Re: The dates of the next week and the previous week days

OriginalGriff5-Apr-14 6:12

Re: The dates of the next week and the previous week days

5-Apr-14 6:12

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");

ismail205-Apr-14 6:12

ismail20

5-Apr-14 6:12

I've solved the problem, thank u OriginalGriff

Anonymous or static or lambda methods??

Sea_Sharp4-Apr-14 8:56

Sea_Sharp

4-Apr-14 8:56

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) 
    {
        ///Anonymous 
        GimmeTwoInts addThemUp = delegate(int x, int y) 
{ return x + y; };
        Console.WriteLine(addThemUp(5, 5));
                  ///Output => 10

        ///Lambda
        GimmeTwoInts addAgain = (c, d) => { return c + d; };
        Console.WriteLine(addAgain(10, 10));
                  ///Output => 20

        ///Static
        Console.WriteLine(Program.AddingMachine(20, 20));
                  ///Output => 40

        Console.ReadLine();
    }

    public static int AddingMachine(int f, int g)
    {
         return f + g;
    }
}

Mycroft Holmes4-Apr-14 14:20

Mycroft Holmes

4-Apr-14 14:20

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

OriginalGriff4-Apr-14 20:55

4-Apr-14 20:55

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!

Richard Deeming7-Apr-14 1:57

Richard Deeming

7-Apr-14 1:57

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

Sea_Sharp7-Apr-14 2:57

Sea_Sharp

7-Apr-14 2:57

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.

OriginalGriff7-Apr-14 5:33

7-Apr-14 5:33

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! Laugh | :laugh:

Sea_Sharp7-Apr-14 8:34

Sea_Sharp

7-Apr-14 8:34

Wow thank you so very much! That was enlightening. Totally had that epiphany moment looking at your examples. K+

OriginalGriff7-Apr-14 8:52

Retrieving a List of Contacts from Exchange

7-Apr-14 8:52

You're welcome!

Member 103181264-Apr-14 1:05

Member 10318126

4-Apr-14 1:05

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?

Re: Retrieving a List of Contacts from Exchange

OriginalGriff4-Apr-14 2:34

Linkedin import to C# WPF desktop application?

4-Apr-14 2:34

Did you see this: http://stackoverflow.com/questions/2071668/how-to-get-contact-list-from-exchange-server[^] ?

Mandarinna3-Apr-14 23:42

Mandarinna

3-Apr-14 23:42

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.

Re: Linkedin import to C# WPF desktop application?

Richard MacCutchan3-Apr-14 23:58

Richard MacCutchan

3-Apr-14 23:58

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.

TCPClient across AppDomains

Carlos Sousa3-Apr-14 23:38

Carlos Sousa

3-Apr-14 23:38

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) {

    //Creating application instance
    Object applicationInstance = applicationType.InvokeMember(null, BindingFlags.Public | BindingFlags.Instance | BindingFlags.CreateInstance, null, null, null);

    //Invoke method
    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?

Rob Philpott4-Apr-14 4:27

Rob Philpott

4-Apr-14 4:27

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.

Carlos Sousa4-Apr-14 5:15

Carlos Sousa

4-Apr-14 5:15

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?

Rob Philpott4-Apr-14 6:03

Rob Philpott

4-Apr-14 6:03

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.

Carlos Sousa4-Apr-14 11:37

Carlos Sousa

4-Apr-14 11:37

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?