I'm C# beginner and not a computer expert in .NET altogether, however I need to create a basic C# form (that would have a few entry fields to store in MS Access database) in two days, so I looked for help at tutorial:
Divider Panel - A tutorial on creating a custom Windows Forms control from Start to Toolbox
Following instructions on section: Assembly Attributes and Signing,
I could not figure out on p. 14 how to create the output file DividerPanel.snk, which then needs to be copied into my project directory.
Could you pls advise me on how to handle it?
My another question is whether there is another simple tutorial for creating this kind of form using C#.
First of all, let me thank you for this great article.
I have a query regarding the deployment of the applications whic uses windows control library.
I have developed a windows control library, as per specified in the article. In my application i added this windows control library into the toolbox of VS.NET 2005 as mentioned below:
1.Right click on the toolbox
2.Select the Choose Items options
3.Select the .NET components tab & add reference to the dll ceated for my windows control library
Now, the windows control library is added to the toolbox of my VS.NET 2005 application. I can use it as other standard windows controls.
When i added the windows control library to the VS.NET 2005 toolbox, the corresponding dll is copied to the debug/release folder of my application. So, when i deploy the application & ship it, i have to include this dll also.
My doubt is.....
Is there any method to avoid this dll for the windows control library while deploying & shipping the application, so that only the exe is present as in the case of using standard windows controls.
For eg: If we add a button control to the application, the corresponding code for the control is added to the application, instead of creating the dll for it. Similarly, i want VS.NET to add the required code to my application when i add my windows control library to the application, withou adding the dll.
Is it possible to do the same.
Kindly post your sugestions.
I've been trying to get a toolbox icon working in my custom controls and have failed miserably so I loaded this project in to VS 2005 to see how it works. Problem is, when I switch to the test application and look in the toolbox, I see the standard "cogs" icon, not the customised icon. Do you know how to make the toolbox icon work in VS 2005?
Even if you don't intend on doing any processing in you public accessors, you should still always stick to good quality coding conventions such as this. The next point is my choice of naming conventions - many people still use naming conventions from other languages such as m_BorderSide instead of my choice of borderSide. My personal choice is based on 3 different sources: first is the names that Visual Studio will automatically assign to controls that are dragged and dropped from the ToolBox, and second is that fact that the framework itself uses this naming convention for most of its private properties (a quick look at any of the framework classes with a decompiler or reflector will confirm this fact). If Microsoft decided it was the best practice naming convention for the .Net framework itself, it's natural to assume it's the best practice when coding for the .Net framework.
The third reason for not using prefixes such as m_ to denote member variables is that you cannot take full advantge of Visual Studio's Intellisense features if you do so. Which brings me to another point of note in the accessor code, my usage of the this prefix - technically there is no need and no advantage in using the this directive in the above accessor code. However, by using the this directive you can take advantage of Intellisense's auto word completion system to fill in the rest of your variable name, saving coding time and saving possible problems with typos.
my 2 Cent:
Code should be readable without Visiual Studio. The prime reason for M$ naming convention is that they want us to use Visual Studio. Naming a variable borderSide is in my opinion very bad style. Naming it this.borderSide even more bad Your code looks confusing without Visual Studio. A variable name should indicate what scope a variable has. Also, this. should be reserved for non static properties and functions and not for private variables. Using case sensitive variablenames is also a bad thing to do. It makes your code hard to translate to different languages like vb.net. And, again it makes code difficult to read on paper or in webpages like this one.
Of course they want us to use VS, and coversely, we also want to use it. Show me a better IDE for C#, and I'll start listening more intently.
VS is really great but SharpDevelop (#develop) works for me even better than VS (VS is too bulky). #develop is compact, free, open source, and there is a free PDF book about developing it from its authors. Take a look...