OPC - the Open Packaging Conventions - is a recently approved standard for packaging data into a single, compact file. Many people, myself included, have had to create file structures in the past to maintain data in a single file; this creates a packaging standard for creating file structures in a discoverable fashion.

The coolest part about the whole thing is there is an API surrounding it in the .NET framework 3.0 - that is enough of a reason, alone, to be curious about it. It leverages ZIP as the compression format, uses a relational hierarchy for the contained parts and, like I said earlier, supports the concept of discoverability.

Check out this MSDN entry for more if you're curious about what this might provide for you: http://msdn.microsoft.com/msdnmag/issues/07/08/OPC/default.aspx.

MSDN Notes: Implementing the CLR Asynchronous Programming Model (Jeffrey Richter)

Source: http://msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs/

1.       Introduction

a.       For applications that require interaction with IO, the answer is often to write into the solution more threads – this still incurs an overhead, however, in terms of the operating system resources needed to spawn and manage threads.

b.      The better solution, according to this article, is to use the CLR’s Asynchronous Programming Model (APM) in lieu of the a more heavily threaded application.

c.       There are four main reasons, according to this article, why you would write a class that implements the APM.

                                                               i.      You’re building a class that directly interacts with hardware,

                                                             ii.      You might be building an abstraction layer atop a class or code base that already talks to hardware,

                                                            iii.      You may have long-running methods in your class,

                                                           iv.      You might be wrapping non-asynchronous Win32 functions.

2.       The heart of the APM: IAsyncResult

a.       Any class implementing APM has a Begin/End method (ex: BeginRead/EndRead) pair of methods. The Begin version must create and return an Iasyncresult object that is the center of APM model.

                                                               i.      The object can be queried for the status of the asynchronous operation and is used to determine the result when the operation is completed.

b.      IAsyncResult has a property – a wait handle – that is actually ineffecient to use and so ought to be avoided if at all possible (many asynchronous operations will have a callback anyway, signalling the end to the operation).

 

 

 

There seems to be a lot of confusion out there with regards to getting the ENTER key to submit a form. I'm here to tell you that the best solution I have found (and the one I use) is to drop whatever TextBox controls I'm using and the final Submit button into a panel control, and then set the DefaultButton property of the panel to the button to be clicked when ENTER is pressed. For example:

<asp:Panel ID="Panel1" runat="server" DefaultButton="Button_Search" Height="50px"
        Width="329px">

When focus is in a TextBox control inside the Panel and the ENTER key is struck, Button_Search will be "clicked" or invoked by the browser to post back the form data. The result is the feel of google's search engine where you simply type in the text box and hit ENTER to start the search.

A default button can also be supplied for the Form object itself, and this is set as a property on the form object too.

One thing to note is that the default behavior when a form is submitted through an ASP.NET button control is that the __EVENTTARGET or "source" of the form post is set to nothing. For example, by clicking a submit button manually, the Form variables posted look like this:

__LASTFOCUS=&__EVENTTARGET=&__EVENTARGUMENT=

However, by having the ENTER key cause the form post, the "cause" of the form post is manually set to actually be the button:

__LASTFOCUS=&__EVENTTARGET=Button_Search&__EVENTARGUMENT=undefined

This causes ASP.NET to have a fit if you do not have the following option set on the page (which can also be set through the web.config file):

<%@ Page EnableEventValidation="false"

The error you will see will be something like this:

Invalid postback or callback argument.  Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Care should be had when setting the EnableEventValidation to false as it is set to True for security reasons.

Source: http://msdn.microsoft.com/msdnmag/issues/07/06/silverlight/default.aspx

 

1.       Introduction.

a.       Currently supports Mac OSX Safari and FireFox, Windows FireFox and IE

b.      Can be interacted with by AJAX code.

2.       Introducing Silverlight

a.       XAML is text-based and exposes it’s DOM to the browser in a scriptable manner (therefore, it is “functional”).

b.      The browser loads the XAML and creates a DOM that can be interacted with via script code, including modifications by script and event handling/processing.  You may also interact with the XAML DOM through methods (such as methods that start playing, stop playing or pause a presentation).

3.       XAML Overview

a.       XAML was first introduced as part of Windows Presentation Foundation; though the XAML used by Silverlight is a web-based subset of the full XAML supported by WPF.

b.      Silverlight XAML markup is based on the <canvas> tag; the “surface” upon which objects will be drawn.

4.       Inside the XAML

a.       There is support for pre-defined shapes, gradients, etc.

5.        Transformations, Media, and Animations

a.       XAML has built in support for transformations on objects (MatrixTransform, RotationTransform, ScaleTransform, etc).

b.      MediaElement tag controls video and audio.

c.       Animations are defined in XAML by how properties change with time.

6.       A simple silverlight application

a.       Currently silverlight.js is required to be located within the /js folder for your web application.

b.      Sys.Silverlight.createObjectEx() implements a new silverlight control.

c.       The silverlight plugin loads into a DIV tag with a unique ID.

d.      Dynamic features can be added to the Silverlight application (such as the source for a particular video) but modifying the script that controls and instantiates the objects through the ASPX page’s rendered output.

7.       Delivering XAML to the Silverlight Front-End

a.       The server can process and build the XAML as needed; the Sys.Silverlight.createObjectEx() method simply takes this markup to load and instantiate the XAML as a silverlight object.           

For those that deal in the world of asynchronous clientside programming, you've definitely encoutered JSON - the JavaScript Object Notation. The standard way of taking JSON formatted data and transforming it back into the javascript objects which it describes has been the eval() method. The problem, though, is that this is effectively invoking the JavaScript parser engine for the browser on potentially untrusted code - the javascript parser will basically execute whatever you give it through this method.

A relatively nice article (http://msdn2.microsoft.com/en-us/library/bb299886.aspx), it describes a script library located off of www.json.org (http://www.json.org/json.js) that provides a much more secure way of parsing JSON formatted data "parseJSON()". It's cousin "toJSONString()" is used to create the JSON strings.

...personally I haven't used this methodology, but it appears promising (at least until there is a much more standardized way of doing it).  

Real buggy coding night. I'm in the process of putting together a site for myself when I ran into this problem:

http://forums.microsoft.com/msdn/showpost.aspx?postid=98346&siteid=1

Basically "Failed to generate user instance" and "An attempt to attach...failed".

For "An attempt to attach....failed" I was able to get around this by simply rebooting my development machine. Apparently there is some local cache of files stored on the hard drive that SQL Server Express uses and this was getting out of wack - somehow rebooting the system did the trick for me. It went away, but I was not able to identify exactly what caused the problem; to me this is a bad thing - I really like knowing WHAT happens when something goes wrong.

The "Failed to generate user instance" came from me being remoted into work from home (that'll teach me to work from home). Oh well, I guess I get my site done tomorrow.

Hrmph. :-(

We've all been pounded with "beware of SQL Injection Attacks" - yet I found a rather nice blog post here: http://blogs.msdn.com/dglover/archive/2005/06/01/423727.aspx that hands out a nice filter method for SQL Server. You might as well have a look and see if you can introduce it into your stored procedures....

http://msdn2.microsoft.com/en-us/library/ms364069(vs.80).aspx

Writing code that is fully interoperable with two different runtimes can blow; 'nuff said. The single-most valuable thing to remember when doing COM interop (in my opinion) is to add your damn .NET module to the GAC. Why?

The reason lies in the internals of COM, and if you've ever had the distinct pleasure of pounding your head against the desk while working on COM you'll quickly understand what I'm trying to say. COM was built with the ideals of interoperability in mind: so long as the two, distinct components stuck to a particular contract-based communcation (through "interfaces") then everything worked nicely.

In COM to get at a particular bit of functionality (which is exposed via an "interface") you must get at the Com Class (coclass) which implements the interface. A particular COM server houses the Com Class (coclass) which implements the interface. Basically, to get at functionality, then, you must locate the physical module, then ask the physical module to activate a particular "object" and then ask the "object" for an interface pointer to the functionality; the rest is done through vtable pointer arithmetic (this is all if you're using "IUnknown" semantics, otherwise the game is slighty different).

.NET interops with COM by having the mscorlib.dll module be the server - it is responsible for loading the necessary DLL files that implement your .NET functionality and doing all the proper dirty work of interoperating with COM. Say you have a COM plugin, then, for some application - but the plugin is written in VB.NET. The main application attempts attempts to create a com instance (through CoCreateInstance()) of your .NET module - this routes the COM runtime to Mscorlib.dll which attempts to locate your DLL; however, how does Mscorlib.dll find it? Well, if you haven't placed it directly next to (in the same directory as) the main application or in the GAC, MScorlib.dll will not be able to find your module and you're, effectively, "dot screwed".

....by placing the module in the GAC you'll be able to guarantee mscorlib.dll will find your module.