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.

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.

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...

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":

You will be welcomed by the "Busy Dude":

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

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...

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!".

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.

Just read Mitch's post: Is your general blogging? It's been some time now that I'm trying to convince my generals and colleagues to start blogging too. I feel somehow alone as the only Xceed member to blog. Moreover, I clearly don't have "all the picture" to share with you. It would be so great to see Odi and Dan open and share their experience as Xceed generals.

Odi Kosmatos

Odi is a geek (or greek, both apply)! When he gets interested in some technology, he'll read everything he can to master the subject. I needed winter tires for my car? I asked Odi. Pascal was curious about having a "music anywhere" house. He asked Odi. Odi could share so much on particular technologies using his own experiments and readings. What's even more interesting is that he gets really excited sharing his thoughts with us. Why not have fun blogging about them?

He's also deeply involved at Xceed with marketing, sales, web sites and next products/features decisions; he sure would have a lot of material for blogging.

Daniel Côté

His blog would be in French... or he wouldn't post enough. But I don't see why we couldn't blog in French too. Though Daniel earned the same computer science diploma as Odi and I, he has since concentrated his efforts on management, finances, and human resources. His blog would address the day to day experience of managing a software company and it's employes, dealing with decisions, relations, and the general image a serious company has to withstand.

Besides Xceed's generals, there are pillars at Xceed I would very much like to see blog.

Pascal Bourque

Friend, fellow lead developer and unofficial chief architect, Pascal is probably the person I'm the most eager to see blog. At the time he's reading this, he's probably mad I'm putting (yet again) more pressure on him blogging, but we would all benefit from the exercise, him first!

Let's make it clear: he's a master! Master at leveraging, quickly understanding and popularizing (is that a word?) any technology. And I mean any! He's amazing. He can quickly identify any technology that can get involved in a new product or feature, understand how it could be useful, and easily explain why. He's a very important part of Xceed's expertise.

Samy Kacem

Samy is our main webmaster. Speaking many languages and getting seriously involved in marketing, he has a clear and serious opinion on many worldwide subjects, and it's always a pleasure to discuss with him. And he's very funny, so his blog wouldn't be boring!

Many others here could also enrich the Xceed blogging community with their experience. I feel alone it that community. Help me convince them to join me!

Funny. When I saw the TopDesk post on Neowin, i told myself "Hmmm, looks nice, I should take a look at it one day", and I returned to my work.

This morning, I saw another TopDesk post, this time on ComputerZen. Scott is so impressed with TopDesk that he made a video capture of it in action. His demo and description sold me! I've installed TopDesk, and it's a great tool for only 10$.

It's not the first time Scott convinces me more than any onther people or article to try something. The power of blogging on small software companies is huge... and very important I realize! Maybe I can even try a conclusion: blogging is far more important for small companies than big companies.

Hint to the Otaku Software and Maxivista of this world: If someone named Scott Hanselman wants to buy your software, give him for free, it's a good investment.

Don pointed us to the Computerworld Development Survey, where we learn that developers use .NET and C# more than other frameworks and languages.

In the survey, you can read this:

What is your current position/job function?
IT manager	38%
Developer	36%
Non-developer IT staff	8%
Non-IT manager	5%
Other	13%

There are more IT managers than developers? What gives? Another table I had problems with is this one:

What is your current employment status?
Employed in organization with more than 100 employees	86%
Employed in organization with 100 or fewer employees	7%
Self-employed	6%
Not employed*	1%

Hmmm, that looks strange. I felt there were more smaller companies around. Then I read the end of the article:

Methodology
This study was conducted among subscribers to Computerworld.

Ok, now I understand. Surveys are biased by definition. You need the definition to understand them! My understanding is:

• Computerworld is read by IT managers, not developers.
• Big companies subscribe to Computerworld for their IT department. Small companies put their money elsewhere first.