Silverlight: DOCX-to-XAML using TextGlow.net

by Jon Davis 10. March 2008 02:07

At http://www.textglow.net/ they've proven that Silverlight 2 and its CLR is flexible enough to be able to take a .docx file (that's a modern Microsoft Word document) and browse it in Silverlight. I am assuming it's converting to XAML under the covers, and even if not I'm sure that a Canvas object and its contents are serializable to XAML (yes?).

What I want to know is, if a Word document can be browsed in Silverlight, why doesn't Microsoft take this another nineteen miles and convert XHTML+CSS to XAML and make Internet Explorer 9 or IE 10 a completely WPF based renderer?

I know that's not nearly as simple as it sounds; there is a vast amount of complexity in Trident.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Computers and Internet | Cool Tools | Web Development

Silverlight: We've Got Window.Eval()!! Yay!!

by Jon Davis 9. March 2008 23:52

W00t!! The window.eval() function is something I've been wanting in Silverlight forever!! Looks like it's here now, finally, in Silverlight v2!

// App.xaml.cs:
private void Application_Startup(object sender, StartupEventArgs e)
{
    // Load the main control      // generated
    this.RootVisual = new Page(); // generated
 
    // added ..
    string html = HtmlPage.Window.Eval("document.documentElement.innerHTML").ToString();
    HtmlPage.Window.Alert(html); // worked!
}

Now lemme try some jQuery ..

<!-- HTML: -->
<script type="text/javascript" language="javascript">
    function showAlert(el) {
        alert("Alert from jQuery introspection of $(" + el.tagName + ").html() ..\n\n"
            + $(el).html());
    }
</script>

...

// App.xaml.cs:
private void Application_Startup(object sender, StartupEventArgs e)
{
    // Load the main control       // generated
    this.RootVisual = new Page();  // generated
 
    object bodyObject = HtmlPage.Window.Eval("document.body");
    HtmlPage.Window.Invoke("showAlert", bodyObject);
}

W00t! It works!! Now lemme try some plugin interop using only outer passing...

<!-- HTML -->
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
    codebase="
http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"
    width="550" height="400" id="tweenMov">
    <!-- first random swf I found -->
    <param name="movie" value="
http://www.albinoblacksheep.com/flash01/tweenaflashodyssey(www.albinoblacksheep.com).swf">
   
    <param name="quality" value="high">
    <param name="bgcolor" value="#000000">
    <embed src="/support/flash/ts/documents/myFlashMovie.swf"
        quality=high bgcolor=#FFFFFF width="550" height="400"
        name="tweenMovie" id="smurfsMovie align="" type="application/x-shockwave-flash"
        pluginspage="
http://www.macromedia.com/go/getflashplayer">
    </embed>
</object>
  
...
  
// App.xaml.cs:
object movieObject = HtmlPage.Window.Eval("tweenMovie");

Hmm, putting a breakpoint on this and introspecting movieObject, it's still an HtmlElement with nothing much associated with it.

I can still pass it around as an object reference ...

Initial jQuery test:

<!-- HTML  <script>: -->
window.onload = function() {
    var movieObj = $("#tweenMov")[0];
    alert("bgcolor=" + movieObj.bgcolor + "\n"
        + "quality=" + movieObj.quality);
}

.. and then try same test after passing to Silverlight and having Silverlight pass it back out again ..

<!-- HTML <script>: -->
function showParams(movieObj, fromMsg) {
    alert(fromMsg + "\n\nbgcolor=" + movieObj.bgcolor + "\n"
        + "quality=" + movieObj.quality);
}

..

// App.xaml.cs:
object movieObject = HtmlPage.Window.Eval("tweenMov");
HtmlPage.Window.Invoke("showParams", movieObject, "From Silverlight:");

Worked! Tested in Firefox, too, but it failed; apparently, it choked on the Flash markup before the other stuff had a chance, and I'm too tired to clean it up.

Now let's see if I can declare Javascript functions on the fly so that I can use browser scripting to perform cross-plugin communications without prior scripting in markup:

// App.xaml.cs:
object val = HtmlPage.Window.Eval("function showHelloWorld() {"
    + "     alert(\"Hello world! This is Silverlight talkin!\");"
    + "     return \"Yay!\";"
    + "}"
    + "showHelloWorld();");
HtmlPage.Window.Alert(val.ToString());

It works. Yay!! Can I do the same to elaborately introspect the Flash plug-in?

object val = HtmlPage.Window.Eval("function getFlashBgColor() {"
    + "return $(\"#tweenMov\")[0].bgcolor;"
    + "}"
    + "getFlashBgColor();");
           
HtmlPage.Window.Alert("Flash background color: " + val.ToString());

Looks like I got my wish! Now I can use the CLR to control DHTML through the browser script runtime, which alone knows the full extent of its DOM. Silverlight is browser script runtime friendly!

kick it on DotNetKicks.com

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Computers and Internet | Software Development | Web Development

Silverlight+DHTML+ASP.NET Coding Blog By Wilco

by Jon Davis 9. March 2008 23:17

http://www.wilcob.com/Wilco/

Really cool blog detailing Silverlight / DHTML / ASP.NET interaction, I haven't read the entries to detail yet, just skimmed it, but looks really interesting so far.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Software Development | Web Development

Silverlight Gets 1.5 Million Downloads Per Day

by Jon Davis 9. March 2008 13:43

At the MIX 08 keynote ..

http://msstudios.vo.llnwd.net/o21/mix08/08_WMVs/KYN0801.wmv
.. or if that fails, http://sessions.visitmix.com/

.. it was announced that Silverlight is being installed by Internet users at a rate of 1.5 million installations per day.

I think we can now pretty much rule out the question as to whether Silverlight is going to reach critical mass enough for it to not be "weird" if you expect your users to download Silverlight before using some widget on your site. I wouldn't have cared, because I knew better, were it not for having to work with co-workers who beat their chests in pride and remain intentionally oblivious to the sheer significance that Silverlight brings to the web on the whole, even now.

kick it on DotNetKicks.com

Currently rated 3.4 by 5 people

  • Currently 3.4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Computers and Internet | Cool Tools | Web Development

Silverlight vs. ActiveX: Give me automation or give me death!

by Jon Davis 8. January 2008 18:49

In the wonderful IE4 days when ActiveX was the big new thing, you could create an ActiveX control -- that is, a first class COM object - in full Visual Basic. In fact, Microsoft released a free version of Visual Basic just for creating ActiveX controls. It was ridiculously easy to create COM objects in this way.

Then you could instantiate the object in the browser scripting engine and do things like:

<script>
myActiveXObject.HtmlDocument = document;go
</script>

With that one line of code, (popping knuckles) the full-blown Visual Basic programming environment had access to the Internet Explorer web browser document object. There was no wrapper, just a COM interface!!

Visual Basic:

Call Me.HtmlDocument.window.eval("alert(""Hello from full-blown Visual Basic via the browser's Javascript scripting engine"");")

Me.HtmlDocument.body.innerHTML = "<h3>Muahahaha!</h3>" & Me.HtmlDocument.body.innerHTML
Me.HtmlDocument.body.style.backgroundColor = "#00000"
Me.HtmlDocument.body.style.color = "#ffffff"

Call Me.PlayVideo()

' etc.

Likewise, the COM interfaces of the ActiveX control were directly and effortlessly exposed to the browser Javascript runtime.

<script>
myActiveXObject.PlayVideo();
</script>

This opened all kinds of doors of opportunity. Event sinks and controllers could be dropped in every which way. Flexibility of writing code was virtually limitless.

This WAS doable before Microsoft abandoned Visual COM (Visual Basic 4/5/6). The ActiveX Script runtime engine was a marvelous invention. I'll admit that it's proprietary to Internet Explorer, though, but Mozilla has traditionally supported COM in some fashion. I don't know how Mozilla's plug-in and scripting runtime integrations work.

Fast forward to today. Rich client applications are now written in Javascript and AJAX, making use of only one specialized COM object (or other automation object, depending on the browser) now known today as XMLHttpRequest. Rich client apps also make heavy use of objects-based programming.

In order to create user experiences that are outside of the capabilities of Dynamic HTML, plug-ins are still used. This is where plug-ins like Silverlight come in. But those plug-ins, especially when they have broad and powerful runtimes like Flash (ActionScript) or Silverlight (CLR), need to be able to be interopable with the browser's script runtime in order for utilization to be fully realized. In the Internet Explorer world, the answer to this was simply IUnknown / COM / ActiveX.

Browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa.

ActiveX componentization is now virtually deprecated. Microsoft no longer sells nor supports Visual COM (Visual Basic 4/5/6, which was the only tool Microsoft ever created to allow users to be able to effortlessly create COM objects). ActiveX controls are also a security concern, and in Internet Explorer 7, users are discouraged from installing them.

But what I'm looking for is unwrapped interop support between the Silverlight CLR and the browser's runtime. Silverlight doesn’t have access to the Javascript DOM. It has access to a limited set of objects and properties of the HTML DOM using a wrapper API.

http://silverlight.net/QuickStarts/Dom/DomAccess.aspx

The CLR in Silverlight introduces a secure but powerful runtime engine to the web environment and an extent of sophistication that previously never existed, not even with old Visual COM (Visual Basic 4/5/6). Now that Silverlight 2.0 is coming out soon with a rich programmatic runtime like Visual COM (VB) used to have, I’d like rich COM automation back. The value is more fully realized when you can pass browser Javascript objects to the CLR or pass CLR-declared objects to the browser Javascript runtime.

(I'll post better examples of what used to work versus what doesn't work later this week. But yes, full COM interop was possible between VB and ActiveX Scripting, and yes you could pass objects back and forth. It even supported dynamically generated COM interfaces. For example, you could declare and instantiate a class in VBScript in the browser, pass the instance to a method on an ActiveX control written in VB where the VB OCX property expects a Variant, and then VB OCX could call upon the functions within that class.)

Obviously, what this means is that Safari, Mozilla, and Microsoft would have to agree on an interop strategy. I thought they had already accomplished this, but it'd be surprising to me if they didn't. It would, however, further cement my frustrations with Microsoft that they allowed too many years to go by without staying involved with the browser standards communities like W3C and ECMA to work those issues out.

ActiveX componentization is not deprecated because COM is a security concern. It is deprecated because the technologies that implemented ActiveX were not sandboxed like Java applets, Flash, and Silverlight are. The Silverlight CLR is neatly sandboxed--this means that there are no longer serious security concerns that developers otherwise had with the ActiveX plug-in support--so if security is a concern, it shouldn't be.

But, practically speaking, browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa. Put as succinctly as I can, if I cannot declare a function in the browser script with parameters, and call on it from the CLR while passing CLR objects, I feel stuck with preferring old ActiveX over the Silverlight CLR for dynamicizing HTML. The same is true going the other way. The way things are right now, it's an all-or-nothing deal--either you completely rewrite the AJAX web application so that it no longer users the browser Javascript and uses the Silverlight CLR, or you don't use the Silverlight CLR and stick with the browser Javascript. These two options are completely unrealistic, from a business perspective.

Microsoft's position on this matter has so far been that they think the "wish is valid, but it is challenging since we are dealing with a scripting world, a native world and a managed world all in one wish."

I'm sure it is challenging. But this and true DHTML are precisely why I thought Internet Explorer v4 was the greatest invention that came out of Redmond after the Windows NT kernel. It's why Internet Explorer had been Microsoft's preferred generic COM host for SDKs and development for many years.

I don't care if it is challenging. It was Microsoft who invented COM. It was Microsoft who implemented the ActiveX Scripting engine. It was Microsoft who invented the fully programmable browser DOM. It was Microsoft who invented .NET and the Visual Basic and C# languages. I have no doubt that the most profitable corporation on the planet can figure something out in this matter.

But this is an issue I have that goes beyond Silverlight, it is about Microsoft's leadership role in the Internet client software industry. It's like they fired their automation visionaries as soon as IE4 went gold.

Perhaps that isn't fair; the CLR is certainly quite visionary. It's just that the current state of things shows abandonment of the industry necessity to keep striving to bridge the gap between the browser script runtime and the plug-in runtime; this is a problem that has been around for over a decade, and that the industry leaders aren't still pushing for a cross-browser automation solution really befuddles me.

There is one "trick" that I can think of, though, to make window.eval() happen from Silverlight that may or may not work efficiently. Perhaps you can get Silverlight to change the text value of a hidden HTML element. This HTML element is strictly used for window.eval(). Javascript would need to be notified that the value changed. A setInterval loop? An onchange event hook? Dunno. But once it sees it it can fire it off and then populate some other hidden element for the eval result. I'd prototype this but I don't think onchange will work and a setInterval loop frightens me, not to mention only being able to use text (or XML) for params and return values. The whole idea seems terribly kludgy... Yuck.

kick it on DotNetKicks.com

Currently rated 3.8 by 6 people

  • Currently 3.833333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , ,

Software Development | Microsoft Windows | Web Development

Testing Silverlight Instancing Scalability

by Jon Davis 14. December 2007 00:49

I have been curious for several months as to how scalable Silverlight is for instancing. That is, not how scalable will Silverlight perform within itself, but rather how many instances of Silverlight can fit on a web page at a time? Is it feasible to go so far as to actually use Silverlight controls where one would normally use PNGs to decorate a page, for example?

I finally got around to digging out these numbers myself by doing a test of my own.

My test consists of an HTML file with Javascript that, when a button is pressed, will generate an instance of Silverlight with a radial gradient and add it to the HTML DOM. If the button is pressed again, another instance is generated and appended to the HTML document.

I pressed the button 100 times and manually measured each one for RAM usage. The test was performed on a x64 environment, with Internet Explorer 7.0 as the browser and Silverlight 1.1 Alpha as the Silverlight build.

My hardware environment is an AMD Athlon X2 6000+ dual core system with 4GB RAM.

Test files:

The RAM usage was a tiny bit better than I expected. Rather than taking up 2 MB or so that I feared to be the worst case scenario, the reality was only an average of roughly 300KB of RAM per instance.

The CPU usage was another story. I don't have the measurements to show for it, but let's just say that at about 80-90 instances, it took about as many seconds, divided by ten, to be able to click on the "Add Silverlight Instance" button again. That is to say, the 85th click caused me to wait about 8 or 9 seconds before I could click again. I think the CPU overhead is actually rendering and invalidating the Silverlight controls, even the ones that are below the visible threshold of the page, because when the CPU goes back down to 0% and I scroll down, I have to wait another 9 seconds before Internet Explorer will stop locking up. Clearly, there are regional invalidation issues with Silverlight, but that's perhaps due to design, since regional invalidation works differently across platforms.

I ran into some hiccups along the way; had to restart my tests once (the RAM usage was within a MB to where I left off), and lost one measurement.

By the time I got to my 100th instance, the wait was more like 20 seconds. The CPU overhead apparently seemed to escalate very quickly at 90 instances.

I'd like to see someone do the exact same test in Flash. If no one volunteers here I'll try to find the time this weekend.

kick it on DotNetKicks.com

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Computers and Internet | Software Development | Web Development

Inline XAML

by Jon Davis 12. November 2007 03:53

I was whining earlier in some technology mailing lists that inline XAML isn’t supported by Silverlight. No one corrected me on that, but it looks like it is supported, rather cleanly and elegantly, except for a stupid Firefox bug. Thx to Jon Galloway for pointing all this out.

http://msdn2.microsoft.com/en-us/library/bb687962.aspx
http://weblogs.asp.net/jgalloway/archive/2007/10/31/silverlight-doesn-t-require-any-javascript.aspx

<html>
 
<head>
 
</head>
  <body>
    <script type="text/xaml" id="xamlContent">
        <?xml version="1.0"?>
        <Canvas ... >
                    ...
        </Canvas>
   
</script>

   
<div id="controlHost">
       
<object
           
id="silverlightControl"

            type
="application/x-silverlight"

            height
="400"

            width
="400">

         
<param name="Source" value="#xamlContent" />
       
</object>
   
</div>
</body>
</html>

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Web Development


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  January 2021  >>
MoTuWeThFrSaSu
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar