I'm planning to write my first program (it'll be in C#), and I need help with a decision. I know I'll want to use custom controls in the final version of the program (probably these), but someone advised me to use standard WinForm controls until the program is running right. They said once things are running right, then I could replace the UI with the custom controls I want. Is this the best way for me to do it? Or should I use the custom UI controls from the beginning?
About me:
-Never written a program
-Have some light Access/VBA experience and classroom C++ Logic and non-UI programming
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Thanks.
It depends on some factors:
The complexity: a simple custom-draw control can easily replace the standard winform control but generally custom controls add new features and tend to have differents methods and properties. In this case, switching to the custom control is not a simple task.
Your experience: Since you are pretty new to this, using a custom control can add another level of difficulty. Generally, these controls offers more options than the winform controls. So, it would be wise to start with the simple winform controls.
Since this is your first project, I tend to agree with your friend. While there is nothing inherently wrong with starting with third party controls, you will find that there is much more documentation and help available for the built in controls. In your early development efforts, you will likely hit many stumbling blocks, regardless of the choices that you make. Therefore, starting out with the most well-travelled course may make things easier for you starting out.
Once you have a little more experience debugging some of the issues that you will inevitably experience while learning a GUI framework, then it would make more sense to start bringing in glitzy third party controls.
Just use the standard controls. Keep it simple, Keep it simple, keep it simple. Also know that if you are still programming next year (hopefully on other projects), you will look back at this code in shame -- but that is a good thing.
Never written a program? I would not advise using any third party libs at this point, you are still learning. If you want the benefit of custom controls, why not write them yourself? You get the custom behavior and you actually learn how this stuff works.
Also, this statement is a bit of a red flag:
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Design patterns are great, but until you get some experience it is hard to understand why they are so great. Start like everyone else writing 'bad' code and then come back to the design patterns. That way you will truly realize why they are so important (rather than just being told that they are). Don't try to grok the advanced stuff before being full competent with the fundamentals.
Related
I have been working on a project over the past 6 months creating a program to control some machinery. The software controls some servos, and other bits mostly via serial communication.
It is currently programmed in ANSI C99 in the Lab Windows IDE, along with some of its included libraries. As the project continues, there are many different variations on "how many" servos are needed for each build. This ends up requiring custom coding for each one. I feel the core logic could still be programmed this way, and just put into a dll if need be, and the rest programmed in something else like C++ if need be.
Due to the fact that each servo needs to be individually controllable, is there really a way to allow a user to select how many they want during an initial setup?
I know it is simple to create a UI element to allow a selection, but how would you go about dynamically creating new UI elements, and variables associated with that UI element for individual control? I think this could work in an interpreted language, where you could have a function literally write out new code after the user makes a selection, but I don't know how to achieve this in a compiled language.
I am currently just researching the feasibility of moving this direction at all, and would greatly appreciate any thoughts or input. If it is possible, I think I just need a basic example of how to go about this sort of problem.
The only way I can personally think of achieving this is to literally program out every possible scenario, but we are talking potentially about 50 variations, so I am really hoping there is a more efficient way to go about this.
If you have any questions for me in order to better answer, please feel free to ask! Thanks in advance!
I want to start a Process Manager project in C and it's suppose to have a Graphical User Interface. It's my first GUI project and I have no idea about it. After some searches I found that I should use winapi32 libraries.
My question is:
Should I write my project like a Console-based one and then I add GUI to it or I should think about GUI at beginning of my project?
I would like to say that it's best to write the application as a command line application, then write a wrapper in GUI. This way you get the most flexible application with a total separation between the GUI and functionality.
But I won't say it! :-)
From my experience it's very difficult to totally seperate the GUI from the application, and thus you should built it with GUI in mind. Your code must open windows, report progress, react upon GUI events, so you must be well familiar with the GUI system you use.
But you must also maintain a separation between the GUI and the functionality as much as you can. For example, make your callbacks short, and direct the funcionality to non-GUI parts of the application. If you need to report progress during long calculation, pass a callback to the calculation algorithm instead of mixing GUI progress commands within the algorithm.
You also must bear in mind that most (if not all) GUI system can do GUI commands only within the main application thread, and build the program accodingly.
So in summary - yes, think about GUI at the beginning, it will be easier this way, but also keep a good separation between the GUI and the functionality,
Why changing the program during development? Just design it like it should be in the end.
You could design your program in a way that enables you to use both, text and graphical user interface. Offer an abstracted interface to the core functionality and use it from the text and the graphical interface.
If you want start top-down and not bottom-up you should choose whatever you prefer to start with a text or graphical interface that calls stub-versions of your interface.
Why write your project like a console-based one, since it's gonna end up with a GUI?
If there are any things you want to try it out first (like you don't know how to do a,b or c), sure you can implement that as a side project.
But as far as your main Project goes, that's what I'd do :
Carefully plan and design
What is it gonna do?
How are you gonna do it?
What should the User Interface contain in order to fully accomodate what you need
Coding
Test and Debug.
Repeat 2 & 3 until perfectly satisfied.
Hint :
A. I wouldn't suggest you to add your GUI to an existing console app, 'coz this will most likely lead to messy code and/or a messy UI.
;-)
B. Always study before trying to implement anything. You simply can't imagine how much your knowledge of what can be done
influences what you can do (and most likely what you'll end up doing).
If you want to make an user interface, you can use QTCreator or Visual Studio forms projects...
QT is an excellent way to make cross-platforms and cute interfaces... Visual Studio forms are usable only in windows platforms.
When you're working with any of these technologies you have to put "componentes" in a "window" a then code them...
I don't know if it's just me, but I really enjoy some application's GUI designs, apps like iTunes/Avast, or some media players like KMPlayer. So I was thinking of making my GUIs look different and I later found out that it's called a GUI skin (am I right?).
I read somewhere that it's not such a good idea to use or make them regarding app's speed, usability and all that. So the question is: Is it good and safe to make GUI skins? and if so, how could I start programming one (cos I don't want to use off-the-shelf ones unless they're really great). What's the main idea behind them. I am expecting to be able to change the whole form's look and feel and possibly change it's shape.
Any idea on this is greatly appreciated.
Good or Bad?
Bad. I don't have a nuanced answer for you. I don't have a bunch of exceptions. I don't have a thoughtful essay to write on when skins might or not be appropriate. I have an unequivocal: Bad.
Custom skins are the cancer that is killing the Windows UI, turning it into an ugly, unusable jumble of mixed metaphors.
If you must theme because your app is the exception and you're just so cool, please provide an option to turn it off and use the regular OS theme. Not a skinned approximation of Aero, Luna or Classic, but the actual normal OS theme, whatever (potentially custom) theme is chosen.
As far as I am concerned there are two kinds of applications that might be skinnable: Media players for example might benefit from looking like an actual physical appliance (PowerDVD or so did that, iirc). However, the actual use cases for such things are very few, if any – the trend today seems to be that such applications have little to no UI and instead concentrate on the content (VLC is an exception).
Then there is the large host of applications where either developers or managers got creative or too much time on their hands. Raymond Chen calls this “I bet someone got a really nice bonus for that feature.” – a sentiment I deeply agree with. First of all, skins are often a non-feature; the novelty wears off really fast, they don't actually help a user with whatever problem they're having to use your program and finally, for many programs that exhibit skins, there is really no need at all. I mean, come on; how often do you open your AV program, or your graphics card settings panel, revelling in the glory of its beautifully and carefully-designed skin? Never, right.
So then is the question why you even want to devote development resources (either your own or others') to create something that serves no useful purpose, except making your application stand out visually. The windows UX guidelines also have something on window frames and branding. Note here especially the following section:
Don't use custom controls for branding. Rather, use custom controls when necessary to create a special immersive experience or when special functionality is needed.
Incorrect:
This example shows a custom control incorrectly used for branding.
Gadgets are another type of application that can get away with custom designs, but then again, those are often only used shortly and serve generally as either informational things or with ephemeral interaction.
If you do skins, do everyone a favor in making it (a) optional and (b) use the standard controls and just paint them yourself. This enables accessibility tools to still know what your program displays instead of just seeing a bunch of picture boxes that are used as buttons.
I know the title is really unclear, so give me a moment :)
I'm a pro-coder doing cool stuff at work (console games), but I've got an idea for an app (for a couple of years now ;)) that I'd like to create at home.
With 15 years of experience, I don't want to fall in to the trap of wanting to do everything myself - I'd like to borrow or steal as much as I can for all the trivial stuff, so I can just focus on what I'd like to do.
But I DO want an app that works like people expect it to, with all bells and whistles people are used to.
Which means I need to create an app with (in my case) something like a workspace-interface,
and undo-redo system,
persistence (serialization / loading&saving),
and preferably a VisualStudio kind of dockable interface so users can decide what they want it to look like.
(On the other hand, it's not an editor - think more like Mac's Quartz Composer !)
I know all of these things and how to write them from scratch, I just don't want to bother - I want to spend my time on writing my own cool thingie, not writing an undo-system or a docking system or whatever.
So I'd like to piece together my application, stealing what I can steal,
focusing on what I want to create.
So far (not writing any code) I came to something like this :
use a very lightweight MVVM lib, probably just my own simple implementation since everything more is overkill.
Use AvalonDock for docking (http://avalondock.codeplex.com/ )
find an undo/redo action-based framework ( http://blogs.msdn.com/b/kirillosenkov/archive/2009/06/29/new-codeplex-project-a-simple-undo-redo-framework.aspx for example )
figure out a 'standard' serialization in C# / WPF or find a library ?
...
The main question in the end is :
if you're working on a hobby-project that needs to be semi-professional, but you just want to focus on the fun stuff...
What is your approach ?
Can you recommend a framework, can you tell me how you did this before ?
How did you avoid spending time on stuff that's in the end completely unrelated to what you'd actually want to do ?
With 15 yaers of experience, you probably know most of this already....but since you asked i'll mention it anyway. ;)
Part of being a professional (semi or not) is doing the boring, annoying parts and doing them well, with full conviction. That said, doing boring things on a hobby project can kill it. You'll lose interest and what once was a great idea is now an abandoned project on your disk.
When a library does not exactly provide what you want, professionally speaking you have two options:
The missing features are critical to have: in this case you have to write at least some of it yourself.
The missing features are not cricical: in this case use the library and accept any shortcomings it might have.
However since it's a hobby project you have to take one extra thing into account: what is the risk of you losing interest in the entire project if you choose option 1?
To decrease the risk i see some options:
You could begin with a simple implementation that takes little time, but will allow you to continue working on fun stuff. As your project takes shape and nears completion, you could be more motivated to improve "that last feature".
If possible, you could also release the app without the boring feature and let the users pressure you into making it. Getting instant gratitude for doing it might motivate you more.
As for doing unrelated stuff....if it's unrelated, then how did you end up doing it in the first place? Either it's fun and you're enjoying yourself, then i see no problem. Or it's not fun, and not relevant to the project. In that case just stop doing it.
I'd probably try to use existing frameworks as much as possible in order to maximize the amount of time spent on the "fun" stuff. That being the case, I'd say you'd want to use one of the existing light-weight mvvm frameworks such as:
Caliburn Micro
MVVM Light
Both of those frameworks are small and take a lot of the plumbing out of doing MVVM.
I'm going to write a rather big/complex WinForm application such as Paint.NET, SharpDevelop, etc. I think one of the most important things to build such an application is to structure the project properly to increase maintainability and control the complexity.
So what kind of patterns or practices show I use? Any blog posts, papers, open source projects are welcomed. I'm trying to learn something from SharpDevelop but it's rather huge for me to step into.
PS: I'm an experienced programmer formerly targeting to web developement(asp.net, rails, etc.). So I know some design principles and how to use them when implement business logics. Maybe I really need now is a sample to get started with a WinForm application so that I can realize how to handle the menus, controls and others. I've learnt something about the MVP pattern but still unconfident to start a large/complex application.
For big projects the methodology and the tools you are using are equally as important as the architectural design. You need to set up a source control system (like SVN) from day one. Also, it is very good to have a standard build procedure and perform builds in a daily basis. The build procedure should include running all tests, which you should also put some effort in implementing from the start.
Regarding the structure, I believe the single most important thing is to divide your project into building blocks with mimimal dependecies on each other. This way you will be able to think about one small part of the system at the same time and not have to face the full complexity of it. It will also help delegate some work to a fellow programmer, if you have this chance.
In order to get started, I recommend that you implement first something minimal as quick as possible. Then work to make it better and add functionality. This will keep you motivated as you will have something concrete to work with. It will also help you identify major design flaws and important issues early enough to correct them.
This is a good beginners guide from Microsoft itself:
http://msdn.microsoft.com/en-us/beginner/default.aspx
check the Windows track there.
After mastering basics - and since you are an experienced developer - you can check this book "patterns & practices Application Architecture Guide 2.0" from Microsoft also.
I would imagine that many of the techniques that make for successful web projects will translate to Winforms projects. Start small and grow the application incrementally. Try to keep the entire application building/working while you add features one at a time.