I need to design a calendar control which should be added to our companie's application (I know there's already quite a lot calendar controls but I shall develop our own one...).
How should I start, should I use a kind of table to display the days or should I completely draw my own grid? How can I do this (I do not need rdy-to-use code, I just need some ideas...)
The application is written in C# as a WindowsForms application (thanks for the hint, forgot to mention this in first case...)
Seeing your comment about WinForms and:
I need to develop an own one because it must be integrated in an already existent application, I need full access in means of style and functionality
makes me suggest to use ready project http://www.codeproject.com/KB/selection/MonthCalendar.aspx and modify it if necessary. I use it in my own little project and it works like a charm. It provides full source if necessary so you can integrate it easily and modify if you think it's not fit enough.
In the end if you end up not using it, you can peak at the sources and functionality it implements and do it your own way.
To me redoing it from scratch is a bit pointless especially with such a good / free one.
If you are developing a web application then I would seriously look at using jquery. A good calendar control should be done client side so I would be looking at some form of java script solution. If you look at jquery-calendar.js as a good example you will see the complexity involved in developing your own control.
Related
We have an old application built on .Net 1.1 Framework and Winforms. We are planning to migrate it to the latest version of .Net.
Here are some of the questions running in my mind:
Should we go with Winforms or WPF?
We want the design and structure to the exact same as what we have now.
What kind of pitfalls can I expect when migrating?
Is there any place where I can lookup to see the process of migration?
Any other suggestions?
Should we go with Winforms or WPF?
This is a very broad question. But my answer to that would be this. Winforms designer is a painful experience and it is not as flexible as WPF by any means so if that is important to you then you should.
We want the design and structure to the exact same as what we have now.
Anything you do in Winforms you can replicate in WPF so no worries there.
What kind of pitfalls can I expect when migrating?
There are too many to name one of the most common ones for our migration was converting existing logic in the WinForms (yes it was a crappy, outsourced, legacy WinForms full of business logic) and connecting it to WPF elements. The process in and of itself is not that complicated but when you have too many intertwined pieces it can get pretty ugly.
Is there any place where I can lookup to see the process of migration?
The process of migration pretty much has to be iterative. So the way many people do it based on my research (articles, StackOverflow answers and such) is through ElementHosts.
1) Target a certain part of your WinForms that you would like to switch up to WPF and then take it out.
2) Replace it with ElementHost.
3) Then in that ElementHost you will have your newly rewritten WPF counterpart.
4) Test it out make sure that it works okay with the rest of the elements.
5) Go to step 1 until rest of the stuff on that window is replaced (You can do header, middle, footer or top, bottom any way you wish to go about replacing elements on the window it depends on your particular situation).
6) Once most of the stuff is replaced you can then combine all of those WPF User Controls into a WPF Window.
Is someone know any .NET Winform control which look like this button control?
QPushButton:
http://zetcode.com/gui/csharpqyoto/layoutmanagement/
You have several options here. You aren't specific about exactly which part of the platform you are using, but if using Winforms, you can certainly customize the buttons to some extent.
If you are using WPF, you can pretty much make it look exactly like you want in XAML. Check out Expression Blend.
As #Dimitri put it, the sky is the limit, but you may need to do the leg work.
You can create custom controls according your need and have its reference added to your project. you will have it added to your toolbox that you can use.
If you are refering to a button that is located on this example form:
We currently finishing our own application that has rather similar looking buttons. We did this by using a third party component. Steps are:
We purchased DevExpress.com's WinForms library.
We developed our own DevExpress Skin (with the help of an external screen design guy)
This was a bit of a work and some amount of money but the results look pretty neat.
Ive been working on a C# project for a while now and I fell it needs change its look.
I have found a UI kit that I really like, which can be seen below:
http://medialoot.com/item/transparent-ui-kit/
Does anyone know how to do this?
Thanks
EDIT: Im using WinForms
EDIT2: Maybe I should convert over to WPF? Is this doable?
You can subclass most common controls and draw their appearance yourself. However, unless for novelty applications I doubt your users will thank you for doing so.
Your example is a library of controls. For you to have an appearance such as that you'll have to create or acquire a similar library of controls and replace all your controls in your project to get that appearance.
If you want to update colors (background, foreground, etc.) and such you can make a class that recurses through controls and sets the settings using reflection and a switch statement to process each control. Then just run this on each form before you show it. One word of caution about this, some controls don't respect your changes and get overridden with themes from the OS (datetimerpicker being the biggest culprit). You'll also need to consider whether your users will appreciate the extra work put in for color/appearance changes.
If you don't have very good design skill and have a good know how about creating such templates, its better to buy them.
And C# is just a language. You're looking to create templates and skins for either for ASP.NET website/application or for windows forms.
Have a look at DevExpress Skins
If you can afford it.
I normally code with PHP, I am used to opening up my editor of choice and going away at it, coding classes,methods, etc. It is fairly easy as there is no GUI to worry about.
Last night I spent the whole night following a couple tutorials with C# in Visual Studio, it's turning out to be harder then I thought it would be. Once thing that I am not use to is, all the tutorials have you add a form object like a text box or button, then have you double clikc it to get to the code part, you then enter some code for that method. Then back to the form and re-peat
This seems very hard as you are never really working on "just the code" so 1 question is, is it always like that or just because i'm new and following tutorials?
Another question, when I see source code online to do certain functions, say I see a class I would like to try using, how can I use that class in the existing form class created by VS, do you somehow import other classes or do you add them right to the form code you are working on?
I'm sure that didn't make much sense but hopefully it does to someone, i'll try wording it better if not.
I should add that this was with WPF, also I feel like you have to learn 2 languages, the C# which has very similar syntax to PHP so that doesn't seem too difficult and the for GUI that's like a whole diff language
You can download the classes you are interested into.
Then you go to the Solution Explorer panel and you add existing items.
This will COPY the files to your project.
In order to use those classes you need to declare that you wan to use them.
So, what you have to do is to say something like
using FooNamespace;
Then you are ready to use the classes.
The name space is declared right before any class. You can go edit it.
Now about the forms. Each form is a Class and it consists of three files
ClassForm.cs
ClassForm.designer.cs
ClassForm.resx
You ONLY need the first one. Right click and view code. You can go there and use it.
Many questions, Many answers
Difficulty and Repetition
you can add form objects via the designer or you can hit the source button (CTRL-PgDn). From there you can edit elements in asp and html just like any php IDE. I do most of the work in source. I am a real programmer so I can never do the drag and drop. With intelligence and time you learn the properties and what to do.
to make complex pages you just have to know what you are doing.
What I started with VS I had the same feelings as you, but i have gotten into the flow of it.
As far as the code behind, you are just hooking methods up to the asp elements that get called by the built in code. You can add your own classes, functions, everything in the code behind or in separate files, just like c++, php, whatever.
Hope that helps, VS is really powerful and runs smooth when you learn where things are, been using it for years now and I'm still learning. Bottom line, never use drag and drop and just play with it.
unfortunately the .net world love drag-drop controls. so most tutorials are designed around this concept. drag a textbox on the to form. drag a button onto the form. double click button image to get the click handler.
it's not needed, it's just the approach for most people using visual studio. being that this is a WPF project everything can be done from code, or xaml markup. you don't need the WYSIWYG editor.
as for adding/referencing classes first you need to reference the assembly the class is located in. your core .net types (part of the BCL, base class library) are automatically included as references. then you add a using statement to the appropriate namespace. then you can instantiate the object.
There are ways to have a C# interactive window; see this question. Alternatively, you don't need to use a form, but you could also create a command-line application.
As for the second question, you can add a new class to your project and then use it in your form. There's really no additional step, except that if the namespaces are different, then it is easier if you import that namespace (via using).
Partly, yes, because you're new and using tutorials.
Partly, no, because you're working with forms, and you really don't want to hand-code those by hand.
If you just want to play with C#, and not concern yourself with forms and display, look for information on Console application. Instead of worrying about buttons and textboxes, your worst nightmare will be Console.WriteLine();
Here are some console-based C# tutorials:
C# Station tutorial
C# Yellow Book - it's a PDF. It's good.
Yes, it is exactly because you are following the video tutorials which are almost always tailored for beginners... Most of us making a living working in VS, developing WPF solutions do not even use the visual editor but instead work directly with XAML to build our UI and have very little or no code in the code behind files following the MVVM pattern.
To answer your second question, most of your classes that "do stuff" which is not directly intertwined with the UI should be in a separate class library (dll file) and should not even be referenced directly by your main UI project (in order to facilitate loose coupling) but instead accessed using some form of Dependency Injection, typically utilizing Interfaces.
The code that responds to user interaction should be in your ViewModel classess which are typically a data context for your views and these VM classes are typically using service agents which implement different Interfaces in order to use code stored in the class libraries mentioned in the previous paragraph.
Now, it is possible to just double click on a button and write all your code in that method created for you in the code behind file just like with Winforms, but just like in the Winforms world that leads to code that is hard to maintain, that is tightly coupled to your user interface and very difficult to test so try to resist that instant gratification and invest some time in learning the MVVM pattern, DI and OO design patterns which facilitate code reuse, decoupling and testability...
Hope this helps...
It really depends on what you are trying to learn. I don't think I would start off with WPF if I was using C#. I would start off with a console application to get the basics of the language down, then move down to a simple WinForms application, and finally to WPF where you started.
But yes, your questions about how the editor works is correct. It's how that platform works.
I know about code-behind files, but what is the best real-world way of Designers that are using DreamWeaver or other Design Tools to work with Visual Studio programmers?
For example, say you have a basic website with user interface forms hitting the database... the database work is definitely done by the developer but how to tie the designed forms with the database coding or client-side logic that may involve events on controls, or other GUI related tie-ins. Are the graphic designers also controlling application flow? There seems to be a large disconnect that needs addressed - especially when it comes time to tweak the design after it's been implemented.
Use another approach like MVC, separate your design from your logic. Like this every member (designer / developer) of the team can focus on what they do best.
MVC implementations: link / link
The best way is to make sure that your designers have some knowledge of what kind of HTML they will be working with.
Every ASP.NET developer is aware of MS-HTML, that lovely nesting of HTML tables, but designers aren't. Designers have their own requirements to meet and they'll do them in the best manner possible. Sadly it's not often good for us.
I am always frustrated when I receive a design from our UI team which shows radio-buttons nicely layed out in a grid using floating div's. Then I have to shatter their dreams that no, I can't generate you that HTML (ok, I can with the use of ControlAdapters, but every time they are different designs!).
Try and have a 90%/ 10% rule, where 90% of the design is done before the ASP.NET starts and the 10% is done once the ASP.NET is completed, and done against ASP.NET generated HTML.
And make sure you're using source control! Code doesn't exist unless it's in source control! And thanks to the latest TFS PowerTools there's a lovely Windows Shell integration component so you don't need to use VS to check in and out now more :D
This may sound really cheezy, but when I was working with Dreamweaver / Visual Studio, I'd do my layouts, and then conveniently put [RADIO BUTTON HERE], [INPUT TEXT HERE], etc. in the places where my form elements/controls would go, and I'd save the page as a basic HTML document.
That way Dreamweaver wouldn't nest its own form tags in and I'd have easy to locate places to drop in my ASP.NET controls when I went to merge things in. It was easy enough to create a fresh web form page in Visual Studio and then copy and paste everything over. If for some reason I mucked things up, I'd have a basic HTML "template" to start over wtih.
Unfortunately this is an all too common problem. Dreamweaver typically doesn't write html that is friendly to a .net developer. If at all possible, get someone who can actually read, and write HTML,not just use the Dreamweaver WYSIWYG editor.
I often found that if I'm working with a designer that doesn't know html, that I actually save a lot of time be just having them mock up everything in photoshop, then give me sliced up images. I find that my writing the actual HTML in a .net friendly format saves a ton of time, instead of having to go back and forth with the designer in this situation.