I have been using Windows 7 for 2 weeks as my main OS and there is no
going back for me. I however, would like to get my hands on the release candidate (s) when the present beta becomes one.
Are any mere mortals going to be afforded the opportunity to test this out, or is it a case of "no way Jose!"?
I have been using Windows 7 for 2 weeks as my main OS and there is no going back for me. I however, would like to get my hands on the release candidate (s) when the present beta becomes one.
The more .NET coding you develop, the more you realise that .NET itself is quite hard. Unmanaged developers make the mistake of thinking that everything in .NET is easy, and that there are no new problems that .NET faces, that the native world has not faced.AndyC said:Maddus Mattus said:*snip*
While the intent at one point defintely seemed to be to provide a managed version of everything that made practical sense, I suspect the reality of doing so has proved somewhat more difficult. You can see this in the introduction of much better interoperability functionality in C# 4.0, which is clearly going down the route of making interop less painful and reducing the need for managed wrappers for things like the Office COM objects.
People need to stop thinking of .NET as a layer that exists on top of C/C++, and that everything in it is easy because this is fallacious. There are some very difficult algorithms that .NET can solve and they are equally hard in native C/C++ or C#/F#. Yes there is a great desire to access the underlying runtime controls for a lot of people, but why limit yourself to a control that was written over a decade ago?
Over the last year or so, every pain point I have had in Windows forms is easily solved using WPF. It really is as simple as that. Take the Office 2007 treeview for example or even the Vista/Win 7 treeview. If you are owner drawing the controls you have to handle some really tricky code, and it takes some time to get the control right, especially when drawing images and node text. Try and do the same with WPF, yes you have to learn some new concepts, but really at the end of the day, it ends up taking the same amount of time but you are not limited by an ageing API.
I don't want to turn this into a WPF Vs Win32 rant, but writing both isn't exactly a walk in the park. .NET is very well designed compared with C/C++ but not everything in it is easier that C/C++. Indeed some things are harder, as you have new concepts to understand, that do not exist in the native world. This is by no means saying that there is equilibrium in the complexity of both, but .NET is very difficult as well.
The problem I have is with things like the User32.dll. If you look at the Office 2007 treeview for instance, I know they tried, but that is still very buggy. They have performed miracles with it in Vista/Win7 but it is a very hard control to modify. Even if you have a managed wrapper around it, the code to get it looking right is very ugly and this is the big problem I have with managed wrappers. Try debugging the .NET source for any winforms control for instance.littleguru said:I wonder if there's ever going to be something like the Win.NET. By that I mean a managed Windows API over the native APIs. That Win.NET would come with Windows like Win32 is right now... Would be nice.
Sometimes there are API's that you would like managed wrappers for, and like pinvoke.net, there are loads that exist. This inherantly increases the complexity of your codebase when developing an application, so making further modifications down the road becomes more expensive. You end up with an application like Windows, and it's dialogues that nobody wants to change because
a) it is expensive to do so
b) you may end up introducing more bugs into something that was working already.
I have changed my way of thinking after some serious Win32 programming over the last year, and where possible, just rewrite the native control in managed code because the maintenance of the application becomes that much easier in the future. Yes there are boffins that like very complex programs that do all sorts but .NET programs littered with p/invoke calls are not very maintainable.
Maddus asks a very pertinent question, and it would be nice to know exactly what people are missing from the native API's?
Bobot ignore what everybody else has posted and to to see Beth Massi's forms over data video's. I am a C# programmer and learned using these videos (love Visual Basic as well now).
These are an excellent introdution to dealing with data in a smart client world, you can then move onto using things like Linq but do the forms over data videos first.
If you get stuck, check out her blog as well, there are some treats there.
I foresee a 2-tier Windows in the future. You will have your core OS, then you (in Win 7) have your Windows Live platform.
Analogously, you have your core OS (again), and your business, silverlight application written in .NET. I'v been doing some job hunting recently, and pretty much all .NET jobs (in England at least) are ASP.NET based. With Silverlight, I can only see this trend continuing. I recently completed a .NET winforms application for a warehouse/distribution centre, and would rather had done it in Silverlight, but there were no controls a year ago, and still no firm data accessaccees technology. Virtualisation is huge in the business world, and people are going for thin clients wherever possible.
I fail to see the necessity of the core OS and it's API, as I won't really ever need the native dialogs, because I don't typically write programs like nero, that interact with the OS, most .NET applications don't really have a need for this. That granted, I checked out the vista bridge (did not know that existed till yesterday) and that has some very useful stuff. It is possible to create a genuine Vista/Win 7 looking application using Winforms, Vista Bridge and some interop albeit rather painful.
The big issue is that Microsoft said they would continue to support windows forms but this (by VS 2010) will not have had an any update or bug fixes (and there are a few) for 5 years. It is the Windows forms code/controls they need to update to reflect the new native API's, because there are a plethora of winforms applications that will remain so for some time into the future.
Proof: wastingtimewithforums wasn't smart enough to start the original UAC thread, so is attempting to steal the format from that thread. This is somewhat somnifacient!Ray7 said:Bas said:*snip*
If you have anything new to say, then just tack it onto the existing thread ... it helps keep the thread of conversation going.
We all know how important this is, but one thread on the subject is much easier to follow than three or four (at least for me anyway).
It is rather difficult to come up with a new feature for the standard Win32 treeview control for example. Microsoft's encumberance is the User32.dll that has not been updated in 15 years. Apple appear to have a far bigger license to design than the Windows team, that is stuck with all these aging controls. Just what more can be done with the listview control? If you try anuse this native control in windows forms, your are stc fixing flickering problems, resize, redraw issues and a whole host of other headaches.blowdart said:http://www.businessweek.com/the_thread/techbeat/archives/2008/03/apples_design_p.html
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, "seven in order to make three look good", which seems to be a fairly standard practice elsewhere. They'll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.
I admire the fact that they are really pushing these controls to the limit, and maybe with Windows Live a two-tier windows is in development. By this, I mean you get the core OS with a simple theme, and the opt in applications that they can be more creative with. Only a fool does not admire the genius needed to procure the new task bar in Win7, but this is quite easy to do with WPF. I could do this in a week by myself.
I think new and fresh blood is needed at the top in Microsoft, not for the coding, but the design. Does Julie Larson-Green think all these Flintstone age checkboxes and dialogs are part of great user experience? Someone please put that question to her!