Thanks to Sebastian and his source here for my direction on this topic. Cheers man; I owe you Guinness.

There seems to be a severe lack of writing on the internet about how to do just this very thing - slowly blending one image to another using DirectX. I'm not an expert at DirectX, I spend most of my time these days doing web-based development, but I am also a software consultant and so get picked up for different types of jobs from time to time, and obviously it makes no sense to turn a job down....

....well, I wanted to implement a system where one texture slowly blended into another texture; kind of like a slow fade effect. As it turns out it's pretty trivial, but again not something I was very good at....

To do this correctly, you really want to do it independent of the image format, so that whether you're using something that has an alpha layer in it or not is irrelevant (like, a JPG vs. a PNG). To do this, you fill in or interpolate the alpha value of an image acrossed it using the vertices in the vertex buffer. So - you need to make sure that your vertices have an alpha color component. Likewise, to change the degree by which something blends, you change the alpha components of each vertex in the buffer. This actually gives you great control over the blending because you can choose even more advanced scenarios than simply blending from one image to another - you can also choose where to start the blending (from a particular corner to another, etc.).

So, on to the code....in the drawing loop for the application (if you're implementing your DirectX application correctly, this should be the Paint method):

        private void Form1_Paint(object sender, PaintEventArgs e)
        {

            _device.Clear(ClearFlags.Target, Color.Black, 1.0f, 0);
            _device.BeginScene();

            if (_zoomIn)
            {
                _alphaValue++;

                if (_alphaValue == 255)
                    _zoomIn = false;
            }
            else
            {
                _alphaValue--;
                if (_alphaValue == 0)
                    _zoomIn = true;
            }
            _verts[0] = new CustomVertex.PositionColoredTextured(-1.0F, 1.0F, 0.0F, Color.FromArgb(_alphaValue, Color.White).ToArgb(), 0.0F, 0.0F);
            _verts[1] = new CustomVertex.PositionColoredTextured(1.0F, 1.0F, 0.0F, Color.FromArgb(_alphaValue, Color.White).ToArgb(), 1.0F, 0.0F);
            _verts[2] = new CustomVertex.PositionColoredTextured(-1.0F, -1.0F, 0.0F, Color.FromArgb(_alphaValue, Color.White).ToArgb(), 0.0F, 1.0F);
            _verts[3] = new CustomVertex.PositionColoredTextured(1.0F, -1.0F, 0.0F, Color.FromArgb(_alphaValue, Color.White).ToArgb(), 1.0F, 1.0F);
            _verts[4] = new CustomVertex.PositionColoredTextured(-1.0F, -1.0F, 0.0F, Color.FromArgb(_alphaValue, Color.White).ToArgb(), 0.0F, 0.0F);
            _verts[5] = new CustomVertex.PositionColoredTextured(1.0F, -1.0F, 0.0F, Color.FromArgb(_alphaValue, Color.White).ToArgb(), 1.0F, 0.0F);

            _buffer.SetData(_verts, 0, LockFlags.None);

            _device.VertexFormat = CustomVertex.PositionColoredTextured.Format;
            _device.SetStreamSource(0, _buffer, 0);

            _device.SetTexture(0, _texture);
            _device.SetTexture(1, _texture2);

            _device.TextureState[1].TextureCoordinateIndex = 0;

            _device.SamplerState[1].AddressU = TextureAddress.Wrap;
            _device.SamplerState[1].AddressV = TextureAddress.Wrap;


            _device.SetTextureStageState(0, TextureStageStates.ColorArgument1, (int)TextureArgument.TextureColor);
            _device.SetTextureStageState(0, TextureStageStates.ColorOperation, (int)TextureOperation.SelectArg1);
            _device.SetTextureStageState(1, TextureStageStates.ColorArgument1, (int)TextureArgument.Current);
            _device.SetTextureStageState(1, TextureStageStates.ColorArgument2, (int)TextureArgument.TextureColor);
            _device.SetTextureStageState(1, TextureStageStates.ColorOperation, (int)TextureOperation.BlendDiffuseAlpha);

            _device.DrawPrimitives(PrimitiveType.TriangleStrip, 0, 2);

            _device.EndScene();
            _device.Present();

            Invalidate();
            return;
        }

The effect is two textures that slowly blend back and forth to each other.

Recommended Reading

ASP.Net doesn't like multiple forms on a webform; indeed, it is the paradigm now that one webform has one "form" on it (hence the name - webform). However, as people begin buliding tricky input forms on their pages it becomes necessary to specify "default" buttons throughout the page. As an example, say you're filling out one of two forms on a page and you want to hit the Enter key to submit your form data. If there are multiple forms on the page, then you will run into a problem as the browser attempts (and possibly fails) to ascertain which button should recieve the keydown event.

In ASP.Net the Panel control supports a default button so that you can "subsection" out your form with various different buttons being the default. If focus happens to be on a control within a panel that has one of these secondary submit buttons specified, then THAT button will get respond to your Enter keystroke.

Here's an example:

First, create a webform with two panels on it like this:



When you run the above form, regardless of whether your cursor is in the textbox of the first form or the second form, hitting ENTER will always act as if you clicked the button in the first.

To submit the button in the second via the ENTER key if your cursor is active in that textbox (or any control in that panel), do the following to the panels:

            First form:
            <asp:Panel ID="Panel1" DefaultButton="Button1" runat="server" Height="127px" Width="151px">
                &nbsp;
                <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
                <asp:Button ID="Button1" runat="server" OnClick="Button1_Click1" Text="Button" /></asp:Panel>
            <br />
            Second form<br />
            <asp:Panel ID="Panel2" DefaultButton="Button2" runat="server" Height="127px" Width="151px">
                &nbsp;
                <asp:TextBox ID="TextBox2" runat="server"></asp:TextBox>
                <asp:Button ID="Button2" runat="server" OnClick="Button2_Click" Text="Button" /></asp:Panel>
            </div>

Notice how I specify the "DefaultButton" property in the panel. Now if your cursor is active in any control within Panel2, Button2 will be the default submit button for your ENTER keystroke.

Addendum:

Please see here for the documentation to this attribute. It is available in the .Net frameworks 2.0 and 3.0 only.

Recommended reading:

This exercise requires no C# or VB.Net code at all (unless you want to start getting fancy), and is relatively well documented on the internet. However, I like to recap things quickly through these little tutorials, so hopefully this might summarize how to quickly get up and running with parent<->child window script communication.

First, create two web forms (they don't need to be, but for our exercise they will be). We'll call the Default.aspx and Default2.aspx.

Second, open up Default.aspx and add the following script functionality:

        <input id="Button1" type="button" value="button" onclick="window.open('default2.aspx');" />
        <input id="Text_Value" type="text" />

...here you see that you open up default2.aspx when you click on the button.

Third, go to your Default2.aspx file and add the following HTML:

        Please Enter Some Data:&nbsp;
        <input id="Text1" type="text" />
        <input id="Button1" type="button" value="button" onclick="return Button1_onclick()" /></div>

Fourth...add the following script:

function Button1_onclick() {
    opener.document.getElementById('Text_Value').innerText =
        document.getElementById('Text1').value;
    self.close();
   
    return;
}

The result will be opening up the default2.aspx form from default.aspx, you can enter text into the Text1 field (see above), click the Button1 which calls the Button1_onclick method. This method communicates with the parent window, sets a text box in that window's document and closes itself.

This requries no .Net code to accomplish; this can all be done through JavaScript.

Recommended reading:

Say you want to use the browser component to automate some form of web browser experience - for example, say you want to programmatically enter some value into a textbox and click a button using C# or VB.Net. To do this is actually quite simple (and, dare we say it, fun).

First, you simply add your browser component to your windows form.

Second, you register an event handler with the browser component for the DocumentCompleted event:

            this.webBrowser1.Url = new Uri("http://www.google.com");
            this.webBrowser1.DocumentCompleted += new WebBrowserDocumentCompletedEventHandler(webBrowser1_DocumentCompleted);

Third, you fill in the event handler with something that looks like this:

        void webBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
        {
            if (!_clicked)
            {
                _clicked = true;

                HtmlElement queryBox = this.webBrowser1.Document.All["q"];
                queryBox.SetAttribute("value", "hello world");

                HtmlElement goButton = this.webBrowser1.Document.All["btnG"];
                goButton.InvokeMember("click");
            }

            return;
        }

This will load the www.google.com homepage, fill in their submit text box and click the Search button.

In the golden days of MSHTML component reuse (before the niceness of .Net'ifying the browser DOM) you had to use a RCW (Runtime Callable Wrapper) around the MSHTML COM library. Everything is obviously implemented through IDispatch here (because you have to be able to do this stuff from VB6 or scripting environments), and so much of the invocation of methods (like click) was done by loosly picking the name for the method and building the stack frame through arrays, etc. The RCW made things a bit nicer for you (you didn't have to think about IDispatch), but you still had to think about COM.

It's been years since I've developed in COM and ATL and I'm glad I don't have to anymore.

Recommended reading:

Say you have a master page and content page scenario, and from the content page you want to interact with DOM elements described from the master page (for example, the main body element). This is how I do it:

First, add the following attributes to your body element so that it is included in the server-side runtime and can be interacted with from there:

<body id="mainbody" runat="Server">

...notice how the body element now has an id and has the runat="server" attribute set.

Second, from code within the content page (I'm doing it in Page_Load) add code like this:

    protected void Page_Load(object sender, EventArgs e)
    {
        HtmlGenericControl ctrl = (HtmlGenericControl)this.Master.FindControl("mainbody");
        ctrl.Attributes.Add("onload", "alert('hello');");
        return;
    }

The key here is to now grab the body element, add some script to it, and then let it all run as normal. When I run the solution, the content page is loaded, its Page_Load called, the script injected into the body element (of the master page) and I see "hello".

Recommended reading:

This is actually a variation on another post I made where I described how to detect when a partial postback has started and ended in ASP.Net AJAX. A great example of using this code is changing the mouse cursor when a partial postback occurs, and then resetting it when the postback completes. The following code will accomplish this:

            <script language="javascript">
                var req = Sys.WebForms.PageRequestManager.getInstance();
                req.add_endRequest(OnFinishedRequest);
                req.add_beginRequest(OnStartedRequest);
                function OnFinishedRequest(sender, args)
                {
                    document.body.style.cursor='default';
                }
                function OnStartedRequest(sender, args)
                {
                    document.body.style.cursor='wait';
                }
            </script>

...one thing to keep in mind when doing this is that the document body element doesn't necessarily take up the entire browser window; and so you will sometimes want to style the body element to make it the right size to take up the entire window.

Recommended reading:

If you look within the ASP.Net AJAX framework you will find no methods for registering UpdatePanels with the ScriptManager; why? The reason is because UpdatePanels register themselves with the page's ScriptManager control in their OnInit method:

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    this.RegisterPanel();
    this.CreateContents(base.DesignMode);
}

What this means is that when an UpdatePanel responds to the Init event, it will register itself with the ScriptManager for that page. You can get the exception detailed above when you have inadvertantly registered an UpdatePanel (because it was added to the page), but it was never rendered to the page. What happens is locally (that is, within the browser) the ASP.Net AJAX script runtime will execute as if the UpdatePanel was in the page DOM; but since it isn't an exception gets thrown, which is the exception you see above.

Two ways to fix this:

1) Dynamically add the UpdatePanel to your page only when you need it,
2) Set the UpdateMode of the panel to Conditional.

Recommended reading:

I'll go into the reason why this happens in a second, but sometimes you'll encounter an exception like this:

"InvalidCastException was unhandled by user code: unable to cast object of type 'ASP.xxxx' to type 'xxxx'". It looks like this:



You might think the way to fix this exception would be by casting to the ASP.home_aspx (in this example) type (which I'll explain to you a minute), but often this does not work either. Why? What's going on?

This is all the result of the dynamic build nature of ASP.Net. What's happening is that types are being automatically generated for you by the ASP.net runtime in some temp directory on your disk. Occasionally this system gets mucked up and you run into typing conflicts.

The way it all works is that ASP.home_aspx (in this example) is the final class that is executed by the ASP.Net runtime when it asks to render out the home.aspx. home_aspx inherits from the class as defined in the .cs/.vb/.aspx files you actually hand-write. ASP.Net inherits from your class so that it can add various other bells and whistles to the class to actually run correctly within the runtime (lots of details here).

...the only thing I can reason that happens when you get a TYPING conflict in this scenario is that the base class the runtime is using for, in this situation, home_aspx is actually a stale object; one that wasn't properly cleaned up by the runtime/Visual Studio. To fix this situation, you generally need to only clean out the temporary asp.net files for this particular site under:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\

Interesting how this looks like a bug in the .Net runtime, but it's actually a bug in the build environments.

Recommended reading: