I need to store a configuration file that can be changed once the executable has been compiled inside of an executable using C++. I assume the configuration file would need to be stored as a resource for it to be editable once the executable has been compiled.
I have no idea how I can go about storing it as a resource and how to then include it in the main section of my project while still leaving it in the resource section.
Any help will be much appreciated.
Windows "*.ini" files is one way.
But, I suggest use XML files for configuration. Most compilers have 2 or 3 libraries to load & store data from XML files.
Besides, they allow to store information in a hierarchical way, and easy to add or remove configuration options.
EDIT:
Another way are JSON files.
Related
The REDHAWK IDE insists on expanding environment variables when creating the Makefile.am.ide file. For example, assume that $SRC_ROOT is /srcpath and I add an include path in the Path and Symbols window of the C/C++ section of my project as below:
${env_var:SRC_ROOT}/include
the generated Makefile.am.ide file contains:
rehawk_INCLUDES_auto = -I/srcpath/include
when what I really want is:
rehawk_INCLUDES_auto = -I$(SRC_ROOT)/include
This is important because this file is used by other team members that have different values for $SRC_ROOT. Currently we have to put the include path in Makefile.am, but then the IDE doesn't see the header files in the directory and sees errors for the code referred to in the missing headers.
Is there anyway to get RHIDE, to not expand the environment variables when it generates Makefile.am.ide?
Not exactly what you are looking for but you can always disable the auto-updates of the Makefile.am.ide by disabling the REDHAWK C++ auto-inclusion builder. This is in the projects properties in the Builders section.
This will allow you to add to Eclipse's Paths and Symbols section without the auto-inclusion builder picking it up and adding it to your Makefile.am.ide.
If you do choose to disable this builder you will then need to manage the addition of new source files on your own.
Youssef's answer is not a bad one, but I've come up with a different way to work around the problem. In Makefile.am, override the redhawk_INCLUDES_auto value to be what I what it to be:
include $(srcdir)/Makefile.am.ide
#Override the value from Makefile.am.ide that may be wrong!
override redhawk_INCLUDES_auto = -I$(SRC_ROOT)/include
This requires one to update any custom include directories in both the IDE and the Makefile.am file, but managing the source files is still automatic.
It still has the issue that the Makefile.am.ide file's contents will be different for other developers which complicates version control. So I don't consider this be a complete answer to the problem.
I'm working in MFC (C++11)in VS2015 and I have a set of standalone GUIs that i'd like to use across multiple projects. I know this is possible by creating a .rc file that can be included in the main .rc file of each project based on this:
Using Multiple Resource Files
While conceptually I understand what it is describing, i can't find any example of creating the standalone .rc file and second resource file. I created a test resource header file that lives globally in my solution and tried to include it using Resource Includes, but it can't find it, even with the path. Can anyone point me to links or examples on how to set this up?
I have either .rci files, that are never used with the resource editor. They are used with #include freely.
Or I have special .rc files that contain standard symbols and messages, that are used over a larger set of projects.
I just simply add the second rc file to the project. This resource file is simply #include'ed into the main .rc file of the project.
To prevent errors in the project. This second .rc file is excluded from the build. In the solution explorer right click on the item. And set Exclude from Build to YES.
Take care about collisions of IDs.
Here is how I do it. If you drop the resource you would like to include on the resource folder in the solution explorer, it will show up as a separate and editable resource in your project
You will have to include the headers in your project that go along with them, of course. So watch out for collisions of your IDs. You may have to go to the new resource and use IDs that have been set aside by adjusting _APS_NEXT_XXX_VALUE. I've never used the 'Resources Includes..'. as described in TN035. I just checked and relative paths to bitmaps seems to work fine. Hope that helps.
I know two approaches of doing it. I will demonstrate it assuming you want it for the need of managing the fact your application supports several languages.
The first one is already described by user #xMRi, and depending on your configuration/platform you will include only the .rc in question. For example you have configurations:
en_GB
fr_FR
pt_PT
de_DE
and files
Project_en_GB.rc
Project_fr_FR.rc
Project_pt_PT.rc
Project_de_DE.rc
For getting this right, you will need to do Exclude from build on them all, except on the Configuration you have selected at the moment on the VS Toolbar combo. If you have fr_FR selected, do Exclude from build of all other .rc except Project_fr_FR.rc files and apply the same logic on every configuration.
The other is to have a VS project (vcproj) for each language, where each project contains the .rc file brlonging to it.
The projects
Project_en_GB
Project_fr_FR
Project_pt_PT
Project_de_DE
contain respectively
Project_en_GB.rc
Project_fr_FR.rc
Project_pt_PT.rc
Project_de_DE.rc
Here at work we use both (I never heard of .rci files before; we use the first with normal .rc files), depending on the project.
I'm new to deploying programs written in C/C++ on Linux and I'm wondering what you'd do in this situation.
I have a binary file (compiled with GNU Make) that needs to read a config file (such as myprogram.conf). But when I write a Makefile to deploy this file to /usr/bin/, where should the config file go? And how does the executable know where it is?
You have endless options, but the best way depends on a couple of things. First, is it a user-specific configuration file, or is it global to all users?
If it's user specific, you could, for example, keep it in ~/.myprogram/config.file and have the program check there. As a service to your users, it's up to you to decide what to do if it's not found -- perhaps copy a default config there from somewhere else, or generate a default, or use hard-coded default options, or display a configuration wizard, or just fail. That's entirely up to you.
If it's global, the traditional place to put it on Linux is in /etc, e.g. /etc/config.file or /etc/myprogram/config.file. See Linux File System Structure. You will generally always have a /etc on Linux. Handling a situation where the file does not exist is the same as above - there's no "right" way to handle that, it's based purely on how convenient you want to make it for a user.
What I usually do for global config files is put them in /etc/wherever on install, have the program default to loading the config file from /etc/wherever, but also give a command line option to override the configuration file (especially useful for testing or other situations).
What I usually do to handle missing config files depends entirely on the application. I'll generally either have hard-coded defaults (if that's appropriate) or simply fail and direct the user to some documentation describing a config file (which I find adequate in situations where my installer installs a config file).
Hope that helps.
It kind of depends on what the configuration parameters are, and whether they are "per system" or "per user" or "per group" or ...
System configurations typically live somewhere in /etc/.... In the same directory that the program lives is a very good place too.
User confgiurations, in the home directory of the user.
Group configurations are the trickiest, as you'll probably need to come up with a scheme where there is a configuration file per "group". /etc/myprog/groups/<groupname>/config or something similar would work.
On Linux, the usual location for configuration files is '/etc', so it is acceptable to deploy a configuration file like /etc/myprog.conf. That requires root privileges however. Other good options include putting a configuration file in the user's home directory, making it something like ~/.myprog.conf or ~/.myprog/.conf to use a folder where you can have several config files, a cache or something else that you want.
As for how the executable knows where the file is, one solution is to look for the file in several common locations. For example, if you decided to place your config in the user's home directory, look for it there first, if not found, look under /etc. And allow a special command line argument that would let a different config file to be loaded. So, say, an invocation of myprog can check for a config file in the home folder, but myprog -c /some/path/config will use /some/path/config as the file. It's also a good idea to have some default settings that you can fall back to if there is no valid config file anywhere.
The config file can go anywhere, but I'd try to put it in the same directory as any other files the program will read or write.
As for how the executable will find it, I'd pass the config file's path to the executable on the command line as an argument, with a default value of "." (which is the current directory, the one you're in when you launch the executable).
I'm beginning development on an acoustic spectrum analysis tool (inspired by spek) written in C++ with gtkmm (C++ bindings for the GTK+ GUI toolkit). I would imagine that I should know how to do this by now, however...
My directory structure is a-la-GNOME, e.g src/, data/, po/, man/. The specific situation that presented the need for my inquiry is the use of a GTK UI Manager that will be located in data/ui. For this specific situation, I want to be able to load the user-interface from this file in an install-independent manner (e.g. loading of the file does not depend on a make install; the executable may be run [and load the UI file] either from src/ after running make [thus compiling the sources into the selfsame exectuable] or from its install prefix). How would I refer to the UI file in my source code (keeping in mind that the loading of the file is not performed by creating a file object (fopen(...)) but rather by passing a file location as a string argument to (UIManager).add_ui_from_file(...))?
In addition to this particular situation of a UI file, how would I do similar references to files (i.e. databases, INI files, XML schemas) by using the autotools build process? Is there a piece of relevant Automake code to quickly set up a project to use this type of directory structure?
simply try to use both files (with the un-installed taking precedence):
if(!(UIManager).add_ui_from_file(../data/ui/mygui))
(UIManager).add_ui_from_file(/incalled/location/mygui)
In Glom, I created a helper function that tries both locations, with both locations being defined in the Makefile.am (this is simpler if you have only one Makefile.am, by using non-recursive automake, which is simpler anyway):
http://git.gnome.org/browse/glom/tree/glom/glade_utils.h#n38
I will be creating a series of projects set up to build COM objects. I attempting to create a property sheet (.vsprops file) which will set up the builds for each project. One of the things I am doing with the properties file is customizing the location and names of the files created by the MIDL compiler. Here's the code I use for this:
<Tool
Name="VCMIDLTool"
TypeLibraryName="$(InputName).tlb"
OutputDirectory="$(RPCDIR)"
HeaderFileName="$(InputName).h"
DLLDataFileName="$(InputName)_dlldata.c"
InterfaceIdentifierFileName="$(InputName)_i.c"
ProxyFileName="$(InputName)_p.c"
/>
RPCDIR is a macro defined before this section of the property file. This works great for compiling the code. When I build my project, these five files are created with the correct names in the location I specified in the RPCDIR macro. My problem is when I try to clean the build. The clean successfully deletes four of the files, but the DLL Data File does not get deleted. I'm especially confused that some are deleted and one is not - I would have thought that either they would all be deleted or none be deleted rather than a split like this.
Does anyone know how I can customize the clean build to correctly delete these files? Optimally any changes I need to make would be in the property sheet so that I can share it with other projects, but if that's not possible then I'd like to at least be able to do it in the project file. Thanks in advance for any help you can offer!
Not your problem, it is a bug in the build system. The dlldata.c file doesn't get deleted using a regular build either. There aren't enough diagnostics available in the msbuild .log files to see what target fumbles this. I'm guessing it has something to do with the <FilePatternsToDelete> item in the Microsoft.CppClean.targets file.
I recommend you report this problem at connect.microsoft.com