Freelance projects
Friday, November 10, 2006
Validation in Windows Presentation Foundation - The Code Project - Vista / WinFX
Validation in Windows Presentation Foundation - The Code Project - Vista / WinFX: "if your applications have a very rich domain model, you may find the ErrorProvider approach helpful. If your application is very service oriented, or very UI centric, ValidationRules might be all you need."
Guidelines for Designing Stylable Controls
Guidelines for Designing Stylable Controls: "Guidelines for Designing Stylable Controls
This document summarizes a set of best practices to consider when designing a control which you intend to be easily stylable and templatable. We came to this set of best practices through a lot of trial and error while working on the theme control styles for the built-in WPF control set. We learned that successful styling is as much a function of a well-designed object model as it is of the style itself. The intended audience for this document is the control author, not the style author.
This topic contains the following sections.
* Terminology
* Before You Start: Understanding Your Control
* General Guidelines
* Theme Considerations
* Related Topics
Terminology
'Styling and templating' refer to the suite of technologies that enable a control author to defer the visual aspects of the control to the style and template of the control. This suite of technologies includes:
*
Styles (including property setters, triggers, and storyboards)
*
Resources
*
Control Templates
*
Data Templates
For an introduction of styling and templating, see the Styling and Templating topic.
Before You Start: U"
This document summarizes a set of best practices to consider when designing a control which you intend to be easily stylable and templatable. We came to this set of best practices through a lot of trial and error while working on the theme control styles for the built-in WPF control set. We learned that successful styling is as much a function of a well-designed object model as it is of the style itself. The intended audience for this document is the control author, not the style author.
This topic contains the following sections.
* Terminology
* Before You Start: Understanding Your Control
* General Guidelines
* Theme Considerations
* Related Topics
Terminology
'Styling and templating' refer to the suite of technologies that enable a control author to defer the visual aspects of the control to the style and template of the control. This suite of technologies includes:
*
Styles (including property setters, triggers, and storyboards)
*
Resources
*
Control Templates
*
Data Templates
For an introduction of styling and templating, see the Styling and Templating topic.
Before You Start: U"
XamlXaml: Exploring XAML, WPF, XBAP & .NET 3.0 » Blog Archive » Control Templating: One of the Most Powerful WPF Features! (KevinButton example)
Sunday, October 15, 2006
DevHood
I was just searching for something and accidentlly got into this site which gives presentations, articles, explanations..blah blah blah abt .Net
Here is something ABOUT the site
DEVHOOD: "DevHood was created by six students at MIT who had nothing better to do than to create a developer's community using .NET. Actually it was really more of a proof of concept for the 2001 MIT $50K Entrepreneurial Competition. They actually got into the semifinals with their alpha version of the site which was pretty exciting.
Here is something ABOUT the site
DEVHOOD: "DevHood was created by six students at MIT who had nothing better to do than to create a developer's community using .NET. Actually it was really more of a proof of concept for the 2001 MIT $50K Entrepreneurial Competition. They actually got into the semifinals with their alpha version of the site which was pretty exciting.
Wednesday, October 11, 2006
Annotations in WPF, Post-it notes using WPF, and more ...
code that'll be useful
Lester's Blog..........
Lester's Blog..........
Code for getting screen relative Position in WPF
One of the common customer queries that we see on the forums is to get the screen relative position of a point. Currently we do not provide an API which allows this functionality. However, Nick Kramer came up with this code on the forum and it works great for LTR (left to right) systems. Following is the code for getting the screen relative position :
static Point TransformToScreen(Point point, Visual relativeTo)
{
HwndSource hwndSource = PresentationSource.FromVisual(relativeTo) as HwndSource;
Visual root = hwndSource.RootVisual;
// Translate the point from the visual to the root.
GeneralTransform transformToRoot = relativeTo.TransformToAncestor(root);
Point pointRoot = transformToRoot.Transform(point);
// Transform the point from the root to client coordinates.
Matrix m = Matrix.Identity;
Transform transform = VisualTreeHelper.GetTransform(root);
if (transform != null)
{
m = Matrix.Multiply(m, transform.Value);
}
Vector offset = VisualTreeHelper.GetOffset(root);
m.Translate(offset.X, offset.Y);
Point pointClient = m.Transform(pointRoot);
// Convert from “device-independent pixels” into pixels.
pointClient = hwndSource.CompositionTarget.TransformToDevice.Transform(pointClient);
POINT pointClientPixels = new POINT();
pointClientPixels.x = (0 < pointClient.X) ? (int)(pointClient.X + 0.5) : (int)(pointClient.X - 0.5);
pointClientPixels.y = (0 < pointClient.Y) ? (int)(pointClient.Y + 0.5) : (int)(pointClient.Y - 0.5);
// Transform the point into screen coordinates.
POINT pointScreenPixels = pointClientPixels;
ClientToScreen(hwndSource.Handle, pointScreenPixels);
return new Point(pointScreenPixels.x, pointScreenPixels.y);
}
[StructLayout(LayoutKind.Sequential)]
public class POINT
{
public int x = 0;
public int y = 0;
}
[DllImport("User32", EntryPoint = "ClientToScreen", SetLastError = true,
ExactSpelling = true, CharSet = CharSet.Auto)]
private static extern int ClientToScreen(IntPtr hWnd, [In, Out] POINT pt);
static Point TransformToScreen(Point point, Visual relativeTo)
{
HwndSource hwndSource = PresentationSource.FromVisual(relativeTo) as HwndSource;
Visual root = hwndSource.RootVisual;
// Translate the point from the visual to the root.
GeneralTransform transformToRoot = relativeTo.TransformToAncestor(root);
Point pointRoot = transformToRoot.Transform(point);
// Transform the point from the root to client coordinates.
Matrix m = Matrix.Identity;
Transform transform = VisualTreeHelper.GetTransform(root);
if (transform != null)
{
m = Matrix.Multiply(m, transform.Value);
}
Vector offset = VisualTreeHelper.GetOffset(root);
m.Translate(offset.X, offset.Y);
Point pointClient = m.Transform(pointRoot);
// Convert from “device-independent pixels” into pixels.
pointClient = hwndSource.CompositionTarget.TransformToDevice.Transform(pointClient);
POINT pointClientPixels = new POINT();
pointClientPixels.x = (0 < pointClient.X) ? (int)(pointClient.X + 0.5) : (int)(pointClient.X - 0.5);
pointClientPixels.y = (0 < pointClient.Y) ? (int)(pointClient.Y + 0.5) : (int)(pointClient.Y - 0.5);
// Transform the point into screen coordinates.
POINT pointScreenPixels = pointClientPixels;
ClientToScreen(hwndSource.Handle, pointScreenPixels);
return new Point(pointScreenPixels.x, pointScreenPixels.y);
}
[StructLayout(LayoutKind.Sequential)]
public class POINT
{
public int x = 0;
public int y = 0;
}
[DllImport("User32", EntryPoint = "ClientToScreen", SetLastError = true,
ExactSpelling = true, CharSet = CharSet.Auto)]
private static extern int ClientToScreen(IntPtr hWnd, [In, Out] POINT pt);
Tuesday, October 10, 2006
AnimationBehaviors
AnimationBehaviors is a library (dll) built for Windows Presentation Foundation (WPF) that makes it easy to add common animations to elements in XAML with little effort. Adding animations becomes as easy as adding an attribute to an element in XAML. AnimationBehaviors simplifies the process of creating page transitions, layout animations, and other common types of animations in WPF.
AnimationBehaviors
AnimationBehaviors
Wow---printing 3D graphics
Here is what he writes about the wonder of WPF Printing the 3D Graphics with just 5lines of code
From Eric's Blog:Eric Writes......
The last time I worked on an app which used 3D graphics, printing was fairly simple. OpenGL was brand new and DirectX didn't exist yet, so we had to do all the projection math anyway. Adapting the code from screen to paper wasn't a big deal.
Modern graphics APIs are great, but they don't help with printing. Since I started my woodworking app using C# and Direct3D, I always figured it would be a huge task to implement printing. More to the point, since this app is a hobby project and the implementation of printing would probably be like real work, I figured this app would never be able to print.
Recently I switched everything over to WPF. Here is my printing code:
PrintDialog dlg = new PrintDialog();
if ((bool)dlg.ShowDialog().GetValueOrDefault())
{
dlg.PrintVisual(myViewport, "sawdust");
}
Five lines. Were it not for my pathological need to use braces on every if statement, it would be three lines.
Yes, yes I know -- a useful real-world printing feature would require more work. I'm just saying: I added these five lines to my app and a color picture of my bookshelf model emerged out of the printer down the hall. That's excellent.
Wow.
Sunday, October 08, 2006
Monday, July 31, 2006
The #1 online source for .NET/XML and Web Service Topics
The #1 online source for .NET/XML and Web Service Topics: "The XML for ASP.NET Developers Website now offers online video tutorials that help you learn XML and Web Service concepts visually. Videos are available in either Flash and/or Windows Media format."
Sunday, June 04, 2006
Thursday, June 01, 2006
Friday, May 12, 2006
Thursday, May 11, 2006
Monday, May 08, 2006
Saturday, May 06, 2006
Friday, May 05, 2006
Tuesday, May 02, 2006
What is WinFx Workflow, and why bother?
Workflow, of course, is one of those deeply overloaded terms that hinders communication as often as it helps, so I’d better say what I mean by it.
Workflow comes down to just two ideas: that there is work to do, which a workflow sees as opaque units of behavior; and flow, which describes what work gets done when.
So is this a Workflow?
public void HandleLoanRequest (string customerID, Application app)
{
if (CheckCredit(customerId, app.Amount))
{
MakeOffer (customerId, app);
}
}
Yes, I believe it is. The work is checking the customer’s credit and making an offer – and HandleLoanRequest defines if and when this work is performed.
But the fact that workflow vendors have traditionally felt that something more than this sort of code is required before they declare victory suggests that we’re still missing a key notion.
This, I believe, is that we don’t just need to describe the flow, but describe it in a way that we can inspect, reason over, and manipulate. In short, workflow needs a model.
C# is one way to do this - we can define coding standards that allow us to scan workflow code and draw a graph of the flow, for instance. Or we could define attributes for the developer to use to call out the parts of his code that form the model. This is not the choice that we made for the Windows Workflow Foundation – and I’ll talk about why we chose what we did in later posts – but it would work.
But back to why we might need a model. We’re going to have to put in effort to create it, so why bother? Where’s the payback? (or the beef, as this Englishman abroad is learning to call it).
Well, I think the payback comes from what the model enables -
Visualization Useful for the developer, during both development and maintenance, but also for the workflow user who wants to know why they are supposed to be doing what they’ve been asked to do, or the IT Ops guy who wants to know what some misbehaving app is, or should be, up to.
Expressiveness A workflow model is a Domain Specific Language, specialized to support characteristic problems. An example is a review process where three positive votes out of five reviews mean that the document is good – and any outstanding reviews can be canceled. This is a little tedious to code, but the Windows Workflow Foundation includes out-of-the-box constructions that address such problems.
Execution The runtime can exploit the model to take away the need to solve the same problems over and over again. In the Windows Workflow Foundation we built in support for the knotty problems of long running workflow such as state management and compensation – controlled by simple, expressive model elements.
Monitoring The existence of a model makes it possible to produce an event stream with a meaningful semantic without any additional developer effort. This can then be used to monitor instances of workflows, or aggregates. Windows Workflow Foundation allows also allows declarative decoration of events with application data pulled from the workflow state - so that you can tell that credit check has started for order 14532.
Transformation Models beget models. An example is the transformation of a workflow model into the Message Exchange Pattern required to communicate with it – as Dharma and Don demonstrated so beautifully at the PDC. Another is customization. An ISV ships a workflow, which is customized by a VAR, and then again by a customer. Then the ISV ships a new base version. The use of a shared, well understood model for the workflow makes the consequent 3-way merges much more tractable.
Composition If an application is factored into flow and work, then the atomic elements of work, with their well understood interfaces, can be reused by other workflows. Workflows themselves are valid definitions of work that can also be used by other workflows.
Customization and transformation together enable ecosystems where definitions of work and flow become shared or traded artifacts.
Manipulation Often there are requirements to invent or modify workflows on the fly. If this means changing code, then there are going to be problems with the security folks – even if the users understand how to hack it. Using a model makes possible dynamic manipulation that is both controllable and comprehensible. The Windows Workflow Foundation supports the dynamic modification of both workflow types and workflow instances.
So that’s it (or at least, all that seeps into my mind this Saturday afternoon). That’s why we thought a model was a good idea, and why we think it has great ROI. But if none of these benefits apply in your scenario, then really, coding is still very cool.
Workflow comes down to just two ideas: that there is work to do, which a workflow sees as opaque units of behavior; and flow, which describes what work gets done when.
So is this a Workflow?
public void HandleLoanRequest (string customerID, Application app)
{
if (CheckCredit(customerId, app.Amount))
{
MakeOffer (customerId, app);
}
}
Yes, I believe it is. The work is checking the customer’s credit and making an offer – and HandleLoanRequest defines if and when this work is performed.
But the fact that workflow vendors have traditionally felt that something more than this sort of code is required before they declare victory suggests that we’re still missing a key notion.
This, I believe, is that we don’t just need to describe the flow, but describe it in a way that we can inspect, reason over, and manipulate. In short, workflow needs a model.
C# is one way to do this - we can define coding standards that allow us to scan workflow code and draw a graph of the flow, for instance. Or we could define attributes for the developer to use to call out the parts of his code that form the model. This is not the choice that we made for the Windows Workflow Foundation – and I’ll talk about why we chose what we did in later posts – but it would work.
But back to why we might need a model. We’re going to have to put in effort to create it, so why bother? Where’s the payback? (or the beef, as this Englishman abroad is learning to call it).
Well, I think the payback comes from what the model enables -
Visualization Useful for the developer, during both development and maintenance, but also for the workflow user who wants to know why they are supposed to be doing what they’ve been asked to do, or the IT Ops guy who wants to know what some misbehaving app is, or should be, up to.
Expressiveness A workflow model is a Domain Specific Language, specialized to support characteristic problems. An example is a review process where three positive votes out of five reviews mean that the document is good – and any outstanding reviews can be canceled. This is a little tedious to code, but the Windows Workflow Foundation includes out-of-the-box constructions that address such problems.
Execution The runtime can exploit the model to take away the need to solve the same problems over and over again. In the Windows Workflow Foundation we built in support for the knotty problems of long running workflow such as state management and compensation – controlled by simple, expressive model elements.
Monitoring The existence of a model makes it possible to produce an event stream with a meaningful semantic without any additional developer effort. This can then be used to monitor instances of workflows, or aggregates. Windows Workflow Foundation allows also allows declarative decoration of events with application data pulled from the workflow state - so that you can tell that credit check has started for order 14532.
Transformation Models beget models. An example is the transformation of a workflow model into the Message Exchange Pattern required to communicate with it – as Dharma and Don demonstrated so beautifully at the PDC. Another is customization. An ISV ships a workflow, which is customized by a VAR, and then again by a customer. Then the ISV ships a new base version. The use of a shared, well understood model for the workflow makes the consequent 3-way merges much more tractable.
Composition If an application is factored into flow and work, then the atomic elements of work, with their well understood interfaces, can be reused by other workflows. Workflows themselves are valid definitions of work that can also be used by other workflows.
Customization and transformation together enable ecosystems where definitions of work and flow become shared or traded artifacts.
Manipulation Often there are requirements to invent or modify workflows on the fly. If this means changing code, then there are going to be problems with the security folks – even if the users understand how to hack it. Using a model makes possible dynamic manipulation that is both controllable and comprehensible. The Windows Workflow Foundation supports the dynamic modification of both workflow types and workflow instances.
So that’s it (or at least, all that seeps into my mind this Saturday afternoon). That’s why we thought a model was a good idea, and why we think it has great ROI. But if none of these benefits apply in your scenario, then really, coding is still very cool.
Subscribe to:
Comments (Atom)