Friday, May 20, 2011

FW: Twitter And Facebook Integration Articles

 
 
 
 
Twitter:
 
 
Facebook:
 
 

FW: Microsoft Useful Articles

 
Managed Extensibility Framework (MEF):
 
Threading :
 
AppDomain:
 
MSDN Magazine
 
 

Friday, February 18, 2011

Outlook Macro and Digital Signature

Digital Signature
 
Setting the security level to medium or low affects macros coming from all
sources (like virus-infected emails). After some more research, I've found a
way to do this without reducing the security level.

1. Create a digital certificate for yourself
Windows XP: Start, All Programs, Microsoft Office Tools, Digital Certificate
for VBA Projects.
Windows 2000: Start, Programs, Microsoft Office Tools, Digital Certificate
for VBA Projects.
(If the SelfCert.exe file is not on your computer, you might need to install
it.)
Follow the instructions to create a certificate.

2. Sign the Macro
In Outlook: Tools, Macro, Visual Basic Editor.
In the Project Explorer, select the project you want to sign.
Click Tools, Digital Signature. Click Choose, select the certificate, click
OK twice. Save.

3. When you open or run the macro, you’ll get a security warning. Check
“Always trust macros from this source”.

Your digital signature/certificate can be used for macros in all Office
applications.
 
 
Outlook Macro
 
Goto     Tools -> Macro -> Visual Basic Editor (Alt + F11)
Select   "Microsoft Office Outlook Objects" -> "ThisOutlookSession"
Type in below code :
 
Public WithEvents myOlItems As Outlook.Items
 
 
Public Sub Application_Startup()
 
   ' Reference the items in the Inbox. Because myOlItems is declared
   ' "WithEvents" the ItemAdd event will fire below.
   Set myOlItems = Outlook.Session.GetDefaultFolder(olFolderInbox).Items
 
End Sub
 
 
Private Sub myOlItems_ItemAdd(ByVal Item As Object)
 
   ' If it's currently not between 9:00 A.M. and 5:00 P.M.
   If Time() < #9:00:00 AM# Or Time() > #5:00:00 PM# Then
 
      ' Check to make sure it is an Outlook mail message, otherwise
      ' subsequent code will probably fail depending on what type
      ' of item it is.
      If TypeName(Item) = "MailItem" Then
 
         ' Forward the item just received
         Set myForward = Item.Forward
 
         ' Address the message
         myForward.Recipients.Add "kadian.vaibhav@aol.in"
 
         ' Send it
         myForward.Send
 
      End If
 
   End If
 
   ' If it's currently not between 9:00 A.M. and 5:00 P.M.
   If Time() >= #9:00:00 AM# Or Time() <= #5:00:00 PM# Then
 
      ' Check to make sure it is an Outlook mail message, otherwise
      ' subsequent code will probably fail depending on what type
      ' of item it is.
      If TypeName(Item) = "MailItem" Then
 
         ' Forward the item just received
         Set myForward = Item.Forward
 
         ' Address the message
         myForward.Recipients.Add "vaibhav.kadian@aol.in"
 
         ' Send it
         myForward.Send
 
      End If
 
   End If
 
End Sub
 
 

Wednesday, February 9, 2011

DDE - Dynamic Data Exchange

Dynamic Data Exchange (DDE) is a technology for communication between multiple applications under Microsoft Windows or OS/2.
 
A list of methods of passing data between programs and which operating systems support them is to be found in Knowledgebase article Q95900 Interprocess Communication Mechanisms.
In additional to COM and DDE they are NetBIOS, Pipes, Sockets, Mailslots, Memory Mapped Files and WM_COPYDATA. Memory Mapped Files and WM_COPYDATA do not operate over a network. Only DDE and COM are mechanisms of the type in which multiple clients can connect to a single server. Named pipes are reported to be amongst the fastest ways of sending data between different computers.
 
DDE mechanism overview
Making the connection between a DDE server and a DDE client
DDE uses a hierarchy of three names, the SERVICE, the TOPIC and the ITEM. A DDE CONVERSATION is established using the service and topic names as a pair. It is convenient to name the pair a CHANNEL. It is roughly the equivalent of a telephone number. The item part of the name is used to identify the particular data or command being requested by the client once a conversation is established.
To establish a conversation a DDE client specifies the service/topic name pair (channel) it wishes to connect to. Windows broadcasts the request to all top level windows. The first server to accept is connected to the client and so a conversation is established.
The client may leave either the topic or the service name unspecified, or both. This is known as a WILDCONNECT. For example, if the topic name is not specified conversations may be established on all the topics supported by a server. If both are unspecified conversations may be established on all topics with all servers. It is up to the server whether to accept such a connection, and if so on what topics.
Unlike a telephone connection, any number of quite separate conversations may be in progress on the same channel, even between the same two applications. This is often done so that only one item of information or one type of command is handled by each conversation. There is no interaction at all between different conversations using the same pair of service and topic names.
Transactions within a DDE conversation
Just as the client application initiates the establishment of a conversation, it also initiates all the transactions. It can request data from the server as a once off (a REQUEST transaction), request being kept up to date about an item of data (an ADVISE or NOTIFY transaction), give commands to the server (an EXECUTE transaction) and send unsolicited data to the server (a POKE transaction). The client associates with all these transactions the item part of the identification. It informs the server of the data required by the client in a request transaction, the action to be taken by the server in an execute transaction or the data being passed to the server in a poke transaction.
It is also possible to use the item part of the name as the data itself, with the topic name indicating the context in which the data is to be used.
Raw DDE has no timing constraints except the order in which messages are sent. At the Windows message level, there is no distinction between synchronous and asynchronous transactions. Synchronous and asynchronous operation is a feature of the DDE management library, or DDEML.
 
What is DDE and why is it totally different from COM?
DDE sends data between applications using Windows messages according to a documented protocol. Saying that DDE is old-fashioned and is being replaced by COM is something you see repeated parrot fashion over and over again. DDE and COM do not work in the same way and they solve different problems. Here are some points of difference:
  • COM is synchronous, one party makes subroutine calls into the other and must wait until the call returns. If the called component is busy the caller is blocked until it becomes free. DDE is asynchronous, a well-programmed client sends a Windows message to the server and carries on processing. Windows holds the message and sends it to the server when the server is ready to process it.
  • COM is complex to program but powerful. The client can manipulate objects within the server as if they belonged to the client. DDE is straightforward to implement but all it can do is transmit data. It can only control another application because the recipient can treat data as a command.
  • COM works well when the client creates an instance of a server object or application for its own use. Programming a continuously running server, to which clients can attach when they wish, is possible but tricky. DDE of itself is incapable of creating objects (although OLE1 used it as a transport mechanism). The essence of DDE is that clients attach to an already running server.
  • Applications using COM almost always need support DLLs such as the VB runtimes or MFC. Programs using DDE can be mean and lean and do not need extra support DLLs.
  • COM interfaces are tightly specified and contained within the software component. Some documentation is normally built into the interface. The user of a COM component knows exactly which methods are available and how to call them. DDE interfaces are specified only in external documentation.
  • Because of the tight interface specification, upgrading COM components can be a nightmare. With DDE the server or client can be changed independently.
  • COM is frequently used to communicate with a DLL in the same process space (called an in-process server). Such as server is often termed an ActiveX control and has the extension OCX. Our DDClient and DDServer Visual Basic components are in-process servers. Using DDE to communicate between components of the same application is possible but has no benefits.
  • COM communication with a remote machine is called DCOM (Distributed COM). If you make a DCOM call to a remote machine which does not respond, your program (or at least the thread making the call) is stuck. DCOM has a fixed built-in timeout which you cannot change. DDE with a remote machine is called NETDDE, it is used by the Hearts game and Chat which come with Windows. Timeout is controlled by the program.
  • Under Windows 3.1 and 9x it is possible to crash the system by badly programmed DDE, because the message queue can be filled. NT does not crash in this way, COM does not suffer from the problem at all.
  • DDE is totally "Bit blind", neither the client nor server can tell whether the other application is 16-bit or 32-bit. Indeed, the server cannot know whether the client is on the same computer or not. Connecting 16 to 32 bit COM components is not usually possible.
It is easy to see from the above points why a DDE server is the most widely used way of providing data obtained from any form of hardware interface. In particular:
  • The server can run continuously.
  • It will probably serve a wide range of clients but can be updated without requiring them all to be recompiled.
  • It is immune from the problems associated with different versions of the system DLLs on different machines.
  • It can be small and self-contained.
  • Clients cannot interfere with the running of the server by being slow or busy.
 
 
Source & Related Links :
 
 

Wednesday, December 15, 2010

SQL Object dependency identification

Problem:
Is there a way to identify which objects are dependent on other objects within a SQL Server database? I need to modify the table structure to add new columns. However, before making any changes I want to make sure that I understand all the object dependencies. Is there a way in SQL Server 2008 to quickly identify all the object dependencies?
Solution
In the earlier versions of SQL Server object dependencies were tracked using the ID of the object, as a result it was tough to keep track of Object Dependencies. However, in SQL Server 2008 Objects are tracked using the name of the object rather than object IDs. The biggest advantage of this approach is that you can track object dependency even after the object is removed from the database and you can also track even if an object is yet to be created in the database.
In SQL Server 2008 there are two new Dynamic Management Functions and a System View introduced to keep track of Object Dependencies. The newly introduced Dynamic Management Functions in SQL Server 2008 to keep track of object dependencies are sys.dm_sql_referenced_entities and sys.dm_sql_referencing_entities.  The newly introduced system view to keep track of object dependency is sys.sql_expression_dependencies.
The sys.sql_expression_dependencies system view holds one record each for a user defined object which has dependency on other object within the current database. A dependency between two objects is created when one object calling the referenced object appears by name in a SQL expression of another object. There are basically two types of dependencies tracked by the database engine in SQL Server 2008 namely Schema-bound Dependency and Non-schema-bound Dependency.
  • Schema-bound dependency: - A schema-bound dependency is a relationship that exists between two objects that prevents referenced objects from being dropped or modified as long as the referencing object exists. A quick example of schema-bound dependency will be a view or a user defined function which is created using WITH SCHEMABINDING clause.
  • Non-schema-bound dependency: - A non-schema-bound dependency is a relationship which exists between two objects which doesn’t prevent the referenced object from being dropped or modified.
The sys.dm_sql_referenced_entities Dynamic Management Function returns one row for each user defined object which is referenced by name within the definition of a specified referencing object. For example, if a user defined view is the specified referencing object, then by using sys.dm_sql_referenced_entities dynamic management function you can return all the user defined objects that are referred in the view definition such as tables, functions etc.
 
The sys.dm_sql_referencing_entities Dynamic Management Function returns one record for each user defined object within the current database which refers to another user defined object by name. For example, if there is a view which refers to three tables then this function will return three records one for each table reference. This function will also return dependency information for Schema-bound or Non-schema-bound entries, Database level and Server level DDL triggers.
 
 
 
Example:
 
/* Find all object which are referencing to <OBJECT_NAME> OBJECT */
SELECT
referencing_schema_name +'.'+ referencing_entity_name AS ReferencedEntityName,
referencing_class_desc AS ReferencingEntityDescription
FROM sys.dm_sql_referencing_entities (<OBJECT_NAME>, 'OBJECT');
GO
 
/* Find all object which are referenced by <OBJECT_NAME> OBJECT */
SELECT
referenced_schema_name +'.'+ referenced_entity_name AS ReferencedEntityName,
referenced_minor_name AS ReferencedMinorName
FROM sys.dm_sql_referenced_entities (<OBJECT_NAME>, 'OBJECT');
GO
 
/* Identifying Object Dependencies */
SELECT
SCHEMA_NAME(O.SCHEMA_ID) +'.'+ o.name AS ReferencingObject,
SED.referenced_schema_name +'.'+SED.referenced_entity_name AS ReferencedObject
FROM sys.all_objects O INNER JOIN sys.sql_expression_dependencies SED
ON O.OBJECT_ID=SED.REFERENCING_ID
WHERE O.name = <OBJECT_NAME>
GO
 

Tuesday, September 28, 2010

Profile Vs Session [ASP.NET]

Comparing Profile[HttpContext.Current.Profile] and Session[HttpContext.Current.Session]:
 
1) Both objects store separate data for each user of your web application without the developer having to
worry about coding for such.
2) Session often needs a small timeout value to protect the user enough, while Profile only ends at the
developer's discretion.
3) Profile allows control over clearing by inactive profiles versus active ones, time periods, etc., while
session is one or all.
4) Profile is strongly typed and Session is not.
5) At runtime, a key can be added to Session, a property for Profile must be designed in before runtime.
6) Session must load the entire dictionary to read only one value, while Profile can read just one property
efficiently (more scalable).
7) Both can store any kind of object.
 
 
use the Profile tab of the Web Site Administration Tool (WAT) to manage how your site collects personal
information about visitors. Profile properties represent data specific to a particular user. Using profile
properties enables you to personalize your Web site for individual users. The address for this web application
 

Monday, September 13, 2010

Abstract Factory Vs Builder

The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. The client does not know (or care) which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage.
An example of this would be an abstract factory class DocumentCreator that provides interfaces to create a number of products (e.g. createLetter() and createResume()). The system would have any number of derived concrete versions of the DocumentCreator class like FancyDocumentCreator or ModernDocumentCreator, each with a different implementation of createLetter() and createResume() that would create a corresponding object like FancyLetter or ModernResume. Each of these products is derived from a simple abstract class like Letter or Resume of which the client is aware. The client code would get an appropriate instance of the DocumentCreator and call its factory methods. Each of the resulting objects would be created from the same DocumentCreator implementation and would share a common theme (they would all be fancy or modern objects). The client would need to know how to handle only the abstract Letter or Resume class, not the specific version that it got from the concrete factory.
In software development, a Factory is the location in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage. This allows for new derived types to be introduced with no change to the code that uses the base class.
Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them, even at runtime. However, employment of this pattern, as with similar design patterns, may result in unnecessary complexity and extra work in the initial writing of code. Used correctly the "extra work" pays off in the second instance of using the Factory.
 
 
The builder pattern is a software design pattern. The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects. Often, the builder pattern is used to build products in accordance to the composite pattern, a structural pattern.
        Builder
Abstract interface for creating objects (product).
Concrete Builder
Provides implementation for Builder. It is an object able to construct other objects. Constructs and assembles parts to build the objects.
        Director
The Director class is responsible for managing the correct sequence of object creation. It receives a Concrete Builder as a parameter and executes the necessary operations on it.
        Product
The final object that will be created by the Director using Builder.
  • Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
  • Builder often builds a Composite.
  • Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
  • Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components are built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
 
 
 
 
Diff b/w Factory & Builder
 
The factor pattern defers the choice of what concrete type of object to 
make until run time. E.g. going to a restaurant to order the special of 
the day.  The waiter is the interface to the factory that takes the 
abstractor generic message "Get me the special of the day!" and returns 
the concrete product (i.e Liver souffle or Chicken caramel) 
The builder pattern encapsulates the logic of how to put together a 
complex object so that the client just requests a configuration and the 
builder directs the logic of building it.   E.g The main contractor 
(builder) in building a house knows, given a floor plan, knows how to 
execute the sequence of operations (i,e. by delegating to subcontractors) 
needed to build the complex object.  If that logic was not encapsulated in 
a builder, then the buyers would have to organize the subcontracting 
themselves ("Dear, shouldn't we have asked for the foundation to be laid 
before the roofers showed up?") 
The factory is concerned with what is made, the builder with how it is 
made.  Design patterns points out that (page 105) Abstract factory is 
similar to builder in that it too may construct complex objects.  The 
primary difference is that the Builder pattern focuses on constructing a 
complex object step by step.  Abstract factor's emphasis is on families of 
product objects(either simple or complex).  Builder returns the product as 
the final step, but as far as the Abstract Factory is concerned, the 
product gets returned immediately