Opacity property of WinForms is not working

The Opacity property of WinForm will not work for MDI Child forms due to some problems in form paintings. Infact, it is designed ONLY for top level windows.

Read @ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskCreatingMDIChildForms.asp

Integrate SQL Reporting Service 2005 with Sharepoint Portal 2003 with Web Part

Reporting Service rendering web part for share point is available at %\Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint when SQL Reporting Service 2005 is installed.

Install the above web part in share point with stsadm.exe. It consists of two web parts, Report Explorer and Report Viewer. Report Explorer is basically for listing the reports available in the reporting service in the specified folder (configuration of web part) and Report Viewer web part is for rendering report. Drag both web part in one of the sharepoint pages

Configuration
Enter the report manager url in the "Report Manager URL" property of Report Explorer web part.
Enter the folder name in the "Startpath" property of Report Explorer web part so that it will list only those reports in that folder. (It can remain empty)

In design mode of the page, go to properties of Report Viewer web part and select
Connections - > Get report from -> Report Explorer.

Now, click one of the reports in the Report Explorer web part listing and find the report rendered in the report viewer web part

Zm

SQL Reporting Service 2005 Express and Business Intelligence Development Studio - How to install and configure ?

SQL Reporting Service 2005 Express is available when you install the SQL Server 2005 Express Edition with Advanced Services SP1 edition. This is frely downloadable at http://msdn.microsoft.com/vstudio/express/sql/download/. Keep the servicing component selected while installing.

To install the Business Intelligence Development Studio, download Microsoft SQL Server 2005 Express Edition Toolkit SP1 from the same URL http://msdn.microsoft.com/vstudio/express/sql/download/

Display Mail Inbox, Tasks and Calendar from MS Outlook in Sharepoint Sites with web parts

You can do this in two better ways.

1. Drag "Content Editor Web Part" and paste the following script into the Source Editor

<object classid="clsid:0006F063-0000-0000-C000-000000000046" id="ViewCtlFolder" width="100%" height="400px" codetype= "application/x-oleobject"
codebase="http://activex.microsoft.com/
activex/controls/office/outlctlx.CAB#ver=9,0,0,3203">
<param name="Namespace" value="MAPI">
<param name="Folder" value="Inbox">
<param name="Restriction" value="">
<param name="DeferUpdate" value="0">
</object>



2. Create a generic web part using VS.Net and rewrite the function RenderWebPart like below

protected override void RenderWebPart(HtmlTextWriter output)
{
string str = "--above written script--";
output.Write(str);
}


Note that, to view Calender or Tasks instead of inbox, you can replace the term "Inbox" in the script with corresponding item.

Zm

How to install SQL Server Business Intelligence Development Studio along with SQL 2005 Express and SQL 2005 Reporting Service

SQL Server 2005 Reporting Service is version dependant on SQL Server. If you install SQL 2005 Express, you can only install express edition of SQL Server 2005 Reporting Service (RS).

Business Intelligence Development Studio is the default report designer of SQL Reporting Serivce. It is an addin for VS.Net 2005 with templates for "Report Projects"

How to install the express editions ?

• Downlaod SQL Server 2005 Express with Advanced Service (this includes the reporting services) and install. While installing keep the item "Reporting Service" checked
• Download SQL Server 2005 Express Toolkit ( http://www.microsoft.com/downloads/details.aspx?FamilyID=3c856b93-369f-4c6f-9357-c35384179543&DisplayLang=en). The kit includes the business intelligent development studio
• Now, go to Start - Settings - Control Panel and click Add remove programs
• Click the "Change" button of MS SQL Server 2005
• Click the link "To install a new component, click here"
• Locate the new .exe file of Express Toolkit by clicking the "Browse" button
• Proceed the installations with "Next" button clicks.

-Zm

Not able to connect Sql Server 2005 Express remotely

"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) "

By default, when you install Sql Server 2005 Express Edition, it will not allow the applications or clients to connect remotely as like OracleXE. This causes the sytem to throw the above error message.

To enable the remote connection,

• Go to Start - Programs - Microsoft SQL Server 2005 - Configuration Tools - SQL Server Surface Area Configuration
• Click the link "Surface Area Configuration for Services and Connections"
• Now expand the tree SQLEXPRESS - Database Engine - Remote Connections in the "View by Instance" tab
• Select "Local and remote connections" and "Using both TCP/IP and named pipes" and apply the changes

~Zm

Body onLoad() event in content pages - ASP.net 2.0

How we can use the onLoad() event in ASP.Net 2.0 content pages ?

Simple !.
A content page is basicall a page inherited from a MasterPage (.master) in .net framework 2.0. This can be adhieved by either two ways.

1. Javascript function override

Add body onLoad() event in the master page and override the function used in the event in the inherited content pages.

Say,

in master page
<html>
<head>
<script language=" javascript" type=" text/javascript">
function testonload(){ //an empty function
var x = 'empty';
}
</script>
</head>


.
..
...
....
.....



in content page

<asp:content id="Content1" runat="Server" contentplaceholderid="ContentPlaceHolder1">
<script language="javascript" type="text/javascript">
function testonload(prodid, div) {
//client script logic goes here..!!
}
</script>


2. Bind client script to body in code behind

Give an id to the body tag of the masgter page and add runat="server" sot that it is available in the code behind.

Now in content pages, add the following code in the page_load event


HtmlGenericControl body = (HtmlGenericControl)Page.Master.FindControl("bodyMaster");
body.Attributes.Add("onload", "toggle('parameters');");


Keep coding,

Service-oriented architecture (SOA)

A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services

The technology of Web Services is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection.

The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. A service provider can also be a service consumer.

Sharepoint - an application development platform!!!

Do you think Sharepoint an engine for just document sharing and versioning? Oooooops..!!
A big no……It is a lot more than that. Apart from using InfoPath to make feeder forms for sharepoint web services, you can make it use as a platform for systems applications development.

.net Web Parts

To customize the sharepoint sites with user-defined business process flows and workflows, user should develop custom web parts on .net technologies. It is basically similar to an application development on .net with more or less constraints and standards.
For example, if the user wants the SP to display the logged in user name, he needs to write a web part to display it in the pages. There web part templates comes into picture. It is freely downloadable from Microsoft web site and it is a plug-in to the VS.Net 2003.

Choosing between a User Control or Web Part for SharePoint

I generally recommend that users don't write Web Parts unless they have to. That confuses a lot of people since most people believe that you have to write Web Parts if you want to do work with SharePoint. This is only partially true.
SharePoint will only display Web Parts on a page. However, there are publicly available shims that allow you to write user controls and have them be displayed as a Web Part. From Share Point’s point of view, the shim is a Web Part. From the point of view of the user control, the shim is simply a control in .NET that is including the user control.
When faced with a decision on how to get content into a SharePoint Web Part on a portal, the question becomes when should you use a user control and when should you use a Web Part. In order to understand this decision, we must first understand the strengths and weaknesses of each approach.

The Power of User Controls

The ability to employ user controls as a part of a SharePoint deployment is very powerful. It takes a technology that developers are already familiar with (or should be familiar with) and is supported by tools and brings it to SharePoint.
AdvantagesThere are three primary advantages to user controls when dealing with SharePoint. They are: familiarity, reusability, and development speed.


· Familiarity
One of the keys to development is managing the degree of change that the team is put through as it transitions from technology to technology. Part of managing that change is minimizing it where possible. This is one of the reasons that user controls are such a good solution for many organizations. User controls are a core ASP.NET construct, they are something that developers are likely already familiar with — or at least aware of.
This familiarity increases the knowledge reuse coming into the project, which keeps morale high, improves productivity, and improves reuse of the experience after the SharePoint project.

· Reusability
Another way user controls are advantageous is that they can be used with other ASP.NET-based solutions. They aren't explicitly tied to SharePoint. If for some reason in the future you decide that SharePoint isn't the right platform for the solutions you're building — or you decide you need to reuse the technology in another non-SharePoint project — you have that capability.

· Development Speed
Direct support by Visual Studio for a visual interface for user controls — as opposed to manually adding in controls through code — is a great advantage in development speed. Having a visual look and feel instantly available makes the process go faster.

Debugging is faster too, as you can construct testing harnesses that fully exercise and instrument the user control. Web Parts are essentially only runable from within SharePoint. This means that you must deal with all of the SharePoint infrastructure while trying to debug.

ASP.NET 2.0 Web Parts and their ability to be used with SharePoint hold promise, but since right now the story of SharePoint and ASP.NET 2.0 is still not perfect, it's more of a future consideration than a potential solution for today.
Maintenance is also easier and faster with User Controls, primarily because they are easier to understand and debug. The net of this is that developing with user controls is substantially faster than developing a Web Part for everything but the most trivial implementations.



Disadvantages
The picture isn't completely rosy or there wouldn't be much discussion about whether to do a user control or a Web Part. There are some places where user controls may not be a great fit.

· Performance
While the overhead of shimming a user control into a SharePoint site may be trivial for most sites, an extremely large site may have to consider the performance impact of having multiple Web Parts actually coming from user controls.
As a practical matter, most people won't be in a situation where the performance difference between user controls and Web Parts will really matter. However, it is still one of the major objections raised by larger organizations to using user controls for their SharePoint development.

· Deployment
The story for deploying user controls is a bit messy. Single compiled DLLs for entire ASP.NET Web sites mean dumping a series of DLLs in to the bin directory or having all of your user controls in one massive project. Although this problem is substantially mitigated with ASP.NET 2.0, it's still an issue for deployments today.
Adding more difficulty is the deployment mechanism created for SharePoint, which doesn't work well with the structure created by the most popular shim — SmartPart. The net result is that deploying user controls can take a different procedure than even deploying your Web Parts. While this is a challenge, it is one that can be relatively easily overcome by some process and tools.


The Performance of Web Parts

For most people, the default answer is to build Web Parts for SharePoint — there are plenty of articles on how to do it, including a few of mine. They have the distinct advantage of being the "stock" answer to the problem. And in some cases they are the best answer for the job.

The primary advantage for creating a Web Part is that everything is available. You can manipulate the tool bar; you can change everything about the way the Web Part behaves. With a user control shim you have limited abilities to reach outside of the container that you're in.

Other than that, the user control's strengths are the Web Part's weaknesses. It's unfamiliar. It's not reusable. It is more difficult to develop and debug. Similarly, the user controls weaknesses are the Web Parts strengths. Web Parts are the best performers. Web Parts have a structured deployment mechanism supported by the core infrastructure.

In most organizations the core advantage for Web Parts turns out to be their performance over user controls. As mentioned above, this is rarely a real concern; rather it is a conditioned response to be concerned with the scalability of the platform. In terms of real performance the difference is fairly minor.

Making the Evaluation

Because the basic understanding of the differences isn't enough, this section dives into some of the other considerations, which emphasizes various strengths or weaknesses of various approaches.

Visual Construction
One of the most popular reasons why I move the bar from creating a user control to creating a Web Part is when the familiarity and development speed benefits of a user control are neutralized. This typically happens when the entire output of the Web Part (or area on the page) is built dynamically. The benefit of the user interface for a user control becomes useless. The familiarity with the concepts fades to the background as the output of the user control becomes more dynamic than normal.

For instance, if you're rendering a set of links or doing replacements on a string to be output, what advantages does a user control really have? The answer is not much, if any. In these cases, it may be better to build a Web Part, which has fewer "moving parts," rather than trying to shoehorn the content into a user control.

Coupling
One of the benefits of a user control is that it can be transported from SharePoint and used in other ASP.NET applications. However, what happens if the user control is tightly coupled to SharePoint. If it has a reference to the Microsoft.SharePoint.dll, then it's no longer reusable outside of SharePoint. So the reusability advantage disappears when you need to make direct use of SharePoint features. In these cases, if the user interface is simple, it may just make sense to be coded as a Web Part. Web Parts are necessarily coupled to SharePoint, therefore the additional coupling to SharePoint is immaterial. When building a replacement Web Part, which controls links on a list page, we made the decision to build a Web Part rather than a user control because the Web Part was deeply integrated into SharePoint. The Web Part applies additional criteria to the visibility of some of the related links — such as 'Alert Me.' Building a user control would not have helped reusability and would have been equally challenging to debug.

Performance
Although I generally believe that performance is too often on developers' minds there are times when performance is an issue to be considered. Generally speaking, the cost of a server and the associated software to run it is trivial in comparison to the cost of developing the solution. With a server being had for less than $5,000 and $5,000 not really even covering the full cost of a developer for a few weeks, it rarely makes sense to focus on performance.

There are, however, obvious places where it makes sense to care about performance. Items that are on every single page are good candidates to be Web Parts. Even with a low overall site volume, a Web Part that is on every page will generate a fair amount of volume, so performance is a valid concern.

For instance, we have a replacement for the Content Editor Web Part. The Web Part's primary function is to allow for relative paths and to enhance caching capabilities. It was done as a Web Part because it exists at least twice on every page — once for the header and again for the footer. This "core" component was pushed towards the side of performance even though it may have been just as easy or easier to develop as a user control.

A Better Mousetrap
The final consideration is that Web Parts lend themselves to a configuration-based design pattern. In other words, you create a generic component to fetch content from a URL rather than creating separate Web Parts for each URL to be fetched. This configuration-based approach is very helpful in reducing code duplication and improving the overall solution.

With SmartPart, there is still a problem with managing how information is pushed down to the user control. The solution is to create your own user control wrapper or to subclass SmartPart to add the ability to push in properties from SharePoint, the query string, and even a form post. This allows you to leverage SharePoint features without creating a coupling between the user controls and SharePoint.

For instance, a user control can expose a public property that accepts the identifier for the current record. The shim has the ID for the current record from the SharePoint properties for the site and notices it available as a public property on the user control. It can push the ID into the public property of the user control. This allows the user control to remain free of SharePoint coupling and still leverage a configuration based approach


Conclusion
Most of the time the assumption is that you have to write a SharePoint Web Part to get functionality in SharePoint is wrong. More frequently, it is appropriate to develop ASP.NET user controls and leverage them in SharePoint through shim technologies like SmartPart