I created a pretty fancy winforms app for my company. We had a graphic designer create the GUI, which was a pain to implement, all graphical buttons, lots of layered backgrounds and logos, animations, etc.
But now my company wants to resell it under different brands. But since I mostly coded it well, I told my higher ups I could have a totally rebranded version done in under a week. Basically all I would do is change a bunch of settings in an xml settings file, swap out the graphics with a new set, and build.
Problem is if they want 5 or 6 different brands, I'd have 5 different builds to support (I really should be supporting 1, with diff templates)
The problem is its not easy (as far as I know) to swap out the images in a winforms app. I have all the graphical resources in a single folder, but once each file is entered into its respective image list or container in visual studio, the only way to get it to update is to remove it and re-add it, changing the source folder doesnt cause the embedded image to refresh. This would be incredibly tedious for each build, there has got to be an easier way.
Add On:
So after some further investigation, I am leaning torwards some sort of resx file editor. However the ones I have seen so far are more focused on translating strings to various languages, and are either very weak, or can not at all edit binary resources like bitmaps/png's. Though if you open a resx file in an xml viewer (I use notepad 2 with .resx set to use xml sytax highlighting) MS is kind enough to tell you exactly how each type is compiled (mostly variations of base 64)
I think your goal should be having "brandable" resource files; you're essentially localizing your application, except you just have a few different versions of English.
You can use ResGen.exe and ResourceManager to load an external resources file, so you could use 5 different "resources" files but keep your code base the same.
This post may also help...
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/b388c700-0e07-452b-a19e-ce02775f78a6/
Edit: BTW, I will second the comment that if you're going through a great deal of effort on this, consider WPF... Most of those "graphical" elements could possibly be done natively especially if it's gradients and stuff, not to mention the easy templating.
What I would do is just load all the graphics of the disk at start up from a folder and create any imagelists needed as appropriate, instead of doing this in the designer. If you are worried that someone would steal the graphics, then I would create a simple file format (possibly encrypted) for my graphics and a small simple app for you or the designer to use to convert into this format from regular files. Then it's just a question of swapping out this folder between different brands.
If most of your forms are similar (i.e. same logo, same buttons on the bottom, etc.) you can use visual inheritance on WinForms to define a set of "Base Forms" from which your actual forms inherit.
If you develop a set of "Base Forms" for each of your brands, each set in a separate assembly you can plug-in the needed work to generate a new brand is reduced to generate a new set of Base Forms.
Hope it helps
It's too late now, but WPF would have been a better choice than WinForms, as it is easier to skin.
However have a look at what DevExpress does for WinForms, as their controls have a skinning system. It is not too hard to swap a DevExpress winform control for a standard winform control.
I think you should be thinking about creating user controls for the dynamically replaceable areas of the form. At runtime, you could swap out one assembly out for another.
Related
I am working on my final year project, in my project i am using winform c#. My project is some sort of security system including hardware.
In my project I have a lots of controls like panels, textboxes, labels etc. Till now I am using layout and it is getting slower and slower (and flickering more and more) as I am adding more controls in it.
My question is that isn't it better to generate controls when required and destroy them when I don't need them? Will it save memory?
Assuming that you use the VS Windows Forms Designer, it will create the code for you which will be loaded at runtime. There will be no difference if you load the controls in Form.InitializeComponent (as the Designer does) or in any other place where you wrote it yourself. The only thing the designer does is it creates the Form.Designer.cs file for you while you design the form, and you can use those controls the same way you would use the controls you create at runtime yourself.
Loading a lot of controls on a single form is not a good practice. And it will get slower as you add more contols. You should probably consider redesigning the GUI.
I want to use same xaml files for silverlight and wpf version of applications.
Only difference that i need is in styling. I have used styles in xaml. But for silverlight i dont want to use any styling in my xaml files, as styling is defined a application level in the form of themes.
Is there any other way to use same xaml file for silvelight and wpf versions? Otherwise I am forced to maintain separate xaml files.
you can reuse quite a bit of xaml for both, I have projects where I'm linking all the same files, xaml and code behind and it works decently.
A couple of things to be weary of is certain things don't always match up well, for example wpf has a template selector for a itemscontrol and silverlight doesn't.
Using SizeToContent tends to produce different behaviours in the two, I recommend avoiding it, I don't think it buys you anything.
I recommend having a seperate 'base' resource where you can keep your difference in the two files. things like event triggers for example aren't nearly as filled out in silverlight. you would have a base class for each version and they would abstract their differences, you could then mark the keys the same and use them as a static resource in your linked files.
Another big gotcha is you want to watch out for the order events happen for uielements, loaded,layout and apply template events get applied in different orders so if you were to make a templated control you have to be careful there, its not a deal breaker you can work around it, just be aware.
other things to be aware of
-silverlight commands take a little more effort, you have to implement ICommand, this isn't always the case in wpf, I use my implementation to help with sharing the code though.
-wpf is the superset, it has a lot of functions that silverlight doesn't have, Usually they are convienient ways of doing things, you just want to avoid those. Good Examples would be Preview events, not there for silverlight but you can usually find an event to match the behaviour.
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.