Salakhetdinov Shamil
mcp2004 at mail.ru
Sat Oct 6 10:42:23 CDT 2012
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? > > -- > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > _______________________________________________ > dba-VB mailing list >dba-VB at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-vb >http://www.databaseadvisors.com > >