at this point in time would a series of tutorials on WinForms be useful ?
-
In back-and-forths with this poster on QA in this thread:[^]: I am left with the idea about writing perhaps three articles, aimed at relative beginners with WinForms, showing how to use inheritance to create Forms that essentially duplicate an existing Form (where, for example, you want a set of standard identical controls with identical behaviors on every Form created). Second, I would like to discuss the shortcomings of that approach when you, for example, wish one Form that inherits from a "master Form" to not have one of the inherited controls (which in the designer appear "locked" when: you create a new Form, add it to the Project, and then make it inherit from the "master Form.") Third, I'd like to compare the strategy of switching between identically sized and positioned Forms to vary the user interface (which is what the OP of the QA post linked to above was after), vs. the simpler strategy of using Panels which are switched at run-time on one Form (but where said Panels may also use inheritance in the same way as described above with Forms). My question is: given the possibility that WinForms is now no longer of that much interest to CP members compared to the latest "hot stuff:" is it really worthwhile to write this up, and include tricks like use of a static class to manage multiple Forms, or Panels, or modifying the Program.cs class to call an 'Initialize method in a static class, etc. thanks, Bill
The glyphs you are reading now: are place-holders signifying the total absence of a signature.
-
In back-and-forths with this poster on QA in this thread:[^]: I am left with the idea about writing perhaps three articles, aimed at relative beginners with WinForms, showing how to use inheritance to create Forms that essentially duplicate an existing Form (where, for example, you want a set of standard identical controls with identical behaviors on every Form created). Second, I would like to discuss the shortcomings of that approach when you, for example, wish one Form that inherits from a "master Form" to not have one of the inherited controls (which in the designer appear "locked" when: you create a new Form, add it to the Project, and then make it inherit from the "master Form.") Third, I'd like to compare the strategy of switching between identically sized and positioned Forms to vary the user interface (which is what the OP of the QA post linked to above was after), vs. the simpler strategy of using Panels which are switched at run-time on one Form (but where said Panels may also use inheritance in the same way as described above with Forms). My question is: given the possibility that WinForms is now no longer of that much interest to CP members compared to the latest "hot stuff:" is it really worthwhile to write this up, and include tricks like use of a static class to manage multiple Forms, or Panels, or modifying the Program.cs class to call an 'Initialize method in a static class, etc. thanks, Bill
The glyphs you are reading now: are place-holders signifying the total absence of a signature.
I don't see any harm in doing this even though WinForms is not as hot as new technology with .NET, but you never know when someone might have a need for it and an article would be useful for them.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
In back-and-forths with this poster on QA in this thread:[^]: I am left with the idea about writing perhaps three articles, aimed at relative beginners with WinForms, showing how to use inheritance to create Forms that essentially duplicate an existing Form (where, for example, you want a set of standard identical controls with identical behaviors on every Form created). Second, I would like to discuss the shortcomings of that approach when you, for example, wish one Form that inherits from a "master Form" to not have one of the inherited controls (which in the designer appear "locked" when: you create a new Form, add it to the Project, and then make it inherit from the "master Form.") Third, I'd like to compare the strategy of switching between identically sized and positioned Forms to vary the user interface (which is what the OP of the QA post linked to above was after), vs. the simpler strategy of using Panels which are switched at run-time on one Form (but where said Panels may also use inheritance in the same way as described above with Forms). My question is: given the possibility that WinForms is now no longer of that much interest to CP members compared to the latest "hot stuff:" is it really worthwhile to write this up, and include tricks like use of a static class to manage multiple Forms, or Panels, or modifying the Program.cs class to call an 'Initialize method in a static class, etc. thanks, Bill
The glyphs you are reading now: are place-holders signifying the total absence of a signature.
BillWoodruff wrote:
WinForms is now no longer of that much interest to CP members
I get the impression there are still lots of CPians using this technology, and will be for a good few years to come. If you think the article(s) would be useful then give it a go.
-
In back-and-forths with this poster on QA in this thread:[^]: I am left with the idea about writing perhaps three articles, aimed at relative beginners with WinForms, showing how to use inheritance to create Forms that essentially duplicate an existing Form (where, for example, you want a set of standard identical controls with identical behaviors on every Form created). Second, I would like to discuss the shortcomings of that approach when you, for example, wish one Form that inherits from a "master Form" to not have one of the inherited controls (which in the designer appear "locked" when: you create a new Form, add it to the Project, and then make it inherit from the "master Form.") Third, I'd like to compare the strategy of switching between identically sized and positioned Forms to vary the user interface (which is what the OP of the QA post linked to above was after), vs. the simpler strategy of using Panels which are switched at run-time on one Form (but where said Panels may also use inheritance in the same way as described above with Forms). My question is: given the possibility that WinForms is now no longer of that much interest to CP members compared to the latest "hot stuff:" is it really worthwhile to write this up, and include tricks like use of a static class to manage multiple Forms, or Panels, or modifying the Program.cs class to call an 'Initialize method in a static class, etc. thanks, Bill
The glyphs you are reading now: are place-holders signifying the total absence of a signature.
BillWoodruff wrote:
is it really worthwhile to write this up
Yes, it is. Not every shop uses WPF, a lot of them still build on the controls that they and their customers are familiar with. I'm still using WinForms as WPF isn't implemented in Linux. Yes, Gtk# might be an alternative, but that would introduce a learning-curve for anyone unfamiliar with Gtk#.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]