easy way to replace components in visual studio C# - c#

I made a GUI using C# for my project using default buttons, graphs and other components available in visual studio. Now I have installed DotNetBar for cool components like tabs buttons etc and want to replace them with the old ones. Is there an easy way to do that so that just replacing (for example a button) associates the code with the newly added button...?
Thanks in advance

No, as much as I know there is no easy way unless the producer of the new controls provides an automated tool for the job.
The main reason lies in the difference in property names, methods name and above all the event handler signature between the standard controls and the new ones. You could be lucky if the third party controls have the same properties, methods and events of the standard one, but usually they have implemented new functionality and extendend the base one and this usually causes broad incompatibility.
Then there is the need to manually edit every project file to substitute the references from the standard controls to the new ones and this is also a complex work that only the producer of the control could resolve

Related

Inheriting Existing ActiveX Control

I am currently working with a 3rd party ActiveX Control (an editor for topographical data distributed by Cadcorp SIS). I have to do some fairly complex stuff with it in a VB.NET (framework 4) program and am finding that the API that comes with the control is quite limited.
As of now I have made a custom control which houses the control and acts as a wrapper for it to allow me to extend the API, which works fine, but What I would really like to do it give the control more events so that I can monitor what is going on with the data more closely.
I'm not sure how to go about doing this though...
I tried inheriting from the control and I can extend it just fine, but I can't figure out how to reuse it after that. Is there some way I can inherit the control and get it to appear in the toolbox so I can just drop it onto a form? Or do I have to load it programatically? If so, how can I do it?
Any pointers, examples, tutorials or alternative ideas as to how to do this kind of thing would be welcome.
If you are not seeing your control class in toolbox it doesn’t mean that you can’t use it just modify code from your form's designer to use your inherited class
Or
You can drag-and-drop your assembly (dll) from Windows Explorer to the
toolbox in VS.NET. Or you can right click on the toolbox in VS.NET and
choose Add/Remove items. Is this what you are looking for?
Also
<ToolBoxItem(True), ToolboxBitmap("MyNamespace.MyClass.bmp")> _
Public Class MyClass

Dealing with control flexibility

I've a question more about 'Good Programming Practices'.
I have just started a really big project. I'm using WebGui (long story short.. it is WinForms in web) - but it's not important.
I'm creating milions of forms with milions of controls like TextBox, NumericUpDown, DateTimePicker and etc. It might happen, that I will have to change something in behavior of DateTimePicker or appearance. It will be impossible to change it in every control. I want my project to be flexible so I've got an idea..
I do separate custom controls for every type - string, numeric, date, byte.. and within I will put TextBox for example. And on every form I will put not TextBox, but MyTextBox. In fact, that MyTextBox will be just TextBox, but when I change something there, every control will be changed.
Is it good, popular pracitce in programming?
in the case of WPF this can be achieved quite easily using Styles and Templates.
in Winforms this is not possible, therefore I'd say your approach of deriving from the controls and using your own custom controls on the UI is a good practical approach which helps managing changes centrally.
If the controls were created manually in the programme, alternatively you could use a Factory clase(s) and get the Factories to create the controller object rather than just newing up.
But this might not be possible when the UI is created by dragging and dropping controls as the developer has no control over the creation of controls.
Which ever the approach you choose, the fundamental goal should be to centralize the creation logic of the controlls.
Yes, this is perfectly normal programming practice for GUI development, if the standard controls don't satisfy your requirements.
Most developers get 3rd party control suites for the extra flexibility. The benefits in buying far out weigh the benefits in building core controls yourself.
I've worked at a place that did companyTextBox, companyDatePicker and it worked ok. A couple of controls got revamped over .Net versions so these base classed controls required some surgery. Any depreciated controls were left as framework version dependent.
For special things, I do a lot of research into good custom controls on CodeProject, CodePlex, Code.Google.com,etc and implement them into the project I'm working on.
Otherwise use the stock standard controls or the suite of 3rd party controls the company I'm working for use.
My advice is to get a 3rd party suite of controls and make a ton of re-usable user controls based on the 3rd party ones. This way you can build most of the 200 forms by Drag and Dropping the user controls onto the forms. Make each User-Control Implement an Interface with Create,Retrieve,Update & Delete methods for the forms to generically work with your user controls.

Workflow with C# in Visual Studio

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.

Adding controls to a form when I only have the reference to it’s EnvDTE

I am writing na Add-In for Visual Studio 2010, and I want it to add controls to an existing Form in an existing Project in an existing Solution, and I already have references to all of them.
As I have the reference to the Project Item that represents the file of the form, I want a reference to the Form per se, then I’ll be able to do anything to it (changing properties, and adding controls).
I have tried some approaches, though I must admit I haven’t ran out of tries. But since this is quite an interesting subject, instead of keeping on beating around the bush, I decided to write this question, so it would be faster for me, and would be registered for future similar doubts from anyone else.
Summarizing:
I have:
EnvDTE.ProjectItem myPrjItemForm
And I want to have:
System.Windows.Forms.Form myFormObject
Have a look at these articles:
HOWTO: Add a control to a Windows form from a Visual Studio add-in
HOWTO: Manipulating controls of Windows forms from Visual Studio .NET add-ins
It's VB code, but as far as I can tell, it illustrates the steps you need to perform.

Graphically template a .NET winforms application

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.

Categories

Resources