Hello again,
It's important to write your app's in a structured way.
Here I was writing a lot of stuff about design patterns.
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
We can talk endlessly on this subject but it's not worthing.
So a basic rule:
Never write your "application logic code" inside your "interface code".
I can't understand your code, the names of variables are impossible to decipher.
It's like the code is obfuscated
, no offense.
But starting from you code I split the actions in the event button1_click into two parts:
First part is related to input, the second part is the actual action.
By doing this way I can easily move the logic, the actual action, in a let's say console application without forms, or in loop which generates more than one silo, or even in a macro. The silo generating algorithm no longer is dependent on controls on the form.
Also I can easily add some input checking in various places.
To explain the code, first I convert the textboxes input into numbers by doing a double.tryparse.
Users will always find a combination of actions that lead to errors or that doesn't follow the intended usage path.
You have to limit the chances of crashes as much as you can.
So if tryparse fails the user is informed and no action takes place.
the int.parse will fail if number is not integer, or if number is not in proper format.
The failure is an application crash if you don't use try-catch-finally.
From the code I think you need doubles not integers, this is why I used double.tryparse instead of int.parse.
Another rule is to
never artificially limit the functionality of your code. If it can run with doubles, let it run with doubles.
The y2k virus/problem is the best example.
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
So never limit to 2 beams and 4 joints if the machine can handle 1000 beams and 4000 joints.
It would make the code readable if t1..t5 are renamed to actual names, the same with textboxes, consider that.
After checking the input at interface level I run the actual logic CreateSilo(),
I placed the CreateSilo inside the event because I don't have a Controller.
A controller is the part of the application that would make the link between the viewer (the form) and the model (application logic and data provider (tekla api)).
The error handling should be inside the controller, which could write errors on disk in a log or show a message in a console or a popup message box or a textbox or in another window or whatever.
In your case the controller is the same with the view, the form. This is why error handling is at System.Windows.Forms level (MessageBox).
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
There's a try-catch error block because it can fail because no connection with tekla or because the math leads to errors. like 0 devision, or because the numbers don't pass some checks.
It can also fail because of antivirus or UAC or simply the user doesn't have tekla or the api is not correctly registered.
If you do simple stuff like adding one beam in an empty model you can see if all went well.
But if you modify a huge model it's much harder to see changes.
So we try to predict from code if all wen't well. A solution could be to check if the beam has weight after it was added to the model.
Remember that users always expect software to do well what it says it does.
If you make a macro, a connection, and it's used allover the model imagine if each one throws unhandled errors. You'll have to use end task for tekla to stop all errors. This is why a silent warning should be used.
The full revised code:
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
In the above, I described what function CreateSilo does and what the input means:
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
The input t1,t2..t5 should be renamed into more readable variable names.
A function should be named like an imperative action/request.
E.g. CreateSilo, DeleteSilo, ModifySilo, AppendSilo.
OR MakeitRain, OpenConnection, CreateThread.
By splitting the code I can have multiple input,like the above debug action.
And here is the console version. As you can see the silo creation no longer depends on interface, textboxes and whatever from forms environment. The input can even come from a file. The error handling is done in a console environment so no more messageboxes.
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
private void CreateSilo turned into private static void CreateSilo.
Static because it does not share context (variable, instance) with anything.
e.g.
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
For you code the CreateSilo uses a tekla model.
Model model = new Model();
This can be done only once when application starts, and reused for each action.
So the console application gets split like this:
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
And another file, in fact another class called TeklaTools.cs
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
As you can see the using statements are now only where you actually use the tekla api.
The tekla model object is created only once when the TeklaTools object is created first.
teklatools = new TeklaTools(); goes to it's contructor
public TeklaTools()
{
model = new Model();
}
As you can see TeklaTools is now part of a different namespace called MyCompany.
And the console app is using it.
About namespace, a simple example is using System.Microsoft....
of using Tekla.Structures....
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
Changing the namespace makes the TeklaTools class be reusable, we can use it in the forms application by simply adding it to the project.
In the forms version of code, it can be stored in a variable inside the Model part of the app, which is controlled by the controller.
Because here the main form is controller we can do it like this:
Code:
***************************************
Content of this section is hidden, You must be registered and activate your account to see this content. See this link to read how you can remove this limitation:
http://forum.civilea.com/thread-27464.html
***************************************
The next step might be to convert the tekla tools to a class library (a dll) and reused it in all projects.
The main purpose of this is to show how things can be structured so that they become reusable and easy to maintain. The most important aspect is to avoid creating unnecessary links between independent parts of the application.
I've converted numbers to doubles by writing instead of 2, 2.0.
A number defined in c# like 2 or 3 is an integer and so if you write:
double a=3/2; a will have the value 1
while
double a=3.0/2.0; a will have the value 1.5