Ink on the Web
来源:百度文库 编辑:神马文学网 时间:2024/04/29 06:32:07
The trick to bringing Ink to Web applications is embedding Windows controls. Although the Tablet PC SDK has a COM API and a managed API for .NET, it is only the .NET API that allows you to bring Ink to the Internet.
This article teaches you the basics that you need to Ink-enable your Web applications, including the important concepts about security that you need to understand to make it work. The article also walks you through deploying an Ink-enabled Web application and then dives into some of the more complicated problems of what to do with the Ink that you have collected in your Web application.
It’s Just a Windows Forms Control with One Big Caveat
If you have ever embedded a Windows Forms control onto a Web page, you are already nearly a pro at Ink-enabling your Web application. Let’s look at the basics.
Start by creating a new Windows Control Library project and add a reference to the Microsoft Tablet PC API. Then you will Ink-enable the entire surface of the new User Control just the way you would in a Windows Forms application, with just one twist.
When you instantiate the InkOverlay object, one of the overrides in the constructor is to hook it up with a control, rather than a Windows handle.
Public Sub InkOverlay(ByVal attachedControl As _
Control)
This is one of the most important things to remember for using this control in a Web application. You must attach the InkOverlay object to the control itself, not its handle.
The reason for this is related to the sometimes confusing topic of Code Access Security and what an object has permission to do on your computer. This is something that Microsoft overcame with version 1.7 of the Tablet PC SDK. .NET protects your computer from all of the terrible things that Web sites might want to do to you. It does that by giving Internet Explorer only Partial Trust on your computer.
Things with Partial Trust have restricted permissions on your computer. For example, they aren’t allowed to delete a file. As you will see a little further on, your Ink-enabled control is automatically downloaded to the client computer, where it is able to interact with the digitizer. However, nothing that is served from Internet Explorer will ever have a trust level higher than its host (Internet Explorer).
A Windows handle is part of the Win32 API, which is, of course, unmanaged code. Unmanaged code requires Full Trust. Because of Internet Explorer’s Partial Trust restriction, it is not allowed to serve up components requiring Full Trust and therefore, if your Windows Forms control contains something that requires Full Trust, its compiled assembly will also require Full Trust and Internet Explorer will be unable to serve the Ink enabled control to your computer. If the attached control’s window gets re-created, it can be automatically re-connected to the new Window. (.NET controls can re-create their windows unpredictably.)
By linking the InkOverlay to the control rather than its unmanaged Window handle, you are removing the requirement for Full Trust. As long as you don’t put anything else in your project that requires Full Trust, the compiled dll will run under Partial Trust and be deployed to the client computer. That is why it is so very important to remember to choose the overload of the control when you are constructing the InkOverlay object.
Remember: you created a simple control and have Ink-enabled its entire surface. The code for your Windows control, therefore, should look like this
Imports Microsoft.Ink
Namespace InkontheWeb
Public Class MyInkControl
Inherits System.Windows.Forms.UserControl
[Region: Windows Form Designer generated code]
Dim inko As InkOverlay
Private Sub InkControl_Load (ByVal sender As
Object, ByVal e As System.EventArgs) Handles _
MyBase.Load
inko = New InkOverlay(Me)
inko.Enabled = True
End Sub
End Class
End Namespace
There will be some default code for the control hidden inside of the Windows Form Designer generated code region. The most important code in there is the code that explicitly disposes the control. Be sure not to remove that code!
Protected Overloads Overrides Sub Dispose _
(ByVal disposing As Boolean)
If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
Why a Custom Control?
You may be wondering why you are building a custom control rather than using the InkEdit or InkPicture controls that are in the Tablet PC SDK. This is an issue related to embedding the Windows Forms control and not specific to the Ink. The control needs to be served up by the Web application, which means the server must have access to it. If you use the InkEdit or InkPicture controls, those are managed code and live on the client computer. Your Web application will not be able to find them. The Web application needs to have local access to the control on the server. By creating a custom control and deploying it along with the Web application, this is possible.
Once you have compiled this project, you can move over to ASP.NET for the Web site.
And it’s Just a Regular Web Site with a Twist
The next step is to create a simple page that contains the Ink-enabled control.
Add a new Web project to the solution. Once the project has been created, you need to add the dll that was created when you compiled the Windows Form control. Although you may be used to adding dlls to projects as a reference, this time, you add this dll as a file just the way you would do with an image, for example. This is an important concept to understand, because helps you to understand how all of the puzzle pieces work together. And as you know from your programming experience, this kind of knowledge is invaluable when you find yourself in a troubleshooting mode.
After adding the dll, which you should find in the bin directory of the control’s project folder, the control is embedded on the Web page with HTML tags. Remember that it is not a Web server control, but will be downloaded to the client’s computer. Your Web page merely needs to know how to find it, but the .NET Framework on the client’s computer does the actual interaction with it. The key to embedding a control on the page is to use the
This article teaches you the basics that you need to Ink-enable your Web applications, including the important concepts about security that you need to understand to make it work. The article also walks you through deploying an Ink-enabled Web application and then dives into some of the more complicated problems of what to do with the Ink that you have collected in your Web application.
It’s Just a Windows Forms Control with One Big Caveat
If you have ever embedded a Windows Forms control onto a Web page, you are already nearly a pro at Ink-enabling your Web application. Let’s look at the basics.
Start by creating a new Windows Control Library project and add a reference to the Microsoft Tablet PC API. Then you will Ink-enable the entire surface of the new User Control just the way you would in a Windows Forms application, with just one twist.
When you instantiate the InkOverlay object, one of the overrides in the constructor is to hook it up with a control, rather than a Windows handle.
Public Sub InkOverlay(ByVal attachedControl As _
Control)
This is one of the most important things to remember for using this control in a Web application. You must attach the InkOverlay object to the control itself, not its handle.
The reason for this is related to the sometimes confusing topic of Code Access Security and what an object has permission to do on your computer. This is something that Microsoft overcame with version 1.7 of the Tablet PC SDK. .NET protects your computer from all of the terrible things that Web sites might want to do to you. It does that by giving Internet Explorer only Partial Trust on your computer.
Things with Partial Trust have restricted permissions on your computer. For example, they aren’t allowed to delete a file. As you will see a little further on, your Ink-enabled control is automatically downloaded to the client computer, where it is able to interact with the digitizer. However, nothing that is served from Internet Explorer will ever have a trust level higher than its host (Internet Explorer).
A Windows handle is part of the Win32 API, which is, of course, unmanaged code. Unmanaged code requires Full Trust. Because of Internet Explorer’s Partial Trust restriction, it is not allowed to serve up components requiring Full Trust and therefore, if your Windows Forms control contains something that requires Full Trust, its compiled assembly will also require Full Trust and Internet Explorer will be unable to serve the Ink enabled control to your computer. If the attached control’s window gets re-created, it can be automatically re-connected to the new Window. (.NET controls can re-create their windows unpredictably.)
By linking the InkOverlay to the control rather than its unmanaged Window handle, you are removing the requirement for Full Trust. As long as you don’t put anything else in your project that requires Full Trust, the compiled dll will run under Partial Trust and be deployed to the client computer. That is why it is so very important to remember to choose the overload of the control when you are constructing the InkOverlay object.
Remember: you created a simple control and have Ink-enabled its entire surface. The code for your Windows control, therefore, should look like this
Imports Microsoft.Ink
Namespace InkontheWeb
Public Class MyInkControl
Inherits System.Windows.Forms.UserControl
[Region: Windows Form Designer generated code]
Dim inko As InkOverlay
Private Sub InkControl_Load (ByVal sender As
Object, ByVal e As System.EventArgs) Handles _
MyBase.Load
inko = New InkOverlay(Me)
inko.Enabled = True
End Sub
End Class
End Namespace
There will be some default code for the control hidden inside of the Windows Form Designer generated code region. The most important code in there is the code that explicitly disposes the control. Be sure not to remove that code!
Protected Overloads Overrides Sub Dispose _
(ByVal disposing As Boolean)
If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
Why a Custom Control?
You may be wondering why you are building a custom control rather than using the InkEdit or InkPicture controls that are in the Tablet PC SDK. This is an issue related to embedding the Windows Forms control and not specific to the Ink. The control needs to be served up by the Web application, which means the server must have access to it. If you use the InkEdit or InkPicture controls, those are managed code and live on the client computer. Your Web application will not be able to find them. The Web application needs to have local access to the control on the server. By creating a custom control and deploying it along with the Web application, this is possible.
Once you have compiled this project, you can move over to ASP.NET for the Web site.
And it’s Just a Regular Web Site with a Twist
The next step is to create a simple page that contains the Ink-enabled control.
Add a new Web project to the solution. Once the project has been created, you need to add the dll that was created when you compiled the Windows Form control. Although you may be used to adding dlls to projects as a reference, this time, you add this dll as a file just the way you would do with an image, for example. This is an important concept to understand, because helps you to understand how all of the puzzle pieces work together. And as you know from your programming experience, this kind of knowledge is invaluable when you find yourself in a troubleshooting mode.
After adding the dll, which you should find in the bin directory of the control’s project folder, the control is embedded on the Web page with HTML tags. Remember that it is not a Web server control, but will be downloaded to the client’s computer. Your Web page merely needs to know how to find it, but the .NET Framework on the client’s computer does the actual interaction with it. The key to embedding a control on the page is to use the