I hope so.

Right now the .NET team is small. The CIO, who I suspect is acting mainly as a developer, has been heavily involved in the initial design. He was working with the project leader, who left last month for a different job. (She told me she wasn't looking and was contacted with an offer she couldn't refuse). Her replacement starts next week. A .NET developer started last week and I heard another has been hired. Finally, there is one guy on staff who is dividing his time between .NET and other stuff.

I am looking forward to meeting the new project leader. Buttlicking will not be ruled out ;-)

>How many are on the .NET team?
>I asume enhancements are still being added to the VFP application otherwise needing four to support what presumably should by now be a stable system sounds excessive. Maybe when you are more familiar with the existing system and when timelines slip on the .NET development (as they inevitably will :-} ) giving you some .NET work will make more sense ?
>
>
>>Uh, Outlining keyboard shortcuts? ;-) You don't have to explain it to me, I will look it up. I also need to review delegates. Just another reminder of how much I have to learn. It's hard to do when you're not using it day in and day out.
>>
>>There is a rewrite in C#.NET underway at the company where I am working now. I was told I would be participating in that, as would the other three developers I am helping support the VFP line-of-business app that is being rewritten. Already I am getting the feeling that I am being used like a you-know-what (starts with b) once again. If that's the way it plays out this will make the fourth time I have taken a job with the understanding that I will be able to do .NET, when all they really intend is for me to support the legacy system while others port it to .NET. Last week I found out that the rewrite project plan includes no hours from me and the three other VFPers. They are all employees -- I am on a 6 month contract to hire -- and I think only one of them even wants to use .NET. We'll see. I am not squawking because it is great to have an income but that .NET work experience remains elusive. I keep studying when I can find time (lately ASP.NET MVC) in faith that it will be put to use. One of these days ;-)
>>
>>>I agree with Bill - good question. And one where I'm sure you will get no consensus :-}
>>>Personally I normally use regions to group:
>>>(1) All class level private variable declarations.
>>>But this depends on style - if you choose, for example, to declare backing fields alongside their related property declarations then it's not so useful.
>>>(2) All class constructors.
>>>(3) All overloads of the same method
>>>(4) Delegates with the same signature ( I don't need this very often)
>>>(5) Interface implementations (the IDE actually does this automatically if you use the 'Implement Interface'). But this can be confusing if the class already partially implements the interface or where some interface members are shared with other interfaces....
>>>
>>>Sometimes it makes sense to group a bunch of related methods - but where that looks like a good option it's often an indication that the class might benefit from refactoring.....
>>>
>>>I suppose there's a case for grouping automatic properties. I don't - but I don't know why I don't :-}
>>>
>>>IAC it helps a lot if you are comfortable with the Outlining keyboard shortcuts....
>>>
>>>My 10c .......
>>>
>>>
>>>>Not to take this off course, but are you a fan of #region or not? Or does it depend?
>>>>
>>>>Based on far less experience with .NET than you, I am ambivalent. If it's standard .NET emitted code like the kind that is generated for every form, sure, hide it. If it's code I wrote myself, eh, I'm not so sure. Maybe irrelevant stuff that would interfere with reading the code would be put off in a corner where it belongs. OTOH if there is something fishy in the hidden code, maybe something that was applicable when it was written and no longer is, regions increase its likelihood of remaining uncaught. If you don't see it you can't fix it.
>>>>
>>>>Let me put it another way. Are there certain types of code that we write ourselves that are candidates for #region and types that are not?
>>>>
>>>>>VS2010 is less restrictive in this respect. In fact I don't think there are any restrictions - even defining regions that would make no sense in real coding are allowed. e.g.: This will work in 2008 and 2010:

#region A
>>>>>    public class C1
>>>>>    {
>>>>>    #endregion
>>>>>    }

wheras this will fail in 2008:

public class C2
>>>>>    {
>>>>>             #region B
>>>>>    }
>>>>>#endregion

In 2010 even something like this will work:

public class C2
>>>>>    {
>>>>>        public void Foo()
>>>>>        {
>>>>>            #region B
>>>>>        }
>>>>>    }
>>>>>#endregion

But, bottom line, you usually need a region to contain only complete code blocks and 2008 handles that OK. Arguably, 2010 is worse since it's possible to define regions that work as specified but are actually conffusing since they expand/collapse arbitrary code selections...
>>>>>
>>>>>>A little futzing revealed the answer:
>>>>>>
>>>>>>When I put all of the child #endregions within the curly brace that teminates the class, alll was well.
>>>>>>
>>>>>>>>I have a large class with a lot of methods (I probably will break it up the next time I add to it) and I have used #region foomethods / #endregion pairs to make it more readable.
>>>>>>When I nest more than 4 pairs in a parent pair, the class compiles OK but the - and + marks don't appear on the 5th region and I can't expand or collapse it.
>>>>>>Is that a limit or am I doing something odd again?