Create an override for a datagrid within a user control(WPF)

The XAML

<UserControl>
 <Grid>
        <toolkit:DataGrid  ItemsSource="{Binding Source={StaticResource DocumentsVS}}" AutoGenerateColumns="False" CanUserAddRows="False" CanUserDeleteRows="False"
                FontSize="16" Name="_dgDocuments" Style="{StaticResource EklektosDataGridStyle}" . . . >
</UserControl>

OR

<local:MyDataGrid x:Name="dataGrid"/>

In case you want to override the OnCreateAutomationPeer of your dataGrid, you have to subclass the dataGrid -

public class MyDataGrid : DataGrid

{

    protected override AutomationPeer OnCreateAutomationPeer()

    {

        return null;

    }

}

And in constructor of your UserControl -

public CDocumentChecklistView()

{

    InitializeComponent();

    AutomationPeer a = UIElementAutomationPeer.CreatePeerForElement(dataGrid);

}

Using Settings in C#

Introduction

The .NET Framework 2.0 allows you to create and access values that are persisted between application execution sessions. These values are called settings. Settings can represent user preferences, or valuable information the application needs to use. For example, you might create a series of settings that store user preferences for the color scheme of an application. Or you might store the connection string that specifies a database that your application uses. Settings allow you to both persist information that is critical to the application outside of the code, and to create profiles that store the preferences of individual users.

While Visual Basic 2005 has provided an easily discoverable mechanism for accessing settings using the My namespace, there is no analogous namespace in Visual C# 2005, and thus settings are somewhat more difficult to access. Nonetheless, C# users can still use settings by accessing the Properties namespace. In the course of this article, you will learn the difference between application and user settings, how to create new settings at design time, how to access settings at run time, and even how to incorporate multiple sets of settings into your application.

Asp.Net Tutorial (PART-11)

Memory Management and Garbage Collection

In any object-oriented programming environment, there arises the need to instantiate and destroy objects. Instantiated objects occupy memory. When objects are no longer in use, the memory they occupy should be reclaimed for use by other objects. Recognizing when objects are no longer being used is called lifetime management, which is not a trivial problem. The solution the CLR uses has implications for the design and use of the components you write, so it is worth understanding.

Asp.Net Tutorial (PART-10)

Common Language Specification (CLS)

The CLI defines a runtime that is capable of supporting most, if not all, of the features found in modern programming languages. It is not intended that all languages that target the CLR will support all CLR features. This could cause problems when components written in different languages attempt to interoperate. The CLI therefore defines a subset of features that are considered compatible across
language boundaries. This subset is called the Common Language Specification (CLS).

Asp.Net Tutorial (PART-9)

Modules and Assemblies

A module is an .exe or .dll file. An assembly is a set of one or more modules that together make up an application. If the application is fully contained in an .exe file, fine—that's a one-module assembly. If the .exe is always deployed with two .dll files and one thinks of all three files as comprising an inseparable unit, then the three modules together form an assembly, but none of them does so by itself. If the product is a class library that exists in a .dll file, then that single .dll file is an assembly. To put it in Microsoft's terms, the assembly is the unit of deployment in .NET.

Asp.Net Tutorial (PART-8)

Common Type System (CTS)

The CLI specification defines a rich type system that far surpasses COM's capabilities. It's called the Common Type System (CTS). The CTS defines at the runtime level how types are declared and used. Previously, language compilers controlled the creation and usage of types, including their layout in memory. This led to problems when a component written in one language tried to pass data to a
component written in a different language. Anyone who has written Visual Basic 6 code to call Windows API functions, for instance, or who has tried to pass a JavaScript array to a component written either in Visual Basic 6 or C++, is aware of this problem. It was up to the developer to translate the data to be understandable to the receiving component. The CTS obliterates this problem by providing the following features:

Asp.Net Tutorial (PART-7)

.NET Framework

In the ASP/VB6 model, Microsoft had developers building a component and then calling it via an ASP. Microsoft realized that it would be a good idea to make the component directly callable over HTTP, so that an application anywhere in the world could use that component. Microsoft threw their support behind SOAP, Simple Object Access Protocol, which allows developers to call a component over HTTP
using an XML string, with the data returning via HTTP in an XML string. Components sport URLs, making them as easy to access as any other Web item. SOAP has the advantage of having been a cross-industry standard, and not just a Microsoft creation.

Asp.Net Tutorial (PART-6)

The Need for a New ASP Model

It was evident that Microsoft would require a fundamental change to bring ASP up to the standard of industrial-strength programming. Active Server Pages was a technology based on the foundations of COM. ActiveX and COM technology provided much of its strength, but also many of its limitations. Microsoft would need to have a long hard look at COM to see how it could improve, and these changes would be bound to affect ASP. At the same time,Microsoft realized that the developers' playing field was changing, with new standards arriving all the time, particularly in information-sharing and distributed applications using XML, such as Simple Object Access Protocol (SOAP) and XML-RPC.

Asp.Net tutorial (PART-5)

Major Changes with ASP 2

Moving to Active Server Pages 2 brought the developer into a more stable and feature-rich environment. All aspects of the technology were tuned and tweaked,and programmers really felt that things had settled into a stable technology.This newfound confidence was in part due to the evidence of successful transactional sites actually showing that the platform could deliver, but also the fact that the technology had been boosted under the hood with tighter integration with Microsoft Transaction Server (MTS).

In fact, IIS 4 was rebuilt to be a MTS application, and so ASP and MTS components were actually running in the same processes. Another improvement was the work with Microsoft Message Queue.This
allowed ASP and components to communicate across networks, ideal for largescale applications with complex backend requirements, for example, e-commerce systems integrating with existing legacy enterprise resource planning (ERP) infrastructures.

Asp.Net Tutorial (PART-4)

Why ASP Was Not Originally Embraced

Active Server Pages was not an overnight success, though understandably it did capture the imagination of a large sector of the development community, particularly those already well versed in Visual Basic programming or Visual Basic for applications scripting.

Others who did not have an investment in Visual Basic knowledge found the limitations of Visual Basic, and by extension Visual Basic Scripting, reasons to avoid the technology. Faults included poor memory management, the lack of strong string management abilities, such as Regular Expressions, found in other established languages.When compared to CGI with Perl,ASP was found lacking.

At that time, Internet Information Server was in its infancy, and take-up was low, despite Microsoft's public relations juggernaut going into full flow after the company's much-reported dramatic turnaround. In comparison to current versions of the software it seems very poor, but it was still competitive on performance.

Asp.Net Tutorial (PART-3)

History of ASP

You can trace the history of ASP right back to 1995 and the momentous occasion when Microsoft realized they were falling behind in a fundamental shift in the industry by not embracing the Internet. Up until that point Microsoft had been developing their proprietary technologies, tools, and network protocols for the Microsoft Network; all of a sudden they needed an Internet strategy and fast.

Microsoft has gone from a position of playing catch-up to one close to dominance, with the Internet Explorer Web browser having a strangle-hold on the Web browsing market, and Internet Information Server (IIS) installed at the majority of Fortune 1000 companies.

Asp.Net Tutorial (PART-2)

Separation of Code from Content

As I mentioned previously, a major drawback of ASP in certain instances is that there is no way to separate code from page content. In ASP.NET, due to the introduction of server controls and the event-driven model, the trend leans toward placing all the code in event handlers in one place in the file (normally at the top). If this isn't sufficient, it's also possible to totally separate code from content by placing all the code in a separate file (VS .NET does this by default).

Session State Management

ASP provided a special collection object where the programmer could store variables pertaining to a particular visitor's session. This was a commonly used feature, but it had three major shortcomings. First, it wasn't Web farm-friendly. Session state variables were stored in the IIS process space, and as such, they were tied to a specific machine. Thus, if a visitor to a site had a particular piece of information stored in a session variable on a particular request, and he or she was then sent to another server on the next request, the ASP code would not be able to retrieve the previously stored
value. Second, a disadvantage of storing session state in the IIS process space is that should the IIS service have to be restarted, the session information is lost. The third problem was slightly more subtle, but important nonetheless: ASP kept track of visitor IDs by using cookies, which aren't supported by all browsers, or are not guaranteed to be enabled in all user browsers.

Differences Between ASP and ASP.NET

ASP.NET isn't simply the next version of ASP it's a completely redesigned technology that takes the best aspects of ASP and merges them with the power of pure object-oriented programming (OOP), a powerful development framework, to give it a vast range of functionality and the advantages of a fully compiled execution environment. Because the changes between ASP and ASP.NET are so drastic, current ASP developers must "unlearn" many concepts that they became accustomed to in ASP in order to truly get the most out of ASP.NET.

Compiled Environment

One of the most dramatic changes in ASP.NET is that it's now a fully compiled environment. Microsoft has implemented this very intelligently and it would be very easy to dismiss ASP.NET as interpreted because, to the programmer and the end user, it appears as if ASP.NET works in exactly the same way as ASP: You modify your ASP.NET page, you refresh the page in the browser, and the changes are reflected. Nowhere are you required to run a compiler. Compilation actually occurs the first time a page is requested after it has been modified. This compiled copy is then kept until the page is modified and requested again. As I've already mentioned, this process is totally transparent to the user.