[dba-VB] C# winforms vs WPF

LOL, no panic.  You are correct of course, Winform will continue to be part of .Net forever, however 
there are no new books on it.  Not that it matters I suppose.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 10/6/2012 11:42 AM, Salakhetdinov Shamil wrote:
> Do not panic there, John :)
>
> I'm personally programming mainly using WinForms.
> That happened historically.
> If I'd have started now, I'd have used WPF.
>
> If you're going to "start almost from scratch" - use WPF.
> There was a thread in Access-D recent;y with good WPF books recommendations.
> But WinForms should live as long as .NET Framewokr will I suppose.
>
> No panic.
>
> Thank you.
>
> -- Shamil
>
>
> Sat, 06 Oct 2012 11:21:44 -0400 от jwcolby <jwcolby at colbyconsulting.com>:
>> 	
>>
>>
> 	
> 	
>>
> 		
> 		
> 			
>> Guys,
>>
>>
> I do a fair amount of C# programming, much of which is automating SQL Server from C#.  I do almost
>>
> no "DB Front End" kind of stuff, though I want to learn that.
>>
>>
> I have never taken the time to learn the Windows form / control stuff and today I went researching
>>
> and discovered that apparently System.Windows.forms is dead technology.  Something I read said that
>>
> the programming team at MS was dismantled and WPF is not the latest thing.
>>
>>
> Obviously I don't know either one.  For my purposes learning how to use the individual controls has
>>
> worked pretty well, I have programmed wrapper classes, passed controls into the classes, sunk
>>
> control events, raised events etc. I do not claim that is a superior paradigm, just 'what I know'
>>
> from doing it that way in the Access / VBA environment.
>>
>>
> My question, addressed to any folks who do heavy duty windows form interface programming, is should
>>
> I just keep on doing what I do or try to figure out how to use WPF.
>>
>>
> Just as an example, so that you can understand what I am looking to do, I have an existing class
>>
> which takes a listview control, a progress bar, a 'clear status' button and a 'print' button and I
>>
> pass all of these objects in to a class which forms a status system for my projects.  I wrap all of
>>
> the delegate functionality for writing back up to the controls, sinking the events of the buttons,
>>
> setting up and using the progress bar and so forth.  I then just instantiate one of the clsStatus
>>
> objects in a form, place the controls on the form, pass the controls in to the form in the init and
>>
> then call methods of this class to write status information to the list, tick the progress bar,
>>
> clear the status list and so forth.
>>
>>
> Notice that none of this is 'data bound', and is used by my application to tell me (the operator)
>>
> what the application is doing in real time.
>>
>>
> I hired a programmer to work with me (now moved on to another job), and I was the architect so to
>>
> speak but didn't do very much of the bit twiddling of making this stuff happen.  I do understand the
>>
> C# code but I am having difficulty (for example) getting a handle on how to use the split container
>>
> vs the splitter, the panel, dropping controls onto these objects, docking them and getting them to
>>
> be where I want them to be at run time, mostly just because he figured this stuff out.  He showed me
>>
> (last year) how to do this stuff but...
>>
>>
> So here I am trying to learn the form / control stuff and I am reading that it is dead technology.
>>
> But can WPF give me this level of object control?  Do I need this level of object control?  Has MS
>>
> bypassed me and provided a framework that does the kind of stuff that I am doing programmatically?
>>
> I obviously need some books to learn what I need, but I am not clear on what I need to learn.
>>
>>
> Any thoughts from interface programmers more experienced than I am?
>>
>>