The Moth

Read both the BlueJ side and a MSFT-employee view then make your own mind up. Personally, I thank BlueJ for the concept and I thank MSFT for borrowing everything that is good in the software industry and bringing it to my platform of choice.

SafeHandle

Enterprise Library background (via)

The endless debate: Custom Objects vs Datasets (check out all the comments and links too)

Human vs Computer (again, read the comments too!)

It has been 3 days since my return from paradise (a.k.a. Mauritius) and earlier this morning I think my mind returned as well :-D

On this glorious day here in England, we'll be spending the day in London with friends and specifically watching Shakespeare's Twelfth Night at Regent's park

I promise technical content will resume at some point in the future (along with some big news regarding my professional life)..!

My first holiday for 2005 starts right now. The last time we went on vacation was 2004 (Vegas and Nordic don't count... I am serious!).

In half an hour we are leaving for Heathrow to catch a flight to Mauritius (never been to the Indian Ocean before).

The big news is that I proposed to Jenny and she said... "YES" :-D
By the way, I am now the world's expert at choosing diamond engagement rings (it's all about cut, carats, clarity and color - set in platinum of course).

A couple of things I'll miss while I am away which I reccommend you don't:
1. Go to the *free* MEDC UK event (10 June)
2. Attend the MVP NETCF chat at 18:00 on June 14th

As a Pocket PC user and a NETCF 1.0 developer, you are familiar with the problem of showing different forms in the same application while preventing the user from navigating between forms from the "running list" (not to mention returning to the correct form after closing a sub-form). This was described previously here (look at the fourth entry: 4. Moving between applications)

So in NETCF 1.0, if you simply use ShowDialog to display another form:
a) The new form (specifically its caption/text) appears in the "running programs list"
b) The original form also appears in the list, which means you can navigate to it (although it appears disabled once activated)
c) There is potential for closing the second form and returning to another window on the PPC (the original form has moved back in the z-order)

With CF 2.0 you can use the new Owner property of the Form and hence get rid of every problem from the above list. Do not confuse the Owner property with the Parent property, which is inherited from Control and is not intended to be used with forms

Run the following snippet (assume it is in the button click event handler of Form1 in VS2005 NETCF 2.0 project):

Dim f As New Form2()
f.Owner = Me
f.ShowDialog()

...you'll notice that only one entry for your application exists in the running list. The only potentially strange thing is that it has the caption of the first form (while the body of the form is clearly that of Form2)! This is easily rectified with the following modification (this time in C#):

Form2 f = new Form2();
f.Owner = this;
string s = this.Text; //make a copy of the original caption
this.Text = f.Text; //set our caption to the form we are about to show
f.ShowDialog();
this.Text = s; //restore the original caption once the second form is closed

Although I would have preferred the original snippet to exhibit the behaviour of the second snippet, still we must agree that this is a step forward from NETCF 1.0!

As you know, in VB variables do not need to be initialised, as they always get the default value for the variable type in question, e.g.
Dim b As Boolean 'b is already initialised to False

In C-based languages (inc. C#) this does not apply; you must initialise the variable before you use it, e.g.
bool b = false;

The above is the reason we cannot have ByOut in VB (only ByVal and ByRef) whereas C# has both ref and out (ByVal is implied by omission).

I have seen VB code that follows the C-style and there are two common reasons for doing so; one is to be explicit and the other is because of a C-based upbringing. The question is what IL will the VB compiler generate, faced with code that differs only by explicit assignment (we know it is pretty crap at optimising the simplest of scenarios, so we don't go in with our hopes high).

Given these two methods (and assuming a private method GetNumber):

    Public Sub VBStyle()
        Dim i As Int32
        i = GetANumber()
    End Sub

    Public Sub CsStyle()
        Dim i As Int32 = 0
        i = GetANumber()
    End Sub

I can tell you that the VB compiler generates slower code for the second scenario (I have to say if you have a bottleneck in your project, cases like this will not be it, but it is still good to know :-).

Here is the corresponding IL:

.method public instance void  VBStyle() cil managed
{
  // Code size       8 (0x8)
  .maxstack  1
  .locals init ([0] int32 i)
  IL_0000:  ldarg.0
  IL_0001:  callvirt   instance int32 VBWinApp.Class3::GetANumber()
  IL_0006:  stloc.0
  IL_0007:  ret
} // end of method Class3::VBStyle

.method public instance void  CsStyle() cil managed
{
  // Code size       10 (0xa)
  .maxstack  1
  .locals init ([0] int32 i)
  IL_0000:  ldc.i4.0
  IL_0001:  stloc.0
  IL_0002:  ldarg.0
  IL_0003:  callvirt   instance int32 VBWinApp.Class3::GetANumber()
  IL_0008:  stloc.0
  IL_0009:  ret
} // end of method Class3::CsStyle

Needless to say that the C# version closely reflects the first version (it is even better, since it uses a call rather than a callvirt - but that is a different story...).

It's a known fact that while the VB compiler team focuses on VB6 compatibility, the C# compiler team focuses on optimisation (funny that, for a compiler team); so I was not surprised with this.

Robert points to updates on the Windows Mobile Migration FAQ for developers

I echo *every* single sentence on this post on signing in VS2005

Looking at the number of comments, you don't need me to tell you about it but... here is some info on tabbed browsing implementation in IE7

Microsoft's view on modelling makes an interesting read, e.g. "What about UML" (via)

Funny and so true (I have used at least half of them in the past :-)

Do not expect anything on this blog (or any online activity, emails etc) for the next week.

In about 25 minutes I am leaving for a business trip to the most Northern parts of Europe. In 5 days we endeavour to visit 4 countries (Denmark, Sweden, Finland and Norway) and more specifically 9 sites (5 immediate customers and 4 end users).

… just as I was recovering from the Vegas jetlag…

Expect this technique to be used extensively with NETCF 2.0. Sure there was an easy workaround for obtaining the Handle, but pinvoking APIs with callbacks was impossible (without a native helper dll) since DllImport in CF 1.0 does not support delegates in the signature. Enjoy Subclassing controls in CF 2.0

I know I will be referring to these steps for removing SS from VS projects

Now I'll never forget the OSI layers "Please Do Not Throw Salami Pizza Away" (via)

Now that NETCF 2.0 supports COM Interop (for CF 1.0 your best bet is 3rd party support), there is a FAQ emerging.

Q: I have a native/C++ exe/process and cannot get it to talk to my managed/C#/VB dll/class library. What's wrong?
A: As indicated last year, this is not supported.

To help Google get you here, I will use various phraseologies that all indicate the same thing.

You can call native COM components from managed code, as long as it is from a managed exe - VS will generate the RCW (Remote Callable Wraper) for you. Once you have activated native COM objects from managed code, they can call you back; so in that sense - and that sense only - CCW (COM Callable Wrappers) are supported.

You cannot activate (or register) managed objects through COM. Regasm.exe that the full framework supports is not available. Forget doing a CoCreate on your managed objects.

If you think about the last statement it makes sense, since runtime hosting of the NETCF CLR is not supported; how could you start a native process that "talked" to a managed library (dll)?

Incidentally, if you must communicate from native code to managed code and since you cannot do that in the same process, consider one of the IPC mechanisms available on WinCE.

While we are on the subject of NETCF 2.0 COM Interop limitations, allow me to quote from one of Richard Greenberg's slides from MEDC:
"Only MTAs (multi-threaded apartments) are supported and there are no custom marshalers or auto-generated Class Interfaces."

With Visual studio 2005 the contents structure of Solution Explorer has changed. Even with VS2003 I always had the "Project->Show All Files" option turned on but with VS2005 it is essential (by default, they hide more than what they show!).

The main change is that under each project there is a folder (just above "References"). Amongst other things it contains the AssemblyInfo file (that previously was with all the other files). If you open the project properties and go to the "Application" tab you'll find a button called "Assembly Information" that brings up a dialog showing the AssemblyInfo values. If for whatever reason you’d prefer the AssemblyInfo file to live with the other code files, then simply drag it out; the project properties will still find it :-)

Under the same folder you'll find a Resources.resx file (and its dependent Resources.Designer). Again, you can manipulate this via the project properties and specifically the "Resources" tab. It is these files that enable My.Resources (and the Resources class in C#) wrapping the System.Resources.ResourceManager. If for whatever reason you’d rather not have these files, then right click on them and delete them (you can always regenerate them via the project properties “Resources” tab).

All of the above is applicable to projects targeting PC or devices and is true for both VB and C#. Of course, keeping the name of the folder the same for both languages would be sacrilege so in VB it is called "My Project" and in C# it is called "Properties".

Furthermore, only for desktop projects (you didn't think we'd have it all in the Compact Framework did you?), the folder also contains Settings.settings (and its dependent Settings.Designer) files. As you guessed, these enable the editing of settings in the project properties based on an auto-generated Settings (My.Settings in VB) class that inherits from System.Configuration.ApplicationSettingsBase). If for whatever reason you’d rather not have these files, then right click on them and delete them (you can always regenerate them via the project properties “Settings” tab).

Finally, only for VB desktop projects, the "My Project" directory contains the files: Application.myapp, Application.Designer.vb and ApplicationEvents.vb. These are responsible for the new startup model and application level events, which we looked at in the Beta 1 timeframe (it has changed slightly but the majority is identical and the changes are mostly cosmetic e.g. the option is now called "Enable Application Framework" rather than "Startup with custom Sub Main"). If you don’t want the ApplicationEvents.vb file, then simply delete it (you can always regenerate it via the button “View Application Events” under the Project->Properties Application tab). Whatever you do, *do not* delete the other two vb files; with Beta 2 at least, nasty things can happen (things that force you to use Task Manager -> End Task)! Having just said that, those two files are also present in Class Library projects even though the relevant project properties areas are disabled (!). In the class library case it seems safe to delete them.