Aiming to improve my coding skills while also helping this amazing software, I plan to implement one of the “simple” feature requests to understand better how the software works internally before moving on to harder tasks.
With this in mind, I decided that feature request 39 regarding *COUPLING support would be a nice place to start.
Since it will be a similar constraint to *RIGID BODY, I would like to know how the latter works internally - which functions are called, where they are stored, where they gather data to work in… - to base the new *COUPLING feature.
I managed to compile PrePoMax from the upstream code with success, but I have no idea how to use Visual Studio to achieve this goal. I suppose there is some tool to see which functions are called when I use the compiled .exe (maybe it is the “call stack”, but for me, it appears empty).
since coupling type distributing is applicable for force type only, maybe is more convenient when these features are placed in properties menu by options. Expected user to switch from rigid body to coupling, for example “Coupling type Distributing” and “Yes/No”
btw, i’m also interested in exporting code workflow since look less complicated for me. Importing another file format also, but it could be more complex in displaying object in graphics after completed.
So, let me start by explaining how to figure out how PrePoMax works using the Visual Studo.
If you are new to PrePoMax code, the best way to start is the class in FrmMain in the folder PrePoMax/Forms. This class is the main form of the application. Since most of the user functions are available through the main form it is the simplest way to start following their execution path. What you can do is open the main form in the design view (double-click the file in the Solution Explorer) and then find the menu and double-click it to get to the code that is executed on the user action. When you are in the code editor, you can set the breakpoint on a selected line, and then the code execution will stop there. Once stopped, you can continue through the code line-by-line.
But what happens in most cases is that the code will open another form (editor), and then you have to follow the code execution path through the sub-form. Luckily, all these sub-forms have a very similar design (for example, the class FrmConstraints is located in folder PrePoMax/Forms/33_Constraints) where at the press of the OK button the function:
protected override void OnApply(bool onOkAddNew)
is called. This function usually calls one of the functions that actually do the work from the base PrePoMax class called Controller - so look for the local name of the Controller class which is usually _controller.
But in general I would not recommend this approach. It would be much easier to first try and add or change some functionality in existing classes. Especially classes, that are not directly connected to the user interface (UI). The UI workflow is usually very hard to grasp and manage. There are many functions needed to correctly handle the user data and to use the functions correctly one has to understand/grasp how they are related or connected. For that, understanding of how the entire UI works is usually needed.
I could give you more detailed instructions on what to do in your selected case, but it would be easier to first try some smaller tasks.
A typical class that is easier to understand and improve is/are file importers/exporters. For instance, the class InpFileReader located in CaeModel/FileInOut/Input/InpModel. Or you could add a Gmsh file importer which is currently missing.
Set the breakpoint inside this function and use the Call Stack window fo follow it back to the place where it was called. There try to add a local parameter to control the visibility of the min/max value.
I could not be grateful enough. Thanks for helping with this!
I’ll report here as soon as I get something (not) working. Probably the best would be to do it in GitLab but I already started this thread, so whatever .
.