Well, The backgroundWorker control is the exact reason why you would want a new progress indicator, because the PercentWorkDone, is really unkown. So you are forced to make guesses that are not accurate. A more accurate representation is to use what the SQL
Server 2005 guys use, which is a circular thing that indicates that the server is working on task.
<shrug>Not sure I care. The control you're asking for is just one of a million different "answers" to this problem. And since I'm moving to WPF instead of WinForms, I can easily use an actual progress bar for this.</shrug>
Another things is that. Yes BackgroundWorker has a callback that you can use to update say a progressbar or something, but that is only in the case of using that control. What if I want to update a control from a thread that I generate using my code? Why do
I have to think about Invokability or not. I think its a compiler's job to do that not mine.
1. Why are you creating a thread instead of using the BackgroundWorker? Doesn't buy you anything.
2. I'm uncertain the compiler could actually do what you want it to. I do know that the obvious thoughts on how to make it do this (for any method calls on objects of types with thread affinity it would emit the normal code to test if invoke were needed and
do that instead it it is) would add needless overhead that in many situations would be significant, and would lead to poor designs. This would encourage coders to not segment their design so that thread context switches would be minimized.
Don't get me wrong, I think it's extremely important that languages move to a better way of handling concurrency. But this topic is extremely complex, and we don't have any answers to it today. Microsoft is working on it, with various research including the
threading APIs included in robotics studio, but I'm willing to bet you aren't going to see what you want in the next few releases.
I as a dev, should only think about what functionalities my program will do, the pluming should be done by the compiler. It should figure out how to update the control, from a different thread. It should generate a way to update it by setting up some sort of
events and call backs automatically.
Programming using threads can be painful experiance, and I think MS should change that for the better.
Its not only the Progress Bar control. I just used that as an example, of something that is relic. The Sockets (TcpClient etc..) classes are really limited and are not robust so as to allow for rapid customizable app development.
In what way? You'll have to get a lot more specific in this area.
Devs should not be left with the task of making their own custom controls for simple things that MS should have thought of before releasing VS.
Uhm... even though there's a lot of functionality that would be nice to have included, I could never go along with a statement like that. First of all, it's simply not possible to have an all encompasing standard library. No language does, nor should they
really. Second, the way you phrase this implies a lot of negativity towards Microsoft that is unfounded at best.
[qoute user="SecretSoftware"]Why low priority? I seen people ask for this kind of support in VS, since 5 years ago or so.[/quote]
I explained that. It's the 80/20 rules. 20% of the people and projects will benefit, while 80% won't. Other things have this ratio in reverse, and so they should have a higher priority.
True. But there are controls that are not really UI elements that are in existance today in VS.
But anything that does this is good.
Not sure I agree. There's non-visual controls, yes, but they are very closely related to the UI. I/O channels aren't.
Why not add both? At the end of the day, its about organization and cleanness. You can either have a messy experience, or a really great clean experience. I just prefer things happen in-situ.
Like I said, I don't have issue with this debugging aid. I won't call it testing, however, and I won't agree that the current testing framework and IDE support is clunky and unusable.
Its just about organization. I dont want to reference alot of DLLs They can add them all into one dll, and then with different namespaces. So in my using statement, I can say using System.LINQ.Xml , or System.LINQ.Entities, etc... its
better that way.
I already explained why they should not be in the same assembly. This is the same design mistake as the "God Object" anti-pattern. It's a waste of resources.
The reason is to be able to open one session to conserve resources. Believe you me, this will improve productivity a lot.
You won't save much. If you notice how quickly second (and later) instances of VS open, you'll know that many resources are already shared. I will, however, agree with the point about settings being persisted.