Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
When developing a WinForms app that will utilize a tab control to display different sets of data, is it best to add all my controls to the tabs directly, OR create user controls, add my controls to the UC and add the UC to each of the different tabs?
I was informed that the UC approach is best practice, and I understand some of the benefits, but I'm wondering if this is truly the way to go... any explanation either way is greatly appreciated!
I have found that personally I do like the UserControl model, it helps get the code separate by each of the functions (tabs), and helps with UI design time.
You can do it either way, but I have had much better long-term success going the route of UserControl.
In addition to the code separation, I think that adding the UC to a tab control ultimately makes it a lot more flexible. For example, if the UI changes over time and tabs are no longer necessary, it can easily be popped out and placed somewhere else. Or if the UC can be reused in a different context, it won't require a tab control to travel with it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am new to React and was learning what component is and what should be considered as component. As I found out component is considered as a certain block of a web page that can be reused and I hope I am right with this statement. But as you can see in the picture below button "What should I do" and add caption with input box together are considered as components. Why? those buttons are not reused anywhere in the same page so why should they be components. As far as I know, Component is a block that is reused in the same page several times
Flexibility.
If you particularly style your button one way and it takes a lot of copy-paste to use it elsewhere, why not make it a component and just call it.
Alternatively if it's fairly simple, you can just write it as is and move on instead of going through the overhead of making it a component.
It's entirely up to you.
Don't take the re-usability aspect too serious. Think of components as parts of a machine. You can order a motherboard, screen, mouse, keyboard... for a computer, or you can order the laptop as a whole. Up to you.
This really depends on you. The idea is to make as much reusable components as possible in React, if you stick to this formula your life will not only be easier but also your project will look clean and proper.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Hi I have been playing around with C and Gtk trying to learn a thing or two
Now wondering how do I create an application that has more then one form.
Do I just clear the window out or do I create new windows every time I want to have another form or view.
and does anyone know a good place to learn this type of thing?
I assume your goal is to use one window but change (large parts of) the window contents at times?
The widget you are looking for is GtkStack, which is a container that will only show one of its children at a time. You can use a Stack with user visible controls (StackSwitcher) or from your own code.
The Stack was only added in 3.10, so in earlier GTK+ versions you'll need to do the work yourself: Add your "forms" as children of a Box and make sure only one child is shown at a time.
does anyone know a good place to learn this type of thing?
To find out what kind of widgets you have at your disposal, I suggest reading the fine manual: https://developer.gnome.org/gtk3/stable/.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Do you think it is alright from architectural stand-point to have ViewModel - View without Model for temporary things?
E.g.: I want users to input some paths so I can open some files later on. It doesn't make sense for me to store the paths anywhere just ViewModel and when the user clicks "Show all files" I then construct models of the files and ViewModels for View that represent them somehow.
So really my only model is the model of the file.
I think sometimes people mistake design and architectural patterns as hard and fast rules. We need to understand that these are just guidelines. One example of this could be the way different programming languages implement singleton pattern.
So I would say if you need the functionality of View Model to be bound to View but really don't require a model, there shouldn't be any problem in ignoring the model. I would suggest use these patterns as guidelines and not as hard and fast rules. Feel free to make minor adjustments wherever applicable.
But at the same time keep in mind that you are not violating the purpose with which these layers are created. It should not happen like we bypass the model and start querying the backend database directly from the View Model. As long as the basic principle of separation of concerns is adhered to everything should be fine.
Of course. If it suits your business process, why not.
But you could probably still use a model to have some sort of in-memory persistence of the entered paths.
Sure. There's no sense in moving the file-opening logic to a separate object just so that you can say you've done it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to select many points/bars/columns etc in all types of charts that the WPF charting toolkit provides, something that the toolkit does not seem to support. I really would like to avoid writing my own DataPointSeries... Any ideas how to achieve that?
As you note, the current implementation (as of November 2009) supports only single selection. There are three roads to multi-selection support that I see offhand:
Implement it yourself by making the necessary modifications to the open-source code for the Data Visualization assembly. You can download the code from blogs.msdn.com/delay/archive/2009/11/30/two-birds-squared-silverlight-wpf-data-visualization-development-release-3-and-a-datavisualizationdemos-update.aspx. Making the relevant modifications shouldn't be too hard, especially if you implement just enough to support your scenario. Fundamentally, multi-select isn't much different than single-select except that more than one item can be selected at a time and it's necessary to track them all.
Wait for us to get around to doing this ourselves and download the relevant release as-is. Unfortunately, this won't happen very soon, so if you need this now, this isn't a great option. :(
Implement it yourself by creating a custom DataPointSeries deriving from ListBox as I mention briefly here: blogs.msdn.com/delay/archive/2009/09/13/a-preview-of-upcoming-charting-changes-silverlight-wpf-data-visualization-development-release-1.aspx. I mention this only for completeness and because the nice thing is that you get full multi-/extended-selection for free (after doing a bunch of work to convert).
So I guess there's really just one good option. But the good news is that it shouldn't be too hard - and it would make a great blog post I'd love to link to from my collection of Data Visualization links: http://dlaa.me/r/DVLinks
I hope this helps!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am developing a mid-size application with VB2008. To better test my application I am following a MVP/Supervising Controller approach.
My question is: What are your recommendations to separate responsibilites? So far I've come up with a winform with an instance of a controller and with an instance of my class. The controls are updated via DataBinding
The problem is that I'm just not sure where to write the responsibilites (let's say Validation, Report creation, Queries and so on) Inside my class? in a separate class?
Is there any small example of a clean Winform class design that you could point me?
I would suggest you spend time reading Jeremy Millers 'Build your own CAB' series of posts to get a feel for what you might like/need to implement as your application becomes more complex.
Martin Fowler is a good source of information on all things design patterns including MVC. Fowler discusses Passive View and separation of responsibilities is demonstrated also
http://martinfowler.com/eaaDev/ModelViewPresenter.html