The Moth

I have it from a good source that Whidbey will ship in May. I was as surprised as you are when I found out and a part of me thinks they meant 2006, but the context of the conversation was 2005, so make of it what you will.

Expect more inside MSFT information now that they offered me a job. I wouldn't accept it but, since my company is being taken over by some other company, I thought it was a good time to move. It is not on the CF team as you'd expect, though. Instead the C# team has hired me with my first task being implementing a background compiler for the Orcas release. Stay tuned.

On the Compact Framework front, you will have heard by now that sanity has prevailed and CF 2.0 will be supported on WinCE 4.2 (woohoo)

Finally, a blog entry without a link is not a blog entry so, as well as posting this over at my "meme" blog, see below who you are messing with:


Oh, I almost forgot: the MSDN Universal price tag will increase by £500 but it will include Visual Studio Team System Suite!

We know the February CTP contains older device bits than the November CTP, but since the DVD arrived through my letter box I thought I'd install it (yes I have better things to do but I was curious alright :-)

My goal was to find 5 things I didn't know about (not necessarily new in this CTP) *and* they should not be CF-specific.

1. PropertyGrid control. I hadn't noticed that this is now part of the default toolbox for winforms. BTW, if you want to use it today with VS2003, see this.

2. Object Test Bench for VB :-) They told me they would not do it. If you've got the Feb CTP, go play with it (e.g. follow the C# steps described here).

3. This has been true since Whidbey went public, but I only just noticed it. If in a C# project (or with VS not having any project loaded), you open a VB file, its regions are recognised :-) [This always pi**es me off with VS2003]. A related nice option is "Tools-Options-Text Editor-File Extension"

4. You know about partial classes. Well, VB still doesn't show us the constructor in the file we edit by default (like C# does) :-(

5. Select the menu "Class Diagram-Display Types". I guess this is a tiny step closer to having method signatures but until that happens... Anyway, there are other reasons to moan about once you observe how this is implemented in C# as opposed to VB. The way I see it, this is another blow for VB developers.

"You cannot cope with UML notation for return types, which is simply replacing 'As' with ':' *but* C# developers are perfectly capable even though the change is larger (moving the return type from the front of the method name to the back and precede it with a colon)."

As a UML shop through and through, this is yet another reason for us not to use the Class Designer (or to ditch VB for any new projects).

One of the missing methods from NETCF 1.0 today is Thread.IsBackground.

CF 2.0 will support this method with a few noteworthy caveats. Read carefully Brian Smith's contributions in this thread.

* In protest to the pricing model of Team System, no msft blog will be linked from this week's BLOTW. The pricing model is widely discussed in the blogosphere, but I find the quote at the end of this entry covers my thoughts:

"Congratulations to the development teams bringing these products to us. We're glad that you've been listening. Now go kick down the doors of the marketing people and blast them for wasting your time."

* On Monday, Roger asked in the wince.app.dev ng if people would be interested in styled controls; I directed him to the cf ng, where he got positive feedback. Here is the result.

* Seems I have to brush up on my UML, as there is a diagram in v2.0 I was not aware of

* In the past I run an internal "Advanced .NET Basics" session (covering the topics on this list). This full day tutorial seems to cover similar ground and all material is available for download.

* Don't throw from finally

So you have experience developing .NET Compact Framework applications targeting your Pocket PC (2000/2002 or WM2003) or even custom Windows CE devices. Now you want to dabble with SmartPhone 2003 development, since CF supports that too (but not SP2002). Where do you start?

The first thing to do is install the SmartPhone SDK. This will give you a new Smart Device Project type and an emulator of course (you may also get the Second Edition Emulator. Usually you choose the Pocket PC platform, now you should choose Smartphone (the only omission from the "project type" list is the "Non-graphical Application", a.k.a. "Console Application" on the Windows CE platform).

So the new project is created. The first thing you note is that the form is small (182w x 239h). In reality, the area you can manipulate is 176x180 pixels since you'll have a border, title bar and menu area. The menu area is actually the space for two soft keys (more on those in a moment). The second limitation we observe is the toolbox; device controls are already much fewer than the desktop, but they are further halved in numbers for Smartphone projects [VS2003 toolbox][VS2005 toolbox]. Later, I'll say a couple of words for some of the 14 controls (datagrid doesn't work) we have at our disposal.

At this point, it is worth stating the obvious: the SP has no touch screen and all interaction is via hardware buttons. The emulator [vs2003][whidbey] gives us some clues. Let's have a closer look at the buttons moving from the top downwards:

There are 3 sections:
1. LCD area
-Two button directly below the screen (a.k.a. soft keys).

2. Middle/center of the phone
-Two phone keys. Green for call and red for hungup.
-Below the call button there is a "home" button.
-Below the hungup button is a "Back" button.
-Between the 4 buttons just described is the rocker [Left, Right, Top, Down and Enter/Action]

3. Lower end of the phone
-Typical 12-button keypad found on all phones

In theory you could hook into any of these buttons and do whatever you want, but it makes sense to remember that the device's primary use is as a phone and also that MSFT has some guidelines for SP applications (some of which are enforced by the CF at runtime). For example the 12-button keypad can be used only for data entry (e.g. on a textbox); the call/hungup buttons (with the green & red phone icons) should be left alone, as should the home button (house icon). The back button navigates to the previous form (or to the previous application, if you are on the main form).

So let's look at the remainder buttons in correlation to the CF controls.

+ The following controls have no user interaction (other than displaying info, of course):
Label, Panel, PictureBox, ProgressBar, Timer, ImageList, VScrollBar, HScrollBar

+ The following 3 controls should be the only control on a single line (other than non-interactive controls mentioned above, of course):

- CheckBox
Up/Down move to the previous/next control on the form. Left/Right/Enter toggle the state.

- ComboBox
Up/Down move to the previous/next control on the form. Left/Right navigate through items in the combobox list. Enter brings up a full screen list of the items for selecting by scrolling with Up/Down.

- TextBox
Up/Down move to the previous/next control on the form. Left/Right moves the caret in the textbox. The Back button erases a character. If the textbox is Multiline=true, Enter brings up a full screen textbox (with scrollbars, if needed):

+ The following two controls must be the only (interactive) control on the form (there is no automatic way for them to pass focus to another control):
- ListView
Up/Down moves through the listview items. Left/Right scrolls horizontally, if there is a scrollbar visible. Enter generates the ItemActivate event.

- TreeView (must be the *only* control on the form)
Up/Down moves through the visible treenode items. Left/Right scrolls horizontally, if there is a scrollbar visible. Enter expands/collapses a treenode.

+ Given the absence of buttons, the two soft keys are the main mechanism of performing actions. The following control is how we drive the two soft keys:
- MainMenu
When placed on a form, the two buttons directly under the screen become applicable. The mainmenu can only have two top-level menuitems, the Text of which is rendered on the screen buttons. The left root menuitem cannot have any child menuitems of its own and thus acts more like a button. The right root menu can have menuitems and hence may function as the normal menus we are accustomed to.

It is always good to cut code in order to understand a new platform, but I suggest you familiarise yourself with the platform philosophy before embarking on a project. Even if you are an experienced PPC developer, Smartphone is a new platform (in terms of UI - you can always use existing CF dlls without recompilation). I hope the above serves as a basis for understanding the philosophy and approach you should take for Smartphone development.

Other useful links for the newbie Smartphone developer:
Keys, menus, faq, msdn article, sp with cf primer, smartphone developer ng

In the previous entry we identified how CF 2.0 does not support RTL on CE 5.0. We also defined what RTL support means.

Like with most features that CF does not support, we can work around this one with a bit of pinvoke. By reading this page on MSDN (thanks Chris Lorton) we see that, if we pinvoke SetWindowLong passing it the Control.Handle, we can change the RTL style.

In VS2005, to test if the above works, we populate a form with all the CF 2.0 controls and run the following method (e.g. call it from a button/menu click):

// Call this method with this.ChangeToRTL(this)
private void ChangeToRTL(Control c) {
    this.ApplyStyle(c);
    foreach (Control c2 in c.Controls) {
 this.ChangeToRTL(c2);
    }
}

private void ApplyStyle(Control c) {
    Int32 lS = GetWindowLong(c.Handle, GWL_EXSTYLE);
    lS |= WS_EX_LAYOUTRTL;
    SetWindowLong(c.Handle, GWL_EXSTYLE, lS);

    c.Invalidate();
}

To test the results you need a CE 5.0 device (or simply get the CE 5.0 emulator as described here).

I have given you enough to run the test and check the results for yourselves, but here is my summary (lookout for screenshots at the end):

1. The following controls pass the test and meet the criteria as defined previously:
button, label, textbox, checkbox, radiobutton, progress bar, v/h scrollbar, form, tabcontrol, datetimepicker, monthview, toolbar, statusbar, listbox

2. The following fail
domainupdown, numericupdown - text part right aligns but buttons remain on the right

trackbar - shade issue (need to change value for effect to take place; refresh is not good enough)

treeview - When ShowLines=true, the lines are portrayed the wrong way round

listview - columns do not right-align (they are not affected at all by the style-change)
listview - resizing a column looks funny. You drag to the right but the listviewitems below move to the left and vice-versa

MainMenu - The top mainmenu items do not change order, although they are aligned to the right (and correctly after the toolbar) menus - when clicking on toolbarbutton with a menu OR a mainmenu to bring down its menuitems, the menuitems appear to the left of the mainmenu/toolbarbutton.

combobox - It appears ok RTL *but* clicking on the dropdown button results in the list appearing but the main combo area disappearing. Clicking elsewhere to take away the focus results in the combobox being drawn to the left (it moves left exactly its width in pixels). Repeating the process eventually moves the combobox outside the form area on the left (kind of funny, really).

3. Vertical Scrollbar issue [treeview, listview, listbox, multiline textbox etc]
Regardless of what is described above, all controls that can have a vertical scrollbar work only if the style is applied *prior* to a vertical scrollbar being displayed. If the vscrollbar is visible and the RTL style is changed, then the vscrollbar stops responding (freezes) and remains on the right.

Screenshots:
Good RTL
Not so good RTL
Bad RTL
Menu RTL

If you have a CE 5.0 device with CF 2.0 on it, feel free to try the exe (in fact, if from IE on your CE 5.0 device you browse to this link, you can run it)

+ If you think there is a scientific way classes are assigned to namespaces, think again.

+ I have thought about this before and, without going into details, I fundamentally disagree with the notion of "contextual keywords".

+ On the one hand I am not impressed with 35 blog entries in 2 days because I am not sure it is right to put such useful content into blogs rather than the traditional MSDN help (and MSFT do the former more and more). On the other hand, have you any idea how long we would be waiting had they taken this information through the stringent MSDN article submission process?

+ I have been bitten by this in the past, so follow the advice.

+ This neat little feature hasn't had as much exposure as it should IMO: incremental searching.

+ We will need this feature for an upcoming project, so I am bookmarking some info/links here on hosting the designer.

+ At some point I will blog about the process I followed when upgrading our VB6 system to .NET and then to CF. Until then, I'd keep my eye on Mike McIntyre’s blog (45 upgraded VB6 projects is a few dozen more than what I have done!)

In some places in the world they read and write from right to left (RTL). Prime examples of such languages are hebrew and arabic. As a software developer, if your market extends to such users, you should support RTL in your application. Unlike support for a LTR language, there are additional things your windows app must do. For .NET apps this includes using the Control.RightToLeft property.

For the Compact Framework the story is less straightforward. You see, the CF is a subset of the .NET Framework that runs on Windows CE based devices. Windows CE 4.x and previous versions do not support RTL (since all current Pocket PC devices are based on the CE 3.x/4.2 operating system, by definition they do not support RTL either). There may be 3rd party solutions available, but I am not aware of any. It would be a nice touch if the CF implemented RTL support without support from the OS (i.e. it could simulate it) however that would probably mean that the windows controls would not be just thin wrappers of the OS equivalent and hence performance would suffer - not to mention framework size.

The OS story becomes much better with the next version of Windows CE. In a sentence, CE 5.0 supports RTL :-)

For devs with their own platform this means migrating from 4.2 to 5.0. (for devs of PPCs [Windows Mobile for Pocket PC] or SPs [Windows Mobile for SmartPhone], my *guess* is you have to wait for a next version of Windows Mobile which if based on CE 5.0 could expose the underlying OS support).

Since CE 5.0 supports RTL and since Compact Framework 2.0 *only* runs on CE 5.0 (and WM2003 for PPC), I'd forgive you for making the logical jump that CF 2.0 exposes Control.RightToLeft - think again. That's right, the infamous "postponed"!

Before we go off in a sulk, it is worth capturing what we mean by RTL support:

1. CheckBoxes (the square bit) and RadioButtons (the circle bit) should appear on the left [there is no CheckAlign property on CF]
2. UpDown buttons (e.g. NumericUpDown and DomainUpDown) should appear on left
3. Controls with vertical scrollbar (e.g. TreeView, ListView, ListBox, multiline TextBox etc) should render the scrollbar on the left
4. Wherever there is text that is naturally left-aligned, it should be right-aligned (e.g. *any* control with .Text property such as Form or .Items such as ListView)
5. Menus, ToolBar buttons and form buttons (i.e. max/min/close buttons, control box) must be mirrored (right aligned)
6. ProgressBar, TrackBar and HScrollBar should start from right.
and a more subtle one
7. Shadows of controls should appear on the left. If you haven't noticed this before, have a closer look at button/scrollbar/trackbar etc: they have a white border top & left and dark border bottom & right. The left & right shades must be switched when RTL applies.

Next time we'll see what we can do with CF 2.0 to support RTL on CE 5.0. I'll include screenshots and details of which controls (based on the November CTP) pose insurmountable problems!

On his blog, as part of a useful OOP series, Raymond Lewallen defines polymorphism. He merges 3 concepts in one post. We've had the discussion on the topic previously, but I don't think we reached total agreement. In my opinion, to say that there is such a thing as "true" polymorphism and to claim that it applies only when inheritance is involved, is plain wrong.

If you are reading that blog entry to understand polymorphism, please read my (complementary) take on the topic below.

First I would ignore overloading. This has nothing to do with polymorphism and I would not bring it up in any discussions on the topic. Just for info, overloading is the ability to define two or more methods on the same class with the same name but different argument lists. Nothing more, nothing less.

Second, do not directly associate polymorphism with inheritance (as you can probably tell this is my pet peeve :-). Polymorphism directly depends on subtyping. Unfortunately, many people confuse subtyping with implementation inheritance. Inheritance is *a* way to achieve subtyping, but not the only one (another is interface implementation). If you ask the question in reverse: Is inheritance the same as polymorphism? The answer is no. Inheritance offers a way to achieve subtyping *and* a way to reuse code.

So if someone asks you to explain polymorphism with a VB.NET example using inheritance, you can do something simple like this:

Public Class EntryPoint
    Shared Sub Main()
        Dim m As New Mouse
        Dim s As New Shark
        DoSomethingWith(m)
        DoSomethingWith(s)
    End Sub

    ' Client code
    Public Shared Sub DoSomethingWith(ByVal a As Animal)
        a.Bite()
    End Sub
End Class

Public MustInherit Class Animal
    Public MustOverride Sub Bite()
End Class

Public Class Mouse
    Inherits Animal

    Public Overrides Sub Bite()
        MsgBox("Disease")
    End Sub
End Class

Public Class Shark
    Inherits Animal

    Public Overrides Sub Bite()
        MsgBox("ouch!")
    End Sub
End Class

The client code uses the type Animal. It does not know what objects it will be given (i.e. instances of what class) but the fact that they support the programmatic interface of the Animal type is enough for it to use them: polymorphism in action.

If someone asks you to explain polymorphism with a VB6 example, you can do something like this:
In a Standard EXE project, change the startup Object in project properties to Sub Main.

Add a module1 with this code:

Sub Main()
    Dim m As New Mouse
    Dim s As New Shark
    DoSomethingWith m
    DoSomethingWith s
End Sub

' Client code
Sub DoSomethingWith(ByVal a As Animal)
    a.Bite
End Sub

Add a Animal class module:

Public Sub Bite()
End Sub

Add a Mouse class module:

Implements Animal
Private Sub Animal_Bite()
    MsgBox "Disease"
End Sub

Add a Shark class module:

Implements Animal
Private Sub Animal_Bite()
    MsgBox "ouch!"
End Sub

That's it. Polymorphism in VB6: nothing fake or incomplete about it.

Naturally you can mix many concepts in your designs including polymorphism, inheritance and overloading etc. If you want to see a design combining these topics, then Raymond's post has a nice VB.NET example.

I have returned from another round of customer visits (in the Midlands this time). Lots of positive feedback on IQView and great ideas contributing to our current plans for a new product (can't say much more on that, apart from that it is also on WinCE with CF). In terms of generic shareable takeaways, everything I said last time was re-enforced on this visit too. A couple more:

7. You can learn as much by listening to your client talk about competitive products as you can from when they talk about yours; encourage it!

8. If you are already the UK's market leader, maybe you should try to obtain feedback from other countries [OK, so this is more of a hint to my manager to send me to our customers abroad :-]

Now back to catching up with my spam... later...

+ Declarative validation with attributes and Java annotations by ex-Avanade Steve Maine.

+ Assuming this has no irony/sarcasm and without belittling anybody, with a dead-straight face I wholeheartedly agree with this (the alternative is to steer VB.NET to cater for this overlooked group; as a .NET dev do you want that?)

+ Never realised comment spam has good side :-)

Helping out in the newsgroups but also as someone that got a lot of support from them in my earlier days, I thought it would be interesting to classify the "types" of posts in a newsgroup (ng) that may rub some people the wrong way (myself included). Note that in the past, I have broken many of these rules myself :-)

So here are my suggestions (in random order):

1. ALL CAPITALS
Capitals are interpreted as shouting so post in capitals if you want to start an argument rather than get help.

2. WRONG NG
Before posting to an ng, it makes sense to check if your question applies to it - otherwise you are just wasting bandwidth.

3. GENERIC QUESTIONS DON'T BELONG TO SPECIFIC NGs
Just because you are hanging out in the aspnet newsgroup doesn't mean you should start asking about the difference between value types and reference types. It is a .NET question but it is not specific to the technology ng. Same goes e.g. into asking about differences between C# and VB in the winforms ng: both are dotnet languages but that doesn't mean you can post them anywhere.

4. READ THE FAQ
So obvious, but so rarely adhered to. I think there is a problem with the technology we are using. There should be a method to detect when a new user posts to an ng and send them the FAQ with a 30 minute delay before they can actually post a question. BTW, for CF look here.

5. AT LEAST READ THE DAY'S POSTS
Follows on from “Read the FAQ”, but guess what you look like when your exact question was asked and answered a few hours ago.

6. BASHING MSFT BEFORE ASKING THE QUESTION DOESN'T HELP
Opening your post with insults to Microsoft and the way they support developers (e.g. documentation) is not helping your cause (to get support). The experts helping out are obviously happy with the platform, so you are insulting their choice. Even when you are right with your accusations, do you think that others are not aware of them? That is why the ng is there: Ask your question without the rant.

7. IF YOU ARE GOING TO POST, HAVE A QUESTION
Describing a problem is fine, but do try to end your post by formulating some kind of question.

8. YOU DON'T KNOW IF YOU FOUND A BUG
Just stating that you found a bug will not get you many replies. Do you really think you are the first one to report the bug? If yes then fine, you have reported it and don't expect any replies. If on the other hand you would like some help to work around it or validate that it is a bug, state your problem with repro steps and ask for help (note how that does not include proclaiming that you found a bug).

9. SHOW ME THE CODE
This is probably the number one omission. Imagine if I send you an email telling you I have a problem when e.g. calling a WS but don't show you any code; kind of daft, right? Show me the code so I can repro your problem and show you what is wrong or how to change it to make it right.

10. TELL ME SOMETHING ABOUT YOUR ENVIRONMENT
Which version are you running (SP1, SP2 etc)? E.g. you have a problem running some code on your device but not the emulator. What device/emulator (PPC 2000/2002/2003, WinCE 4.1/4.2/5.0 etc)? E.g. you'd like a code sample that does xyz. What language are you using (VB/C#/C etc)?

11. DOT NET IS A MULTI-LANGUAGE PLATFORM. DEAL WITH IT.
Do not finish off your post with "code in VB only". If the help is given in C#, translate it with one of the many online converters or use it in a class library. If you are having trouble translating it, post back including the specific line you are having trouble with. If you prefer to see it in VB, state at the beginning what language you are using (it will be used as a hint but not as a constraint).

12. WHEN YOU POST CODE, INCLUDE THE EFFECT YOU ARE SEEING
"Here is my code. It doesn't work". What doesn't work? Does it not compile (what is the compilation error on what line?), does it throw an exception at runtime (what exception on what line)? Learn to at least use breakpoints and step into to locate the offending line!

13. "URGENT, URGENT, PLEASE HELP" or "REPLY SOON, I AM WAITING"
Everybody that posts to the ng requires help urgently. Marking your message as such will only piss off some experts, thus you get less attention. Don't do it. Don't cry for help; the fact that you posted a question is a big clue that you are after help.

14. DO NOT MULTI-POST
Posting the same question separately to every ng you think it applies to, is real bad manners. Most experts hung out in more than one ng, so they have to read your post multiple times. Imagine if you posted the same question to one ng multiple times; isn't that stupid? That is exactly what multi-posting does. If you think that you *must* target multiple ngs, please cross-post (include the ngs in the “to” field - if your newsreader doesn't support that then change newsreaders).

15. DON'T ASK ME TO DO YOUR PROJECT
"How do I pass parameters from one thread to another" is OK. "Post a sample that animates a little person on the screen collecting coins while avoiding aliens" is not OK.

16. DO NOT ASK UNRELATED QUESTIONS IN ONE GO
Do not gather up your questions in one post. You may have encountered these 5 problems in the last hour, but posting them in one message will not get them answered. Think about it: Unless someone has the best answer to all of them, they are not going to help (had you split them into many posts, some would get answered). Worst, someone replies with answers to some questions (but not all). Given that the post has had a reply, others may not look at the thread so your unanswered questions get ignored. Also, posting many unrelated questions invariably breaks the following rule.

17. CHOOSE A GOOD SUBJECT
Not everybody reads all the posts in the ng. Besides, an expert may get a couple of minutes at lunchtime to scan the group for a few easy questions to address. Guess what they are scanning. You got it: the subject. Subjects such as ".NET" or "TabControl" or "Exception" or "[no subject]" are ignored.

18. THE SUBJECT IS NOT A SUBSTITUTE FOR THE BODY
Sticking your question in the subject and leaving the body empty is not clever. Not repeating any info of the subject (or referring to it) is not clever either. Choose an appropriate subject and then, when you write the actual message, forget what you wrote in the subject: (re)describe the full problem.

19. DO NOT CHANGE THE SUBJECT FIELD
You are participating in a thread of discussion and mid way through you change the subject - please don't! If you want to say "thank you" or "solved" say it in the body; don't change the subject text. Without going into details, this causes problems to some newsreaders (when they are used in a certain way).

20. NEW QUESTIONS GO INTO THEIR OWN NEW THREADS
This is a bit like the multiple unrelated questions in one post. You've started a thread, you got your problem solved and now you have a new problem. Don't insist that the kind person that just helped you should now address your new issue! Start a new thread.

21. EXCLAMATION MARKS
Exclamation marks, smileys etc have their place in newsgroups. I have no problems with them and use them myself but please don't end *every* single sentence that you *ever* wrote on *every* post with 3 exclamation marks!!! [ true story]

22. Last but by no means least: DON’T REPLY TO ME
Replying in the ng is fine. Replying to me personally is not – please don’t. (Comments on my blog entries are always welcome of course)

For more… just search!

Over the last two days we spent time visiting client sites around the country and obtaining feedback on our current products & future thoughts. As much as I was not ecstatic to be offline for two days, I can't stress how important these kinds of events are to a developer. If you have the opportunity to go meet the end users of your magnificent creations, then go do it now. It is invaluable!

I could bore you stiff with the specifics discussed, but I won't. Instead, here are some general thoughts which I think apply to most products.

1. How do you please both the savvy and the newbie? The one that explicitly asks for XML export and the one that says this is the first touch screen device they ever came across!

2. It is hard to draw a line of where the features of one product end and another's begin. What's the point of offering features that drive sales up on this but cut sales from that - dropping the overall profit!

3. Should we abandon PCs and do everything in embedded devices (WinCE, not XPe) or should we dumb them down and have them slaves to PC applications? Everybody can be persuaded one way or the other; the devil's advocate always wins!

4. When you replace an older product, you better make sure *all* features of the original are carried over. There is no feature that "nobody ever used that, it was just there"!

5. Do users understand that this response is bad for my job security: "I love it; it does everything I want; don't change it".

6. Are shortcuts (i.e. having more than one way to do a task) good or bad?

While I ponder on the above (along with 4 A4 pages of notes), please bear with me for any unanswered emails; I will slowly catch up with 5 email accounts and hundreds of blogs, not to mention the newsgroups... hopefully before the next round of customer visits next week.

- My favorite blog entries are those that cover a topic from A to Z. Another attribute I look for is content that has not been published before. Naturally, stuff like that comes once in a blue moon; on Wednesday the moon must have been blue on Peter Foot's blog.

- Layout in WinForms.

- Windows CE History (via droppings)

Here is another question that appears in various guises.
"Event X from control Y gets fired twice" or "I want to stop this event from firing while I am waiting for Z"

For example assume that you do stuff in the event handler of the selectedindexchanged event of a list; you now need to select an item in a list programmatically but do not want to run your event handling in that case (only when it is done by the user). Here is a simple example:

Given a form with a listbox and a button let's assume your event handler looks something like this:

Private Sub ListBox1_SelectedIndexChanged(ByVal sender As System.Object, _
 ByVal e As System.EventArgs) Handles ListBox1.SelectedIndexChanged
    MessageBox.Show(ListBox1.SelectedItem.ToString())
End Sub

And let's assume as part of a button click you are doing something like this:

Private Sub Button1_Click(ByVal sender As System.Object, _
 ByVal e As System.EventArgs) Handles Button1.Click
    ListBox1.SelectedIndex = 0
End Sub

When you click the button you don't want to see a messagebox.

As you'd expect the solution is simple:
1) Use a boolean flag and check it in your event before processing
or
2) Dynamically remove the event handler

1) Define a boolean in your form code like this:

Private mDontRun As Boolean

Change your button click event handler body to be like this:

mDontRun = True
ListBox1.SelectedIndex = 0
mDontRun = False

And add to the selectedindexchanged event handler the following as the first line:

If mDontRun = True Then Return

2) The alternative is not to declare a boolean, not to change the selectedindexchanged event handler and simply change the button click method body like this:

RemoveHandler ListBox1.SelectedIndexChanged, _
        AddressOf ListBox1_SelectedIndexChanged
ListBox1.SelectedIndex = 0
AddHandler ListBox1.SelectedIndexChanged, _
 AddressOf ListBox1_SelectedIndexChanged

Simple really... and one more entry I can point to from the ng...