I am creating CAPL Test Module in Canoe11. I wanted to create different files for variables , user defined functions in separate file and then include in my CAPL test Module. In which format it should be written so I can reuse it in different test modules?
They usually have *.cin extension.
Simplest way you can include them in *.can CAPL Test Modules is by File Explorer. Right click on Includes tab and "Add include...".
If you are code-savvy enough, you can manually define it in the
includes
{
}
section of the .can file, like this:
#include "[absolute/relative path to the .cin file]"
Related
Visual Studio 2019. Windows Runtime Component C++/WinRT project.
How do I follow and implement the recommendation: "We recommend that you declare each runtime class in its own Interface Definition Language (IDL) (.idl) file, in order to optimize build performance when you edit an IDL file, and for logical correspondence of an IDL file to its generated source code files. Visual Studio merges all of the resulting .winmd files into a single file with the same name as the root namespace. That final .winmd file will be the one that the consumers of your component will reference."
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-apis
Within the same project I can add a second (third and so on) .IDL file using Project->Add New Item->Midl File (.idl). This seems to work ok?! I then manually add associated .h and .cpp files for each .IDL file. Build to generate stub files then manually copy and "fill in" these files before a final build which is successful. In this way I have a single IDL file per runtime class with its associated headers and implementation files including any other files (c++ .h and .cpp files) needed for the implementation. As I need to add functionality to the interface I just edit the IDL file, rebuild and add functionality to the header and implementation C++ files.
Is this what was recommended?!?
When I add the .IDL file and then manually add an associated .h and .cpp they do not appear "under" the .IDL file as the original ones did when I created the new project. Is this just a visual nicety of Solution Explorer OR is this indicating that I have something wrong?!?
I plan to have multiple "C++/WinRT WRC" projects (one for each namespace, each consisting of multiple runtimeclass interfaces with separate .IDL/.h/.cpp files as described above. Then I reference all of the projects (project to project) in my single C#/UWP App.
I am actually trying to implement a user interface to allow me to utilise a large code base of math/engineering C++ classes that implement a very specific & proprietary type of electronic circuit simulation already existing and programmed in C++ and compiled as a console app. The user data in and out is relatively small compared to the processing that takes place to generate the output.
It looks like you are handling the idl files correctly and that behavior is the same as I experienced when just adding a new Midl file directly.
If you like the look of having the .h and .cpp files "under" the .idl file in the tree you can try adding a new View Model instead of a new Midl file. This will create the .idl/.h/.cpp files all with the same name and place the .h and .cpp files visually under the Midl file. The idl template you get this way is for a basic runtime class.
When creating a new Windows Runtime Component, the .idl and the .h are usually grouped under the .cpp, not the .idl, but whatever your preference. There isn't a template to add a Runtime Class, which is pretty dumb. One fix for this could be as follows:
This is not a perfect solution, but is the easiest. Create a new Windows Runtime Component. Open Project>Export Template. Select Export Item. Select the Runtime Class under the new component. Export with Automatic Import option checked. Save your project and exit VS. Open your project. You can now add a fully templated Windows Runtime Class by simply adding item>Runtime Class. However, there will still be no dependencies (there may be a tool for custom nesting, but not in community as far as I can see). To fix this, after adding the files, save the project. Edit the project file (use notepad++ or even unload project, edit) and add the property <DependentUpon>Runtime Class.idl</DependentUpon> between your .cpp and .h file delimiters. Save the project file and reload. Probably want to do this in batches.
The alternative is to write a .vsix to either add the files and edit the project file, or have a right click command that runs on a .cpp and edits the project file, adding the DependentUpon directive. I can't find a 2022 functional .vsix for this. I will post one if I make one.
Is there any way to automatically generate the DEF file for a DLL in Visual Studio? I've always just manually created them before, but there's gotta be an easier way.
I have found a place to generate the .DEF file for you here: expdef - def file generator
This works amazing and has a list of options you could also generate besides the method names of the functions and symbols.
Simply put: write a script that suits your needs. I for one created a small Perl script at some to create a .def file from an existing DLL that would then be used to create an import library (.lib) from it.
The reason there is no read-to-use tool that does it for you is because none of the tools involved can guess or somehow telepathically determine which functions or variables or constants or classes you want to export and under which names.
As you may know module definition files allow you to alter how an internal name appears in the export table, allow to export by ordinal (instead of name) or by name and ordinal. Of course they also allow to export a function multiple times (e.g. an old name due to legacy support purposes and a newer one because it follows some convention now).
Also see this question. You will notice that the answer also involves a custom script. In this case the requirement is apparently only to demangle and export the names of any and all non-static functions.
See answer with demo project in here:
https://stackoverflow.com/a/64302521/2338477
I have included python script to generate .def file from static library, but that unfortunately does not work with variables / data.
How can I specify the output path of a T4 template?
When I add my T4 template using "Add as Link" to my project from $TemplatePath$, it generates the output file in $TemplatePath$, not $ProjectPath$. How can I specify that $ProjectPath is where the generated file is placed?
I got around this by having a master template in one location and then templates that imported that one (but did little else) in each project. Of course, that's not the nicest solution.
We typically use the same system that Jeff Yates mentioned with minimal (often single line) stub templates including the shared template.
You could also use Oleg Sych's T4Toolbox to project output to any directory you please.
However, the standard IVsSingleFileGenerator that T4's custom tool is built upon doesn't have any dials to turn to control it's output location and it's behavior in the case of linked files is as you describe.
Is there a way in Visual Studio (any version) to embed the content of a file in another file upon compiling? For instance, if one wanted to embed an xml file in a vb code file how would it best be done?
Add the file to your project, right click on the file and select its properties. Under "Build Action" change it to "Embedded Resource". Now when you compile the file is automatically embedded as a resource.
Here is an example showing how to access an embedded bitmap resource.
Have a look at Resources. You can create a string resource that has your xml. This is then compiled into your application image.
Brian beat me about the embeded resource as I was looking for the resource URL :)
If you don't mind it actually being in your code, you can use an XML Literal.
I was about to mention using the #include preprocessor directive (for C and C++), but then you mentioned VB. I don't think VB supports such a thing.
I have no idea on how to go about doing this. But the first thought that came to my mind was that of Build Providers (the thing that generate classes from xml file in case of an ORM).
I searched & found 1 more thing called Custom Tools, which can act on a file existing in your solution and can be used to generate code file.
See if this link helps at all - http://www.drewnoakes.com/snippets/WritingACustomCodeGeneratorToolForVisualStudio/
What I've done in the past is write a simple .bat file that concatenates 3 different sources into a final source file that actually gets compiled. The .bat file is run as part of the Pre-Build event.
Project
SourceTop.vb
Source.xml
SourceBottom.vb
All of these files have a Build Action of "None"
Merged.vb
merge.bat
type SourceTop.vb > Merged.vb
type Source.xml >> Merged.vb
type SourceBottom.vb >> Merged.vb
I need to dynamically generate some macros into a .h configuration file that C programs can include in order to check which options are enabled, in a fashion similar to what is possible with CMake's CONFIGURE_FILE macro. But after looking in the doc and the web, I could not find something useful. Is it possible to generate such a file from bjam and have the dependencies handled correctly? If so, how would you do it?
Yes it's possible.. The way to do it boils down to defining a make target for the header and using the #() file output action support in bjam. You would set up a set of configuration variables on the header target and the action would use them to generated the file. That is what I do in one of the library extensions I wrote (see GIF lib extension). I also wrote some basic support for automating some of the tasks, but it still ends up being functionally the same, to create text files in the ext.jam utility. To allow easier definition of header configuration files that change based on Boost Build features (see Irrlicht 3D lib extension). Basically you can do just about anything you can think of with the make target since it's implementation is entirely up to you.