Monday, June 13, 2005

I just learned through Scott and Simon that you can add new fonts to the Windows Console. Great, I've added my ProggySquare font to the list. See how great my XceedBox.NET sample looks:

XceedBox.jpg

Neat!


Fun

6/13/2005 9:40:41 AM (Eastern Daylight Time, UTC-04:00)  #   
 Thursday, June 09, 2005

In the new package v1.2.5309 which will be available for download next week resides a new feature you won't see much emphasis about, but which I was very eager to complete. You can now create a ZipArchive instance around an AbstractFile that does not support reading from.

(drum roll) ... (looking around) ... Nobody's applauding? That's because you probably don't know yet how useful this can be.

Most ASP.NET applications that wish to create zip files on the fly and send them in the response are either stuck with creating those zip files on disk in a temporary filename, or create them in a MemoryFile, then copy that MemoryFile in the response stream.

However, the StreamFile class was created for such purposes of exposing any existing Stream as an AbstractFile. You already could create a StreamFile around the Response's OutputStream. But passing that StreamFile to the ZipArchive's constructor would fail, because it can't read from it. Instead of assuming an empty zip file, it miserably failed. Shame.

No more... Since version 2.2.5302, it will assume the zip file is empty. So code like this works perfectly:

    public void ProcessRequest(HttpContext context)
    {
      context.Response.ContentType = "application/zip";
      context.Response.AddHeader( "Content-Disposition", "attachment; filename=images.bmp" );
 
      ZipArchive archive = new ZipArchive( new StreamFile( context.Response.OutputStream ) );
      DiskFolder source = new DiskFolder( context.Request.MapPath( "." ) );
 
      source.CopyFilesTo( archive, false, false, "*.bmp" );
    }

The same problem appeared when trying to combine Xceed Zip for .NET with Xceed FTP for .NET, to upload zip files directly on the FTP server. Though the FtpClient class exposes a very useful GetUploadStream method to get a direct stream on the data connection, code like this previously failed.

          using( Stream upload = client.GetUploadStream( "images.zip" ) )
          {
            ZipArchive archive = new ZipArchive( new StreamFile( upload ) );
            DiskFolder source = new DiskFolder( @"d:\images\" );
 
            source.CopyFilesTo( archive, false, false, "*.bmp" );
          }

Talk about short and sweet uploads of zip files!


.NET | FileSystem | FTP | Zip

6/9/2005 2:56:43 PM (Eastern Daylight Time, UTC-04:00)  #   
 Thursday, May 19, 2005

Lately, people have been asking us how to abort a zipping operation with Xceed Zip for .NET. The official answer is "you can't", as there is no method or property exposed for this task, as opposed to Xceed Zip ActiveX with its simple Abort property. But the truth is you can, with relatively little coding.

Before we get into how to abort, let's talk a little bit about the ZipArchive's TempFolder property. By default, it points to the same folder as the static ZipArchive.DefaultTempFolder property, which itself points to the user's temp folder, as exposed by System.IO.Path.GetTempPath().

Though the library is designed to delete any file it creates in the temporary folder, this can occur only when instances get finalized if the operation failed in the middle of the process.

A good coding pattern I like to use is the following:

    ZipArchive zip = new ZipArchive( new DiskFile( @"d:\temp\backup.zip" ) );
    zip.TempFolder = zip.TempFolder.CreateFolder( Guid.NewGuid().ToString() );
 
    try
    {
      using( AutoBatchUpdate auto = new AutoBatchUpdate( zip ) )
      {
        DiskFolder source = new DiskFolder( @"d:\Data" );
        source.CopyTo( zip, true );
      }
    }
    finally
    {
      zip.TempFolder.Delete();
    }

This makes sure no temp file survive a zipping cycle. And with that pattern, I can set the "default" temporary location once using the static DefaultTempFolder property, and each instance will use a unique folder within this starting point.

Now that my zipping operations are cleaning their traces, we're ready to talk about aborting. Some key concepts:

  • The library isn't pumping messages, and does not offer async operations. If you want your WinForms application's "Abort" button to react, you will have to pump messages yourself somewhere.
  • There are three major operations behind the creation or modification of a zip file:
    • Compressing each new file.
    • Moving each file to keep from the original zip file (if updating an existing zip file).
    • Building the target zip file by appending data created by the above two steps.
  • Zip and FileSystem events get raised at many levels, so you should pass your ZipEvents instance everywhere an overload accepting a FileSystemEvents or ZipEvents instance exists.

Your "Abort" button (or any abort input you like) will simply raise a flag. It can't do more.

    private bool m_abort = false;
 
    private void AbortButton_Click(object sender, System.EventArgs e)
    {
      m_abort = true;
    }

Then you handle three events matching the forementioned three steps, pump messages to keep a responsive application, and check if the flag is raised. You can safely use the same method for handling the three events.

    private void CheckAbort_ByteProgression(object sender, ByteProgressionEventArgs e)
    {
      if( m_abort )
        throw new ApplicationException( "The user aborted the operation." );
 
      Application.DoEvents();
    }

As you can see, if the flag is raised, I'm throwing an ApplicationException. This will result in a System.Reflection.TargetInvocationException being thrown by the originally called method. To get a well-behaved application, you obviously want to trap any exception the FileSystem could throw. You can catch any TargetInvocationException to display an "operation aborted" message. Here's my code for the full operation:

    private void StartButton_Click(object sender, System.EventArgs e)
    {
      m_abort = false;
      StartButton.Enabled = false;
      AbortButton.Enabled = true;
 
      try
      {
        ZipEvents events = new ZipEvents();
 
        // Advise for the three main events for checking abort flag.
        events.ByteProgression += 
          new ByteProgressionEventHandler( CheckAbort_ByteProgression );
        events.GatheringZipContentByteProgression += 
          new GatheringZipContentByteProgressionEventHandler( CheckAbort_ByteProgression );
        events.BuildingZipByteProgression += 
          new BuildingZipByteProgressionEventHandler( CheckAbort_ByteProgression );
 
        // What's cool with delegates is that you can separate logic from UI.
        events.ByteProgression += 
          new ByteProgressionEventHandler( UpdateUI_ByteProgression );
 
        ZipArchive zip = new ZipArchive( 
          events, null, new DiskFile( @"d:\temp\backup.zip" ) );
 
        zip.TempFolder = zip.TempFolder.CreateFolder( Guid.NewGuid().ToString() );
 
        try
        {
          using( AutoBatchUpdate auto = new AutoBatchUpdate( zip, events, null ) )
          {
            DiskFolder source = new DiskFolder( @"d:\Data" );
            source.CopyTo( events, null, zip, true );
          }
        }
        finally
        {
          zip.TempFolder.Delete();
 
          // Clean up events.
          events.ByteProgression -= 
            new ByteProgressionEventHandler( CheckAbort_ByteProgression );
          events.GatheringZipContentByteProgression -= 
            new GatheringZipContentByteProgressionEventHandler( CheckAbort_ByteProgression );
          events.BuildingZipByteProgression -= 
            new BuildingZipByteProgressionEventHandler( CheckAbort_ByteProgression );
 
          events.ByteProgression -= 
            new ByteProgressionEventHandler( UpdateUI_ByteProgression );
        }
      }
      catch( System.Reflection.TargetInvocationException except )
      {
        MessageBox.Show( except.InnerException.Message, "Abort" );
      }
      catch( Exception except )
      {
        MessageBox.Show( except.Message, "Error" );
      }
      finally
      {
        AbortButton.Enabled = false;
        StartButton.Enabled = true;
        m_abort = false;
      }
    }

Things to notice:

  • I'm passing my "events" instance to:
    • The ZipArchive's ctor. You could handle the ReadingZipItemProgression events.
    • The AutoBatchUpdate ctor, which will in turn pass it to both BeginUpdate and EndUpdate. The later method will generate the GatheringZipContentByteProgression and BuildingZipByteProgression events.
    • The CopyTo method. It will generate the ByteProgression events.
  • I'm advising two times for the ByteProgression events, once for handling abort conditions, and another for updating my UI. This is a cool way to leverage delegates and separate the logic from the UI.

.NET | Zip

5/19/2005 4:53:12 PM (Eastern Daylight Time, UTC-04:00)  #   
 Wednesday, May 11, 2005

I thought I'd give the new Yahoo Music Engine a try, so I downloaded the setup and launched the installation.

First, it comes with the Yahoo Messenger 6.0, something I don't want on my machine. I don't need it, I don't want to try it, I don't want to polute my machine with. But the installer won't give me the choice not to install it. I decide to continue installation anyway. At worst, I'll uninstall it later.

A following step introduces me with the Privacy Policy. It informs me that the Yahoo Music Engine will "collect certain information about your usage of the Music Engine, and will transmit such information back to Yahoo!".

Hmmm, wait a minute, where's the checkbox to disable this? Can't? Oh boy... They're asking me something big here. Usually, I can say "no" and try anyway (WinAmp, Windows Media Player). At least, those other apps are giving me the impression I have control over what info is sent.

Let's read this more carefully before taking the plunge. So I click the Yahoo Privay Center link.

[...] Such information may include the following: version number; unique identifier numbers that allow us to distinguish between different computers and different people using the Music Engine, Yahoo! ID, duration of session time; number of times you download a song.

They can link a unique computer-based number with a Yahoo! ID? Hmmm, I don't feel comfortable with that.

[...] The Music Engine may send additional information to better understand your music preferences, personalize certain content, recommend music to purchase or listen to, allow you to rate songs, share playlists, and to automatically identify what CD is in your computer. Information sent may include the song playing, your playlists and what CD is in your drive.

That's getting too much. If it's only for a better experience, and that cannot be tied to any advertising, then write it out loud in the setup!

Yahoo is a serious company. I should trust them they won't use that info against my needs, right? So I continue reading, with the remaining intention to install the engine.

By default, your music profile is public. It includes a description of your musical tastes, your ratings, followers and influencers, and lists of similar members. It will also link to your LAUNCHcast radio station.

Ok, that's it, I'm out. I'm forced into something I'm not comfortable with. I understand that in order to improve the online music industry, one must sometimes impose things. But in this case, Yahoo have reached my own limits of what I can trust, and what I want control over. Will there be an option somewhere in the engine to turn everything off? Maybe. But first impressions are important. I'll wait.

Conclusion: If the intentions behind this collection of information is only meant to improve my experience with the Yahoo Music Engine, and that I can disable this later, then the setup application should mention it. Can't disable this while installing? Fine! Then regain my confidence with a clear statement that this is for my sole benefits.


Fun

5/11/2005 10:34:59 AM (Eastern Daylight Time, UTC-04:00)  #   
 Tuesday, May 03, 2005

Numbers can be very impressive. For example, FireFox recently hit the 50 million downloads mark. But what does that mean? How can we relate that number to the actual number of users? How do they count downloads?

Take me for example. I've installed FireFox both at home and work. So I count for two. But I've actually downloaded FireFox 8 times since its release, for every update there was (1.0, 1.0.1, 1.0.2 and 1.0.3), some through the automatic update, others from their web site. In any case, I'm sure both end-up being counted in that 50 million.

Jeremy has similar remarks concerning browser stats. Depending on the hosts, number of FireFox and IE users vary a lot. In some cases, the audience type explains it, but in other cases you just need to take numbers with a grain of salt.

Sure FireFox is gaining market shares. Sure FireFox has won me. I've also tried Opera 8, and it's a damn good browser, probably even better than FireFox, surely faster. But I can't stand the advertising banner, and why would I pay for no-ads Opera when I can find a free and almost as good alternative in FireFox?

I've paid for Trillian 1.0 Pro because at that time, there were no free runner-up. I've recently renewed for Trillian 3.x Pro because I just can't stand the ad banners in MSN Messenger, and didn't find something almost as good. Wrong. I did find a free alternative: Trillian Basic... but I couldn't live without a few features only in the pro version.

Tomorrow, I could convince myself I need Opera 8. Or IE 7 could win me back. By the way, I have downloaded Opera twice, to try it both at home and work. If one day they hit the 50 million downloads mark, you'll have to substract at least 2 from the actual number of users... Numbers are so volatile... Preferences are so fragile...



5/3/2005 10:59:17 AM (Eastern Daylight Time, UTC-04:00)  #   
 Friday, April 22, 2005

You already know the original picture shown on Coding4Fun raised within me some concerns I was already outdated, old, unplugged, not into "it" anymore.

Well, I'm thinking of launching a new portal called Coding4Work, where developers will feel more connected to the real thing. Instead of being welcomed by the "Tattoo Dude":

edited-poster-tattoodude.jpg

You will be welcomed by the "Busy Dude":

martin-tattoodude.jpg

Hmmm, that's much closer to my life, dude! ;-)


.NET | Fun

4/22/2005 3:48:17 PM (Eastern Daylight Time, UTC-04:00)  #   
 Tuesday, April 19, 2005

I just got bitten by the .NET Framework COM interrop. We had a problem with Xceed Zip ActiveX used in a .NET application. If the application was handling the ZipPreprocessingFile event and changed the sFilename parameter (BSTR*, or ByRef String if you wish), sometimes the library did not change the filename in the resulting zip file.

That "sometimes" was the mysterious part, though I had a good idea where the problem was. The method which fires the ZipPreprocessingFile event makes a dangerous, but up until now valid assumption. The kind of assumption that would make Raymond Chen or Don Box real mad. It took for granted that the BSTR address would change if the callee was to change the BSTR. I made this assumption based on two facts:

  1. A BSTR is an immutable entity. If you need to modify one, you should create a copy with the new content.
  2. If the implementation of a function that takes a BSTR reference parameter assigns a new BSTR to the parameter, it must free the previously referenced BSTR. (written "as is" in MSDN)

The .NET code that reproduces the problem does a very simple thing:

sFilename = sFilename & "new"

Normally, languages will work with the provided BSTR* as is. And if a modification occurs, they will allocate the required new BSTR, copy chars from the old BSTR, then free it. The new string cannot have the same address as the old one.

In .NET, the COM interrop is actually making a copy of the BSTR to create a System.String, work with that System.String throughout the function, then checks if the string changed before returning control to the COM caller, making either a call to SysReAllocString on the old BSTR, using the String as the "psz" parameter, or simply freeing the old BSTR, then allocate the new one based on the String.

Bam! Turns out SysReAllocString or SysAllocString sometimes reallocate the new BSTR at the same address as the old one. Can't argue against that. My bad.

Three things to conclude with that:

  1. You can never use what you experiment as a proof of concept. Experiments and tests are always a subset of the big picture.
  2. Don't try to make assumptions larger than the initial statement. Assuming that a pointer wouldn't change just because a BSTR* parameter must be freed if changed was stretching the actual fact.
  3. Optimizations may sound good, but can always introduce more problems. Simplicity is bliss.

By the way, I realized I could try a very simple VB6 test. If once the old BSTR is freed any new BSTR can end-up at the same address, does it mean that a VB6 application modifying the sFilename parameter twice can reproduce the same bug? Absolutely! My VB6 sample application did this in ZipPreprocessingFile:

sFilename = sFilename & ".foo"
sFilename = sFilename & ".bar"

Turns out files are sometimes renamed, sometimes not... Sometimes, I feel like an...


COM | Zip

4/19/2005 9:17:39 AM (Eastern Daylight Time, UTC-04:00)  #   
 Monday, April 18, 2005

Scott is inviting us on the MSDN Coding4Fun portal, with news and articles on many programming topics.

It's funny... or should I say perturbing... I'm welcomed by a young tattooed man wearing earphones, working on his laptop, peacefully in what appears to be his living room. The JPG filename is self-explanatory: "c4f-poster-tattoodude.jpg".

I don't have tattoos. I don't have a laptop, I wouldn't code on one if I could anyway. I'm not a "dude" anymore, if I ever was one. I listen to music while coding only to isolate myself of the ambient office noise. I'm a happily maried father who's day job is to develop software, and used to have time to "Code 4 Fun" in a distant era.

I'll be honest, I don't code for fun anymore. I'm having fun most of the time when I code, but I do it for work. I feel old and unplugged when I see "Dude" sites that tell me "programming is cool, man!".


.NET | Fun

4/18/2005 10:00:35 AM (Eastern Daylight Time, UTC-04:00)  #   

The .NET Compact Framework 2.0 beta 2 is out! But it won't run on my awesome state-of-the-art Jornada 545. :-(

Supported Device Operating Systems: Windows Mobile Software for Pocket PC 2003 Pocket PC, Microsoft® Windows Mobile™ version 5.0 for Pocket PC and Smartphone, and Windows CE .NET 5.0.

Ok, ok, I admit, I expected this! :-) My old Jornada is running Pocket PC 2000 (Windows CE 3.0 based), and has an astonishing 16 Mb of base storage to split with both storage and memory. Though I've installed the minimum in main storage, I have 7.5 Mb to work with when I boot. For example, I often can't open Windows Media Player and Word simulteneously, else I run out of memory.

Don't get me wrong, I love my PDA... But less than a few years ago. The battery is giving me less up-time than before, and more often than before I can't find software to run on Pocket PC 2000. I expected this to happen one day. My biggest frustration is I can't install a new OS. Can't brun the ROM. It will die with Pocket PC 2000.

But I'm a little surprise the new version of the .NET Compact Framework won't support Pocket PC 2002. Imagine if the regular .NET Framework was to only work on XP and 2003, but not on Windows 2000. People would scream! I thought the Windows CE 4.x market was big enough to justify supporting it. Oh well, I was wrong...

BTW, do you know where and when I bought my Jornada? At the Microsoft Store during my first Early Adopters .NET lab at Building 20. An impulsive decision at a time I didn't know I needed a PDA.



4/18/2005 9:25:31 AM (Eastern Daylight Time, UTC-04:00)  #