Friday, August 1, 2014

SQL SERVER CLR stored procedure

Short notes regarding how to begin with the CLR store procedure and help full reference links in the bottom.

View/Set the Database setting :

 select * from sys.dm_clr_properties  
 select * from sys.dm_clr_appdomains  
 select * from sys.dm_clr_loaded_assemblies  
 select * from sys.dm_clr_tasks  

Enabling the Clr in SQL Server.

 sp_configure 'show advanced options', 1;  
 GO  
 RECONFIGURE;  
 GO  
 sp_configure 'clr enabled', 1;  
 GO  
 RECONFIGURE;  
 GO

Creating StoreProcedure.

 USE database_name  
 GO  
 EXEC sp_changedbowner 'sa'  
 ALTER DATABASE database_name SET TRUSTWORTHY ON  
 CREATE ASSEMBLY Database2 FROM 'C:\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\Database2.dll';  
 create PROCEDURE SqlStoredProcedure11 AS EXTERNAL NAME Database2.StoredProcedures.SqlStoredProcedure1;  
 EXEC dbo.SqlStoredProcedure11  


Code Snippet:

using System;  
 using System.Data;  
 using System.Data.SqlClient;  
 using System.Data.SqlTypes;  
 using Microsoft.SqlServer.Server;  
 using DataTracker;  
 using System.Text;  
 public partial class StoredProcedures  
 {  
   [Microsoft.SqlServer.Server.SqlProcedure]  
   public static void SqlStoredProcedure1 ()  
   {  
     // Put your code here  
     SqlPipe sp;  
     sp = SqlContext.Pipe;  
     String strCurrentTime = "Current System DateTime is: "  
     + System.DateTime.Now.ToString();  
     sp.Send(strCurrentTime);  
   }  
 }  

Reference Link








Monday, July 21, 2014

REST vs SOAP

REST stands for REpresentational State Transfer (REST) which enforces a stateless client server design where web services are treated as resource and can be accessed and identified by there URL unlike SOAP web services which were defined by WSDL.
Web services written by applying REST Architectural concept are called RESTful web services which focus on System resources and how state of Resource should be transferred over http protocol.

SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in XML form.SOAP is protocol which relies on XML, that defines what is in the message and how to process it,set of encoding rules for data types, representation for procedure calls and responses.


REST vs SOAP

Before going for differences between two lets first see the differences in request header :

Sample SOAP & REST Request message for Weather Web Service :


 


SOAP vs REST Key Differences
Here are some of Key differences between SOAP and REST web Service :

  •  REST uses HTTP/HTTPS, SOAP can use almost any transport to send the request(for example we can have SOAP Messages over SMTP),  SOAP is a XML based messaging protocol.
  • REST is totally stateless operations where as SOAP supports statefull calls too. 
  • SOAP has more strict contract in the form of WSDL between applications, no such contract exists in case of REST.
  • AS REST APIs can be consumed using simple GET requests, RESTresponse can be cached, this is not possible with SOAP.
  • REST is Lighter, SOAP requires an XML wrapper around every request and response(SOAP Headers, XML tags etc). Thats why REST is preferred choice in mobile devices and PDA's
  •  SOAP message format is restricted to XML only where as REST supports other formats too for example JSON.  
  • REST is simpler in terms of development as compared to SOAP.
  • Browsers can handle REST easily as compared to SOAP as REST is based on HTTP where SOAP is another wrapper over HTTP.

Why to use SOAP ? 
SOAP provides some features like Security, Reliable Messaging, Atomic transaction which are not available in REST API.

  • WS-Security  & WS-SecureConversation  Provide support for using security tokens like Kerberos, and X.509.
  • WS-ReliableMessaging   Reliable messages delivery between distributed applications in case of failures.
  • WS-AtomicTransaction, two-phase commit across distributed transactional resources
  • In case where exact specification  of exchange format need to agreed between applications SOAP is better suitable.

Sunday, July 13, 2014

Maintaining Application State

We usually can create two types of cookies,
1. Session cookies.
2. Persistent cookies.

A session cookies exists only in memory. If a user closes the Web browser,  the session cookie disappears forever.

A persistent cookie, on the other hand, can last for months or even years. When you create a persistent cookie, the  cookie is stored permanently by the user's browers on the user's computer. Internet Explorer,  for example,  stores cookies in a set of text files contained in the following  folder:
\Documents and Settings\[user]\Cookies

Thursday, July 10, 2014

What is the difference between static class and singleton pattern?

In the first overview; we see both singleton class and static class are look similar. But there are many difference and here are the major points.

The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes, although that's less common IME), so you can pass around the singleton as if it were "just another" implementation.

A singleton allows access to a single created instance - that instance (or rather, a reference to that instance) can be passed as a parameter to other methods, and treated as a normal object.

A static class allows only static methods.

Singleton object stores in Heap but, static object stores in stack.

We can clone the object of Singleton but, we can not clone the static class object.

Singleton class follow the OOP(object oriented principles) but not static class
we can implement interface with Singleton class but not with Static class.

Friday, July 4, 2014

Command Design Pattern

 

Implementing the Command interface

First things first: all command objects implement the same interface, which consists of one method.

here's the Command interface:

 public interface Command{  
   public void execute();  
 }  

Implementing a Command to turn a light on

Now, let's say you want to implement a command for turning a light on.
Referring to our set of vendor classes, the Light class has two methods: on() and off(). Here's how you can implement this as a command:


public class LightOnCommand : Command{  
   Light light;  
   public LightOnCommand(Light light){  
     this.light=light;  
   }  
   public void execute(){  
     light.on();  
   }  
 }  

Using the command object

Okey, let's make things simple: say we've got a remote control with only one button and corresponding slot to hold a device to control:


public class SimpleRemoteControl{  
   //we have one slot to hold our command which will control one device.  
   Command slot;  
   public SimpleRemoteControl(){}  
   //we have a method for setting the command the slot is going to control.   
   //This could be called multiple times if the client of this code wanted   
   //to change the behavior of the remote button.  
   public void setCommand(Command command){  
     slot=command;  
   }  
   //This method is called when the button is pressed .   
   //All we do take the current command bound to the slot and  
   //call its execute() method.  
   public void buttonWasPressed(){  
     slot.execute();  
   }  
 }

Creating a simple test to use the Remote Control

Here's just a bit of code to test out the simple remote control. Let's take a look and we'll point out how the pieces match the Command Pattern diagram:


//This is our client in Command pattern-speak.  
 public class RemoteControlTest{  
   public static void main(String[] args){  
     //The remote is our invoker; it will be passed a command object that can be used to make  
     //requests.  
     SimpleRemoteControl remote = new SimpleRemoteControl();  
     //Now we create a Light object, this will be the Receiver of the request.  
     Light light= new Light();  
     //Here, creates a Command and pass it to the Receiver.  
     LightOnCommand lightOn=new LightOnCommand(light);  
     remote.setCommand(lightOn);//Here, pass the command to the invoker.  
     remote.buttonWasPressed();//And then we simulate the button being pressed.  
   }  
 }  

Thursday, June 19, 2014

Thread Pool - BackgroundWorker

BackgroundWorker is a helper class in theSystem.ComponentModel namespace for managing a worker thread. It can be considered a general-purpose implementation of the EAP, and provides the following features:
  • A cooperative cancellation model
  • The ability to safely update WPF or Windows Forms controlswhen the worker completes
  • Forwarding of exceptions to the completion event
  • A protocol for reporting progress
  • An implementation of IComponent allowing it to be sited in Visual Studio’s designer
BackgroundWorker uses the thread pool, which means you should never call Abort on a BackgroundWorker thread.

Using BackgroundWorker

Here are the minimum steps in using BackgroundWorker:
  1. Instantiate BackgroundWorker and handle the DoWork event.
  2. Call RunWorkerAsync, optionally with an object argument.
This then sets it in motion. Any argument passed toRunWorkerAsync will be forwarded to DoWork’s event handler, via the event argument’s Argument property. Here’s an example:
class Program  
 {  
  static BackgroundWorker _bw = new BackgroundWorker();  
  static void Main()  
  {  
   _bw.DoWork += bw_DoWork;  
   _bw.RunWorkerAsync ("Message to worker");  
   Console.ReadLine();  
  }  
  static void bw_DoWork (object sender, DoWorkEventArgs e)  
  {  
   // This is called on the worker thread  
   Console.WriteLine (e.Argument);    // writes "Message to worker"  
   // Perform time-consuming task...  
  }  
 }  
BackgroundWorker has a RunWorkerCompleted event that fires after the DoWork event handler has done its job. Handling RunWorkerCompleted is not mandatory, but you usually do so in order to query any exception that was thrown in DoWork. Further, code within a RunWorkerCompleted event handler is able to update user interface controls without explicit marshaling; code within the DoWork event handler cannot.
To add support for progress reporting:
  1. Set the WorkerReportsProgress property to true.
  2. Periodically call ReportProgress from within the DoWork event handler with a “percentage complete” value, and optionally, a user-state object.
  3. Handle the ProgressChanged event, querying its event argument’s ProgressPercentage property.
  4. Code in the ProgressChanged event handler is free to interact with UI controls just as withRunWorkerCompleted. This is typically where you will update a progress bar.
To add support for cancellation:
  1. Set the WorkerSupportsCancellation property to true.
  2. Periodically check the CancellationPending property from within the DoWork event handler. If it’s true, set the event argument’s Cancel property to true, and return. (The worker can also set Cancel and exit withoutCancellationPending being true if it decides that the job is too difficult and it can’t go on.)
  3. Call CancelAsync to request cancellation.
Here’s an example that implements all the preceding features:
   var bgWorker = new BackgroundWorker { WorkerReportsProgress = true };  
   bgWorker.DoWork += (o, e) =>  
   {  
     //Worker thread code. Gets called in a Non-UI thread.  
   };  
   bgWorker.ProgressChanged += (o, e) =>  
   {  
     //Progress change gets called on the UI thread. Controls can be accessed safely  
   };  
   bgWorker.RunWorkerCompleted += (o, e) =>  
   {  
     //gets called when worker thread finishes. UI thread. Controls can be accessed safely  
   };  
   bgWorker.RunWorkerAsync();  


 using System;  
 using System.Threading;  
 using System.ComponentModel;  
 class Program  
 {  
  static BackgroundWorker _bw;  
  static void Main()  
  {  
   _bw = new BackgroundWorker  
   {  
    WorkerReportsProgress = true,  
    WorkerSupportsCancellation = true  
   };  
   _bw.DoWork += bw_DoWork;  
   _bw.ProgressChanged += bw_ProgressChanged;  
   _bw.RunWorkerCompleted += bw_RunWorkerCompleted;  
   _bw.RunWorkerAsync ("Hello to worker");  
   Console.WriteLine ("Press Enter in the next 5 seconds to cancel");  
   Console.ReadLine();  
   if (_bw.IsBusy) _bw.CancelAsync();  
   Console.ReadLine();  
  }  
  static void bw_DoWork (object sender, DoWorkEventArgs e)  
  {  
   for (int i = 0; i <= 100; i += 20)  
   {  
    if (_bw.CancellationPending) { e.Cancel = true; return; }  
    _bw.ReportProgress (i);  
    Thread.Sleep (1000);   // Just for the demo... don't go sleeping  
   }              // for real in pooled threads!  
   e.Result = 123;  // This gets passed to RunWorkerCompleted  
  }  
  static void bw_RunWorkerCompleted (object sender,  
                    RunWorkerCompletedEventArgs e)  
  {  
   if (e.Cancelled)  
    Console.WriteLine ("You canceled!");  
   else if (e.Error != null)  
    Console.WriteLine ("Worker exception: " + e.Error.ToString());  
   else  
    Console.WriteLine ("Complete: " + e.Result);   // from DoWork  
  }  
  static void bw_ProgressChanged (object sender,  
                  ProgressChangedEventArgs e)  
  {  
   Console.WriteLine ("Reached " + e.ProgressPercentage + "%");  
  }  
 }  
Press Enter in the next 5 seconds to cancel
Reached 0%
Reached 20%
Reached 40%
Reached 60%
Reached 80%
Reached 100%
Complete: 123
 
Press Enter in the next 5 seconds to cancel
Reached 0%
Reached 20%
Reached 40%
 
You canceled!

Subclassing BackgroundWorker


BackgroundWorker is not sealed and provides a virtual OnDoWork method, suggesting another pattern for its use. In writing a potentially long-running method, you could write an additional version returning a subclassedBackgroundWorker, preconfigured to perform the job concurrently. The consumer then needs to handle only theRunWorkerCompleted and ProgressChanged events. For instance, suppose we wrote a time-consuming method called GetFinancialTotals:
 public class Client  
 {  
  Dictionary <string,int> GetFinancialTotals (int foo, int bar) { ... }  
  ...  
 }  
 We could refactor it as follows:  
 public class Client  
 {  
  public FinancialWorker GetFinancialTotalsBackground (int foo, int bar)  
  {  
   return new FinancialWorker (foo, bar);  
  }  
 }  
 public class FinancialWorker : BackgroundWorker  
 {  
  public Dictionary <string,int> Result;  // You can add typed fields.  
  public readonly int Foo, Bar;  
  public FinancialWorker()  
  {  
   WorkerReportsProgress = true;  
   WorkerSupportsCancellation = true;  
  }  
  public FinancialWorker (int foo, int bar) : this()  
  {  
   this.Foo = foo; this.Bar = bar;  
  }  
  protected override void OnDoWork (DoWorkEventArgs e)  
  {  
   ReportProgress (0, "Working hard on this report...");  
   // Initialize financial report data  
   // ...  
   while (!<finished report>)  
   {  
    if (CancellationPending) { e.Cancel = true; return; }  
    // Perform another calculation step ...  
    // ...  
    ReportProgress (percentCompleteCalc, "Getting there...");  
   }  
   ReportProgress (100, "Done!");  
   e.Result = Result = <completed report data>;  
  }  
 }  
Whoever calls GetFinancialTotalsBackground then gets a FinancialWorker: a wrapper to manage the background operation with real-world usability. It can report progress, can be canceled, is friendly with WPF and Windows Forms applications, and handles exceptions well.



BackgroundWorker and ProgressBar demo

public partial class Form1 : Form   
  {   
   public Form1()   
   {   
    InitializeComponent();   
    Shown += new EventHandler(Form1_Shown);   
    // To report progress from the background worker we need to set this property   
    backgroundWorker1.WorkerReportsProgress = true;   
    // This event will be raised on the worker thread when the worker starts   
    backgroundWorker1.DoWork += new DoWorkEventHandler(backgroundWorker1_DoWork);   
    // This event will be raised when we call ReportProgress   
    backgroundWorker1.ProgressChanged += new ProgressChangedEventHandler(backgroundWorker1_ProgressChanged);   
   }   
   void Form1_Shown(object sender, EventArgs e)   
   {   
    // Start the background worker   
    backgroundWorker1.RunWorkerAsync();   
   }   
   // On worker thread so do our thing!   
   void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)   
   {   
    // Your background task goes here   
    for (int i = 0; i <= 100; i++)   
    {   
     // Report progress to 'UI' thread   
     backgroundWorker1.ReportProgress(i);   
     // Simulate long task   
     System.Threading.Thread.Sleep(100);   
    }   
   }   
   // Back on the 'UI' thread so we can update the progress bar   
   void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)   
   {   
    // The progress percentage is a property of e   
    progressBar1.Value = e.ProgressPercentage;   
   }   
  }   

Events and Delegates

This is the best code snippet to make clean understanding about the usage of Events and Delegates.

class Program  
   {     
     static void Main(string[] args)  
     {  
       Ball ball = new Ball();  
       BallEventArgs balEvt = new BallEventArgs(10, 10);  
       Pitcher pi = new Pitcher(ball);  
       ball.OnBallInPlay(balEvt);  
     }       
   }  

 Delegate:

 public class Ball {  
     public delegate void eventDelegate(object o,EventArgs e);  
     public event eventDelegate BallInPlay;  
     public void OnBallInPlay(BallEventArgs e)  
     {  
       eventDelegate ballInPlay = BallInPlay;  
       if (ballInPlay != null)  
         ballInPlay(this, e);  
     }  
   }  
   public class BallEventArgs:EventArgs{  
     public int Distance { get; private set; }  
     public int Trajectory { get; private set; }  
     public BallEventArgs(int trajectory, int distance)  
     {  
       this.Trajectory = trajectory;  
       this.Distance = distance;  
     }  
   }  
   class Pitcher  
   {  
     public Pitcher(Ball ball)  
     {  
       ball.BallInPlay += new Ball.eventDelegate(ball_BallInPlay);  
     }  
     void ball_BallInPlay(object sender, EventArgs e)  
     {  
       if (e is BallEventArgs)  
       {  
         BallEventArgs ballEventArgs = e as BallEventArgs;  
         if ((ballEventArgs.Distance < 95) && (ballEventArgs.Trajectory < 60))  
           CatchBall();  
         else  
           CoverFirstBase();  
       }  
     }  
     private void CatchBall()  
     {  
       Console.WriteLine("Pitcher: I caught the ball");  
     }  
     private void CoverFirstBase()  
     {  
       Console.WriteLine("Pitcher: I covered first base");  
     }  
   }  

  EventHandler: 

public class Ball {  
     public event EventHandler BallInPlay;  
     public void OnBallInPlay(BallEventArgs e)  
     {  
       EventHandler ballInPlay = BallInPlay;  
       if (ballInPlay != null)  
         ballInPlay(this, e);  
     }  
   }  
   public class BallEventArgs:EventArgs{  
     public int Distance { get; private set; }  
     public int Trajectory { get; private set; }  
     public BallEventArgs(int trajectory, int distance)  
     {  
       this.Trajectory = trajectory;  
       this.Distance = distance;  
     }  
   }  
   class Pitcher  
   {  
     public Pitcher(Ball ball)  
     {  
       ball.BallInPlay += new EventHandler(ball_BallInPlay);  
     }  
     void ball_BallInPlay(object sender, EventArgs e)  
     {  
       if (e is BallEventArgs)  
       {  
         BallEventArgs ballEventArgs = e as BallEventArgs;  
         if ((ballEventArgs.Distance < 95) && (ballEventArgs.Trajectory < 60))  
           CatchBall();  
         else  
           CoverFirstBase();  
       }  
     }  
     private void CatchBall()  
     {  
       Console.WriteLine("Pitcher: I caught the ball");  
     }  
     private void CoverFirstBase()  
     {  
       Console.WriteLine("Pitcher: I covered first base");  
     }  
   }  

 

ThreadPool - Asynchronous delegates

ThreadPool - Asynchronous delegates

ThreadPool.QueueUserWorkItem doesn’t provide an easy mechanism for getting return values back from a thread after it has finished executing. Asynchronous delegate invocations (asynchronous delegates for short) solve this, allowing any number of typed arguments to be passed in both directions. Furthermore, unhandled exceptions on asynchronous delegates are conveniently rethrown on the original thread (or more accurately, the thread that callsEndInvoke), and so they don’t need explicit handling.

Here’s how you start a worker task via an asynchronous delegate:
  1. Instantiate a delegate targeting the method you want to run in parallel (typically one of the predefined Funcdelegates).
  2. Call BeginInvoke on the delegate, saving its IAsyncResult return value.

    BeginInvoke returns immediately to the caller. You can then perform other activities while the pooled thread is working.
  3. When you need the results, call EndInvoke on the delegate, passing in the saved IAsyncResult object.
In the following example, we use an asynchronous delegate invocation to execute concurrently with the main thread, a simple method that returns a string’s length:
static void Main()
{
  Func<string, int> method = Work;
  IAsyncResult cookie = method.BeginInvoke ("test", null, null);
  //
  // ... here's where we can do other work in parallel...
  //
  int result = method.EndInvoke (cookie);
  Console.WriteLine ("String length is: " + result);
}
 
static int Work (string s) { return s.Length; }
EndInvoke does three things. First, it waits for the asynchronous delegate to finish executing, if it hasn’t already. Second, it receives the return value (as well as any ref or out parameters). Third, it throws any unhandled worker exception back to the calling thread.

ThreadPool - QueueUserWorkItem

ThreadPool.QueueUserWorkItem

You can't use the Task Parallel Library if you're targeting an earlier version of the .NET Framework (prior to 4.0). Instead, you must use one of the older constructs for entering the thread pool: ThreadPool.QueueUserWorkItem and asynchronous delegates. The difference between the two is that asynchronous delegates let you return data from the thread. Asynchronous delegates also marshal any exception back to the caller.

QueueUserWorkItem

To use QueueUserWorkItem, simply call this method with a delegate that you want to run on a pooled thread:
static void Main()
{
  ThreadPool.QueueUserWorkItem (Go);
  ThreadPool.QueueUserWorkItem (Go, 123);
  Console.ReadLine();
}
 
static void Go (object data)   // data will be null with the first call.
{
  Console.WriteLine ("Hello from the thread pool! " + data);
}

Our target method, Go, must accept a single object argument (to satisfy the WaitCallback delegate). This provides a convenient way of passing data to the method, just like with ParameterizedThreadStart. Unlike with Task,QueueUserWorkItem doesn't return an object to help you subsequently manage execution. 

We must use WaitCallback. At MSDN, WaitCallback is described as a delegate callback method to be called when the ThreadPool executes. It is a delegate that "calls back" its argument.
WaitCallback
You can use WaitCallback by simply specifying the "new WaitCallback" syntax as the first argument to ThreadPool.QueueUserWorkItem. You don't need any other code to make this approach effective.


public partial class MainWindow : Form
{
    // This is the delegate that runs on the UI thread to update the bar.
    public delegate void BarDelegate();
 
    // The form's constructor (autogenerated by Visual Studio)
    public MainWindow()
    {
                InitializeComponent();
    }
 
    // When a buttom is pressed, launch a new thread
    private void button_Click(object sender, EventArgs e)
    {
                // Set progress bar length.
                progressBar1.Maximum = 6;
                progressBar1.Minimum = 0;
 
                // Pass these values to the thread.
                ThreadInfo threadInfo = new ThreadInfo();
                threadInfo.FileName = "file.txt";
                threadInfo.SelectedIndex = 3;
 
                ThreadPool.QueueUserWorkItem(new WaitCallback(ProcessFile), threadInfo);
    }
 
    // What runs on a background thread.
    private void ProcessFile(object a)
    {
                // (Omitted)
                // Do something important using 'a'.
 
                // Tell the UI we are done.
                try
                {
                    // Invoke the delegate on the form.
                    this.Invoke(new BarDelegate(UpdateBar));
                }
                catch
                {
                    // Some problem occurred but we can recover.
                }
    }
 
    // Update the graphical bar.
    private void UpdateBar()
    {
                progressBar1.Value++;
                if (progressBar1.Value == progressBar1.Maximum)
                {
                    // We are finished and the progress bar is full.
                }
    }
}







Wednesday, June 11, 2014

When & why to use delegates?

Say you want to write a procedure to integrate some real-valued function f (x) over some interval [a, b]. Say we want to use the 3-Point Gaussian method to do this (any will do, of course).

Ideally we want some function that looks like:


 // 'f' is the integrand we want to integrate over [a, b] with 'n' subintervals.  
 static double Gauss3(Integrand f, double a, double b, int n) {  
  double res = 0;  
  // compute result  
  // ...  
  return res;  
 } 

So we can pass in any Integrand, f, and get its definite integral over the closed interval.

Just what type should Integrand be?

Without Delegates
Well, without delegates, we'd need some sort of interface with a single method, say eval declared as follows:



// Interface describing real-valued functions of one variable.  
 interface Integrand {  
  double eval(double x);  
 }  

Then we'd need to create a whole bunch of classes implementing this interface, as follows:



// Some function  
 class MyFunc1 : Integrand {  
  public double eval(double x) {  
   return /* some_result */ ;  
  }  
 }  
 // Some other function  
 class MyFunc2 : Integrand {  
  public double eval(double x) {  
   return /* some_result */ ;  
  }  
 }  
 // etc 


Then to use them in our Gauss3 method, we need to invoke it as follows:

 double res1 = Gauss3(new MyFunc1(), -1, 1, 16);  
 double res2 = Gauss3(new MyFunc2(), 0, Math.PI, 16);  
 And Gauss3 needs to do the look like the following:  
 static double Gauss3(Integrand f, double a, double b, int n) {  
  // Use the integrand passed in:  
  f.eval(x);  
 }  

So we need to do all that just to use our arbitrary functions in Guass3.

With Delegates

 public delegate double Integrand(double x);  

Now we can define some static (or not) functions adhering to that prototype:

class Program {  
   static double MyFunc1(double x) { /* ... */ }  
   static double MyFunc2(double x) { /* ... */ }  
   // ... etc ...  
   public static double Gauss3(Integrand f, ...) {   
    // Now just call the function naturally, no f.eval() stuff.  
    double a = f(x);   
    // ...  
   }  
   // Let's use it  
   static void Main() {  
    // Just pass the function in naturally (well, its reference).  
    double res = Gauss3(MyFunc1, a, b, n);  
    double res = Gauss3(MyFunc2, a, b, n);    
   }  
 }  

No interfaces, no clunky .eval stuff, no object instantiate, just simple function-pointer like usage, for a simple task.

Of course, delegates are more than just function pointers under the hood, but that's a separate issue (function chaining and events).

source: 
http://stackoverflow.com/questions/2019402/when-why-to-use-delegates

Thursday, June 5, 2014

Differences between Abstract Factory Pattern and Factory Method


Factory Method is used to create one product only but Abstract Factory is about creating families of related or dependent products.

Factory Method pattern exposes a method to the client for creating the object whereas in case ofAbstract Factory they expose a family of related objects which may consist of these Factory methods.

Factory Method pattern hides the construction of single object where as Abstract factory method hides the construction of a family of related objects. Abstract factories are usually implemented using (a set of) factory methods.

AbstractFactory pattern uses composition to delegate responsibility of creating object to another class while Factory design pattern uses inheritance and relies on derived class or sub class to create object.

The idea behind the Factory Method pattern is that it allows for the case where a client doesn't know what concrete classes it will be required to create at runtime, but just wants to get a class that will do the job while AbstractFactory pattern is best utilised when your system has to create multiple families of products or you want to provide a library of products without exposing the implementation details.!
Factory Pattern Implementation: 




AbstractFactory Pattern Implementation:




Tuesday, April 29, 2014

To See the connection opened in Unix Terminal.

Use this command –

netstat -nputw

If you are looking for particular IP address or key then Grep it as

netstat -nputw|egrep "192.0.0.1"

I use for monitoring the Connection OPEN and CLOSE status.
In one of my project huge one, I got an exception “12 - too many connections “ .  I was sure about the connection Open() and Close()  and the calling place was right.

To test if there is anything missing from human eye. I had restarted the application and parallel to that  I was running netstat command to watch opened connection is closing or not. 

Wednesday, February 5, 2014

Load an icon file embedded in your executable

When you are developing a Windows Forms application in .NET, it’s not immediately obvious how to programatically load an icon file embedded in your executable.
This recipe shows you the 1 line solution.

Your icon file should be a regular windows icon file. Add it to your project, and in the properties for the icon make sure that it is set to Embedded Resource.
Now in your code, add the following line:


     public static NotifyIcon icon;  
     protected override void OnStartup(StartupEventArgs e)  
     {       
       App.icon = new NotifyIcon();  
       icon.Click += new EventHandler(icon_Click);       
       icon.Icon = new Icon(System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream("WorkingHours.time_n.ico"));          
       //icon.Icon = new System.Drawing.Icon(@"icon\time_n.ico");  
       icon.BalloonTipIcon = System.Windows.Forms.ToolTipIcon.Info;  
       icon.Visible = true;         
       base.OnStartup(e);  
     } 

You should now be able to use the icon directly in any windows control that uses icons, like the NotifyIcon control.


Monday, February 3, 2014

Allowing only one instance of a WPF application to execute

Sometimes, for any reason, you want to have only one instance per application.
Search on the internet and you will find many different ways of doing this. However, inside Jeffrey Ricther’s excellent book there is a way of allowing only one instance of an application (Console, WinForms, WPF) to execute at any given time using kernel-mode constructs.
Using what has been described in the book and searching at P/Invoke.net, I wrote some code that works with WPF applications. The code also attempts to set focus on the window and if it’s minimized it will attempt to restore it. 

 using System;  
 using System.Collections.Generic;  
 using System.Configuration;  
 using System.Data;  
 using System.Linq;  
 using System.Windows;  
 using System.Diagnostics;  
 using System.Runtime.InteropServices;  
 using System.Reflection;  
 using System.Threading;  
 using System.Windows;  
 namespace WorkingHours  
 {  
   /// <summary>  
   /// Interaction logic for App.xaml  
   /// </summary>  
   public partial class App : Application  
   {  
     private static readonly Semaphore singleInstanceWatcher;  
     private static readonly bool createdNew;  
     static App()  
     {  
       // Ensure other instances of this application are not running.  
       singleInstanceWatcher = new Semaphore(  
         0, // Initial count.  
         1, // Maximum count.  
         Assembly.GetExecutingAssembly().GetName().Name,  
         out createdNew);  
       if (createdNew)  
       {  
         // This thread created the kernel object so no other instance  
         // of this application must be running.  
       }  
       else  
       {  
         // This thread opened an existing kernel object with the same  
         // string name; another instance of this app must be running now.  
         // Gets a new System.Diagnostics.Process component and the  
         // associates it with currently active process.  
         Process current = Process.GetCurrentProcess();  
         // Enumerate through all the process resources on the share  
         // local computer that the specified process name.  
         foreach (Process process in  
            Process.GetProcessesByName(current.ProcessName))  
         {  
           if (process.Id != current.Id)  
           {  
             NativeMethods.SetForegroundWindow(  
               process.MainWindowHandle);  
             NativeMethods.ShowWindow(process.MainWindowHandle,  
               WindowShowStyle.Restore);  
             break;  
           }  
         }  
         // Terminate this process and gives the underlying operating   
         // system the specified exit code.  
         Environment.Exit(-2);  
       }  
     }  
     private static class NativeMethods  
     {  
       /// <summary>  
       /// Brings the thread that created the specified window into the  
       /// foreground and activates the window. Keyboard input is directed  
       /// to the window, and various visual cues are changed for the user.  
       /// The system assigns a slightly higher priority to the thread that  
       /// created the foreground window than it does to other threads.  
       /// </summary>  
       /// <param name="hWnd">A handle to the window that should be  
       /// activated and brought to the foreground.  
       /// </param>  
       /// <returns>If the window was brought to the foreground, the  
       /// return value is nonzero. </returns>  
       [DllImport("user32.dll")]  
       internal static extern bool SetForegroundWindow(IntPtr hWnd);  
       /// <summary>Shows a Window</summary>  
       /// <remarks>  
       /// <para>To perform certain special effects when showing or hiding a  
       /// window, use AnimateWindow.</para>  
       /// <para>The first time an application calls ShowWindow, it should use  
       /// the WinMain function's nCmdShow parameter as its nCmdShow ..  
       /// Subsequent calls to ShowWindow must use one of the values in the  
       /// given list, instead of the one specified by the WinMain function's  
       /// nCmdShow parameter.</para>  
       /// <para>As noted in the discussion of the nCmdShow parameter, the  
       /// nCmdShow value is ignored in the first call to ShowWindow if the  
       /// program that launched the application specifies startup information  
       /// in the structure. In this case, ShowWindow uses the information  
       /// specified in the STARTUPINFO structure to show the window. On  
       /// subsequent calls, the application must call ShowWindow with ..  
       /// set to SW_SHOWDEFAULT to use the startup information provided by ..  
       /// program that launched the application. This behavior is designed ..  
       /// the following situations: </para>  
       /// <list type="">  
       ///  <item>Applications create their main window by calling ..  
       ///  with the WS_VISIBLE flag set. </item>  
       ///  <item>Applications create their main window by calling ..  
       ///  with the WS_VISIBLE flag cleared, and later call ShowWindow ..  
       ///  SW_SHOW flag set to make it visible.</item>  
       /// </list></remarks>  
       /// <param name="hWnd">Handle to the window.</param>  
       /// <param name="nCmdShow">Specifies how the window is to be shown.  
       /// This parameter is ignored the first time an application calls  
       /// ShowWindow, if the program that launched the application provides a  
       /// STARTUPINFO structure. Otherwise, the first time ShowWindow .. ,  
       /// the value should be the value obtained by the WinMain function ..  
       /// nCmdShow parameter. In subsequent calls, this parameter ..  
       /// the WindowShowStyle members.</param>  
       /// <returns>  
       /// If the window was previously visible, the return value is nonzero.  
       /// If the window was previously hidden, the return value is zero.  
       /// </returns>  
       [DllImport("user32.dll")]  
       internal static extern bool ShowWindow(IntPtr hWnd,  
         WindowShowStyle nCmdShow);  
     }  
     /// <summary>  
     /// Enumeration of the different ways of showing a window.</summary>  
     internal enum WindowShowStyle : uint  
     {  
       /// <summary>Hides the window and activates another window.</summary>  
       /// <remarks>See SW_HIDE</remarks>  
       Hide = 0,  
       /// <summary>Activates and displays a window. If the window ..  
       /// or maximized, the system restores it to its original size and  
       /// position. An application should specify this flag when displaying  
       /// the window for the first time.</summary>  
       /// <remarks>See SW_SHOWNORMAL</remarks>  
       ShowNormal = 1,  
       /// <summary>Activates the window and displays it ..</summary>  
       /// <remarks>See SW_SHOWMINIMIZED</remarks>  
       ShowMinimized = 2,  
       /// <summary>Activates the window and displays it ..</summary>  
       /// <remarks>See SW_SHOWMAXIMIZED</remarks>  
       ShowMaximized = 3,  
       /// <summary>Maximizes the specified window.</summary>  
       /// <remarks>See SW_MAXIMIZE</remarks>  
       Maximize = 3,  
       /// <summary>Displays a window in its most recent size and position.  
       /// This value is similar to "ShowNormal", except the window is not  
       /// actived.</summary>  
       /// <remarks>See SW_SHOWNOACTIVATE</remarks>  
       ShowNormalNoActivate = 4,  
       /// <summary>Activates the window and displays it in its current size  
       /// and position.</summary>  
       /// <remarks>See SW_SHOW</remarks>  
       Show = 5,  
       /// <summary>Minimizes the specified window and activates the next  
       /// top-level window in the Z order.</summary>  
       /// <remarks>See SW_MINIMIZE</remarks>  
       Minimize = 6,  
       /// <summary>Displays the window as a minimized window. This value is  
       /// similar to "ShowMinimized", except the window ..</summary>  
       /// <remarks>See SW_SHOWMINNOACTIVE</remarks>  
       ShowMinNoActivate = 7,  
       /// <summary>Displays the window in its current size and position. This  
       /// value is similar to "Show", except the window ..</summary>  
       /// <remarks>See SW_SHOWNA</remarks>  
       ShowNoActivate = 8,  
       /// <summary>Activates and displays the window. If the window is  
       /// minimized or maximized, the system restores it to its original size  
       /// and position. An application should specify this flag ..  
       /// a minimized window.</summary>  
       /// <remarks>See SW_RESTORE</remarks>  
       Restore = 9,  
       /// <summary>Sets the show state based on the SW_ value specified ..  
       /// STARTUPINFO structure passed to the CreateProcess function by the  
       /// program that started the application.</summary>  
       /// <remarks>See SW_SHOWDEFAULT</remarks>  
       ShowDefault = 10,  
       /// <summary>Windows 2000/XP: Minimizes a window, even if the thread  
       /// that owns the window is hung. This flag should only be used when  
       /// minimizing windows from a different thread.</summary>  
       /// <remarks>See SW_FORCEMINIMIZE</remarks>  
       ForceMinimized = 11  
     }  
     //protected override void OnStartup(StartupEventArgs e)  
     //{  
     //  // Get Reference to the current Process  
     //  Process thisProc = Process.GetCurrentProcess();  
     //  // Check how many total processes have the same name as the current one  
     //  if (Process.GetProcessesByName(thisProc.ProcessName).Length > 1)  
     //  {  
     //    // If ther is more than one, than it is already running.  
     //    MessageBox.Show("Application is already running.");  
     //    Application.Current.Shutdown();    
     //    return;  
     //  }  
     //  base.OnStartup(e);  
     //}  
   }  
 }  

One improvement would be to restore the window only if it’s minimized by checking the return value of SetForegroundWindow method. I leave this to you, go on and adapt it to your own needs.



Code Formater

Paste Here Your Source Code
Source Code Formatting Options
1) Convert Tab into Space :
2) Need Line Code Numbering :
3) Remove blank lines :
4) Embeded styles / Stylesheet :
5) Code Block Width :
6) Code Block Height :
7) Alternative Background :
Copy Formatted Source Code
 
Preview Of Formatted Code