I can't stand drag n' drop controls for things like threads and timers. These controls just feel too far removed from the actual essence of their being. Drag n' drop a thread? I hope the drag n' dropper understands what's going on under the covers before they do so.
Are these abstractions too far removed from the metal? Are they helping or hurting programmers?
Personally I haven't had a reason to use multi-threaded programming in my working career, although I did learn it in college. So the Timer control was a great help to me specifically because I didn't care to learn how to do multi-threaded programming in .NET just to get a piece of simple functionality going.
I think they are hurting programmers. Dragging and dropping is not programming.
I may be painting with a wide brush, but I find it shocking that most web application developers (specifically .NET WebForm developers) I have come across have a complete lack of knowledge when it comes to the HTTP model, basic things such as POST and GET are out of their grasp due to the abstractions they have encountered.
This article is a very interesting read and reflects my sentiments completely.
"Drag 'n Drop" meaning using the WYSIWYG parts of the IDE?
I grew up working on VB6 and dreamweaver code so I'm going with "very yes" if that's the case.
I think for basic long running operations; or one off situations the background worker control is perfect for these situations. If you're doing anything more advanced than that then you should be studying the advanced uses of thread and multi-threading design.
So for a quick way to get threading up and running, it doesn't hurt; but to use it as the one and only way to do threading then it definitely hurts programmers.
I don't think they are evil. Dropping a control on a form is just another way of saying "new Thread()" or "new Timer()", which many programmers don't really understand either.
Simple solutions won't always fit your needs, but when they do, what's wrong with using them?
However, if using the drag-and-drop stuff is the only way a programmer knows how to do things, that's not a very good programmer.
Its a UI metaphor thing.
What you Drag and Drop it should be a "something" a file, document or whatever to another "something" a container, bin, shredder, printer or whatever.
Dragging and dropping thread/task to a timer loses the basic mataphor and feels wrong.
Right clicks and pulldowns are much better for "verbs" like "start timer".
BackgroundWorker adds real value. It produces a lot cleaner code (by using an event model) than doing threading manually by using delegate invokes, then Control.Invoke to marshal the result back on to the UI thread.
I've been burned by testing for Control.InvokeRequired without testing for Control.IsHandleCreated too. Control.InvokeRequired will return false when the code is already executing on the UI thread but also if the control does not exist. If I would have used BackgroudWorker, I probably wouldn't have had that problem.
The good news is that, since .NET, drag and drop controls don't need to be used drap and drop style. I'm personally of the opinion that while drag and drop is okay for prototyping, the more complex your requirements, the more likely you are to find designers restrictive and obstructive. A simple example of this is a form that should expand as you resize the containing window. You quickly find yourself writing so much code that you would be better off ditching the designer entirely.
And that's before we discuss bugs in the designer that, for instance, remove all the events...
(From the .Net tag on the question, I'll assume we're talking about the Visual Studio designers when talking about dragging and dropping controls.)
I don't think they're evil, though I agree that it isn't always the most fitting metaphor for components (like Thread).
The dragging-and-dropping of control isn't, to me, a statement of "this is a UI component that is far-removed from the metal." Rather, it's a statement that I "want the designer to manage this component's lifetime for me." From this perspective, it's very sensible to add things like background workers via the drag and drop. In fact, this is my favored method for including any IDisposable object as a member of (e.g.) a UserControl or a Form. This way, the codegen is handled for me and I can focus that much more on what my code does as opposed to the wiring.