in

WPF Design and Development

IdentityMine Team Blogs

David Kelley

A day in the life of a humble software architect... doing C#, WPF, Silverlight, Legos, Fuzzy Logic AI and/or whatever is the latest and greatest or more importantly the coolest techo mumbo jumbo...

October 2007 - Posts

  • Silverlight, JSON and Automatic Design Asset Zip and index generation...

    Lets say we have a huge silverlight application.  And lets say that we have a lot of images, xaml and media that we use in our application.  Silverlight does a great job of allowing us to use downloaders and catch events and deal with it but lets say we want to just do it once.  Download everything in one file and then apply our assets.  We also don't want all of the loose assets floating around our Silverlight apps directory structure...

    From an architectural stand point this is a much cleaner method of keeping additional assets packaged especially when there is a lot of xaml and images etc and keep it as small as possible over the wire.  Silverlight allows us to address all that by being able to download zip files.  On the downside there is not dynamic way to know what is in the zip file and plus it is a pain to have to do it on your own.  So this is how I addressed it. 

    First I built a windows application project in Visual Studio without any windows.  I added directories with all my design assets and set them to be content and show up in the output directory.  When you compile the project it builds out the executable and copies all the folders and assets added to the project to the output directory.  From here Visual Studio starts the application.  Although it doesn't have a UI persay it starts by looking for any zips that might be in the directory and deletes them. 

    Now the cool part happens...  it looks at all the diretories and creates an index JSON file for each folder.  It saves these all in the root of each directory and then proceeds to create zip files for each directory automatically.  All I need todo is then have this projects zip files that are generated in the output folder be copied to my Silverlight project directory structure as a pre or post build event and I'm good.  All these additional assets are kept nicely packaged and out of the main project.  And I didn't have to mess with it on my own.

     Also note that the attached project doesn't have the zip.exe that builds the zip via console commands passed to it.  You can use the command line version of any thing like pkzip etc but you will have to edit the source of the main application to make it work.  I have my own licensed copy of this command line tool that (pkzipc.exe) which is what the argument structure is designed for.

  • Silverlight - Associating Files in Visual Studio

    So here is a Visual Studio trick I picked up from Josh in WPF land that applies to Silverlight.  One issue we found in Silverlight was when we were building big Silverlight applications and custom user controls that the XAML and .js files were not associated to each other.  But in Visual Studio if you know what todo its pretty straight forward.  Then yoru 'XAML files can have JavaScript code files even if created seperating with different names. 

    Here is how you do it. When you silverlight solution and project is open in Visual Studio Right click on the project in the visual studio solution explorer.  Click 'Unload Project'.  If the solution is tied to Source control you will get a dialog 'Attempt to unload projects with shared checkouts' and you can select the option you want.  So assuming you select 'continue' then the project is unloaded.  Right click on the project and select Edit [project filename].csproj.  You will see the project file open up in a raw xml edit mode.  Fine the 'itemgroup' collection that has the file you want to make dependent on another file.  Add a 'DependentUpon' node to the node that is your file and put the name of the file you want your file to be under.  Save and close the project file.  Then you right click the project and click 'reload' the project. 

    Its a cool trick and sure helped me clean up a few huge messy projects.

     

  • Popfly goes Beta

    Yea, Popfly Beta has gone live and now is open for everyone.  I'll have to go in and clean up some of the controls I did...

  • Identitymen To the Rescue

    Here is a cool Identitymen story that is right out of a comic book.  A business man is at a conference is struggling to get some Silverlight App running and calls for help.  Unclear if it is possible to get his app up and running in time for the conference.  In the nick up time an Identity'man' shows up and in about 10 minutes has it up and running ready for the conference.  He even had the logo on his super hero costume at 7am in Redmond...    Identitymen to the rescue :)

    (based on a true story)

  • Wiring Silverlight Into the Browser History/Back Button

    While watching a presentation Jason Cook was doing on flash he suggested some of the tricks used by other technologies could be used with Silverlight.  The trick I was interested in was particularly being able to wire things into the browser history so that the back button of the browser does something other then go back to a different web page.  This turned out the be a simple task.  The way my sample works is that the html file (or .net page etc) that is running the silverlght application includes this Silverlight Paging class.  At the end of the page is a block that initializes the class.  On initialization it adds an iframe to the root pointing at one of two proxy files.   The silverlight application then needs to add a proxy handler for setting application state based on any key it wants and each time application 'state' changes that you want to be a history 'point' you just call 'AddPage' with a key on the class.  When some one then hits the back button the browser loads a different proxy with a different key stored as a query string value; which is then returned to the proxy handler or 'delegate' that sets application state.  Slick as a whistle. 

    So lets look at that in more detail.  Starting from the page that hosts our Silverlight application we can see that there is a script include.  That script file includes our class and at the bottom of the page is our initialization code.  


     <script type="text/javascript">
      var SilverlightPager = new Paging();
      SilverlightPager.Init();
     </script>

    In the block of script at the bottom we have two lines of code.  The first creates a global reference and instance of our class and the second line calls the Init method.  If we go to our class source and go to the Init method and all it does is do a document.write and inserts an iframe that our class will use to create history paging entries. 

    In the paging prototype we also see two other methods.  The method 'AddPage' loads page proxies into our iframe to create entries using our key value. 

     SilverlightPager.AddPage( "somevalue that indicates state");

     in my sample project we just use an indexer in our Scene object on on mouse click on the button this happens:

      // Put clicked logic here
      this.indexer++;
      
      SilverlightPager.AddPage(this.indexer);

    Our next method is called 'OnReturnPage' which is actually called by our proxy pages.  So in our Silverlight application we call 'AddPage' and pass in a key value each time we change state in and what that to be a history point. In our sliverlight load we also need to associate a delegate to the 'PagingDelegate' member of our class like this: 

    SilverlightPager.PagingDelegate = MyAppChangeStateHandler;

    This will then be called each time our application calls 'AddPage' or clicks the browsers history button.  In both cases the page proxies are going to call OnReturnPage and pass in our path which will have the key as a querystring value that we then strip off and pass into the PagingDelegate to change the application state.  So then we get a little Flash Magic Mojo for our Silverlight app.

  • Silverlight 1.1 As A Sharepoint Web Part

    Recently I did a project where I had to embed a Silverlight web part into sharepoint.  You would think this is easy if you haven't done web parts before.  At least thats what I thought.  Granted I have done web parts but it always surprises how much jumping around I had todo.  I found what worked best for me was to create the 1.1 project as a silverlight based server control in a web site that ran all the bits and then to install that in the same domain as the sharepoint server.  At first I tried to make the web part duplicate what the server control did but for some reason Sharepoint would make it render is such a way that the silverlight ended up hidden...  I tried a few things but decided to use an iframe.  This way the web part only outputs a iframe pointed at the controls default page that loads the silverlight interface.  Works like a charm too.  :)  That sounds good but the steps ended up being something like this: 

    Silverlight Site Configuration

    1.       Copy the Silverlight Website folder to Server Location.

    2.       Open IIS Manager (Start-> All Programs -> Administrative Tools -> Internet Information Services (IIS) Manager)

    3.       Open Server Node (local Computer)

    4.       Open ‘Web Sites’ node.

    5.       Open Default running web site node

    6.       Right Click web site node and select New -> Virtual Directory

    7.       When the Virtual Directory Creation Wizard comes up click next

    8.       Enter the correct Alias ‘[some name]’

    9.       Click ‘Next’

    10.   Click ‘Browse’ and find the physical location of the site directory by drilling down in the ‘Browse For Folder’ and then select ‘OK’

    11.   Click ‘Next’

    12.   Select ‘Run Scripts’ check box

    13.   Click ‘Next’

    14.   Click ‘Finish’

    Web Part Configuration

    1.       Make sure the wep part project is compiled.

    2.       Copy the project to the Sharepoint server.

    3.       Copy the WebPart.dll to the bin directory under the wwwroot.

    4.       From the VS command prompt navigate to the bin directory under wwwroot.

    5.       gacutil the dll which should look something like this: gacutil –i WebPart.dll

    6.       from this same location in the VS command prompt use the command: sn –T WebPart.dll to find the strong name key.  For example: 7dd6db7c5d0189b7

    7.       Find the Sharepoint Web.config by opening up the IIS Manager and selecting the core site and then right click on the web.config and file the file location.

    8.       Add a ‘safecontrol’ node to the safecontrols section like this:

    <SafeControl

       Assembly="WebPart, Version=1.0.0.0, Culture=neutral,

          PublicKeyToken=7dd6db7c2d0088b7"

       Namespace="[some name space]"

       TypeName="*"

       Safe="True"

    />

    9.       Make sure the dwp file has a valid public token.

    10.   Go to the Sharepoint home page.

    11.   Click Site Actions and select ‘Show Page Editing Toolbar’

    12.   Click Page button in the toolbar. 

    13.   Select ‘Add Web Parts’ -> Import

    14.   Click Browse and find the dwp file in the project.

    15.   Click ‘Upload’

    16.   Select ‘Add to: Top Zone’

    17.   Click ‘Import’

    18.   Close the import right hand bar

    19.   Select publish from the toolbar

    So I'm not saying this is the right method or the best way todo it but it worked for me in my case...  abit of a hack but well its Sharepoint :) 

  • Releasing the Source Code for the .NET Libraries...?

    Check out this post on ScottGu's blog that Josh sent around this morning...  very cool :)

    http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

     

More Posts
© 2007 IdentityMine, Inc.
Powered by Community Server (Commercial Edition), by Telligent Systems