I just tested the auto-versioning plugin and was wondering whether it is possible to put the project's version into the output exe's filename.
So e.g. the output could look like this:
myProject_0.11.8.exe
Being able to have the compile-time-date in the filename would be nice aswell:
myProject_2013_12_16.exe
Is that possible?
You can add the following to the output filename variable:
add $(TODAY) or $(NOW_) or $(NOW_L), placing it between the end of the filename and the .exe part and you will add the compile date and time (including seconds).
To add the version number you need a few steps (there may be an easier way however I don't know one and would love to hear it:)
First go to Global Compiler Settings >> #defines and add #version = RC_VERSION thusly:
Then in your project options go to:
I use today and the version number as that means you only get one exe per day and version, whereas using NOW gives an exe per minute difference and NOW_L gives an exe per second of difference.
File Link
I have uploaded a sample project at Test Project on my website http://www.dark-arts.tk (work in progress).
NB: remember to do this for each build you want formatted this way!
Hope this helps, and let me know if you need more info:)
Related
I am trying to define 2 custom filetypes that I want them to feature thumbnail previews within windows explorer and I used this code sample (https://code.msdn.microsoft.com/CppShellExtThumbnailHandler-32399b35) to register the new shell extension but I can only make one of them work at a time.
The moment I try to register the second one it seems it replaces the IThumbnailProvider's Handler Subkey {E357FCCD-A995-4576-B01F-234630154E96} and breaks the first filetype's registration. If anyone has some experience with this, my question is,
can I register more than 1 filetypes at a time using this code sample?
Is there an alternative?
Thank you!
I managed to register more than 1 custom files, but the way I did it leaves me baffled... So if anyone could take the time to explain it to me I d sure appreciate it.
I copied the c++ project/solution to a new folder, changed the custom filetype parameters inside the code to match my 2nd custom filetype needs, build this new project and registered the resulting .dll.
So basically, what made it work, is that when you build the project/ solution the files that are being produced (the .dll being just one of them) are essential for the thumbnail handler to work.
And this is what baffles me.
I would expect that after you register the .dll, the new filetype is established and that I could even get rid off the aforementioned files. But apparently not only you have to register the .dll, but also make sure you keep the other files that are being produced upon built, unchanged in everyway.
So that basically means, 1 project/solution per custom filetype, nicely saved in its own folder :)
Is this the right way to do this, or am I just hacking it here?
I have frequently encountered the following issue in my day to day programming at the office where files can be reused from one project to the next, but the header information needs to be updated for each file, when you are dealing with hundreds of files updating them all manually is a pain, and a waste of resources.
Ideally what I would like is a program that contains a standard header with attributes like author, project code, creation date etc, that I can manually update and when executed it will add this information to all the files/programs in a directory. We use a standard header, which cover the first 20 lines of each program and each attribute is on a certain line, or can be searched for in order to replace it.
For the most part I would like to develop this myself, but any starting point as to how to apply said header to the first 20 lines of each program and how to apply it to each file in a directory. I want to add other functionality later for tracking purposes etc, but for now any help in getting started would be awesome.
I'm a big fan of using keyboard macros to generate header shells. So when I hit CTRL-H, I get a header block comment with the sort of information you described, including my name and today's date. If the assumption is that you will have to manually type something into a header for every program for every project (e.g. a revision note or whatever), then automatically adding 100 header shells doesn't save you much more than the keyboard macro approach.
That said, yes, you could do it with SAS using file statement or whatever. Could probably do it with any good text editor.
And of course a better solution would be to get a version control system.
I wouldn't modify the programs in the directory this way, but rather use %include files. We've done that on projects before, where you have a single program that includes libnames and such, and then you have
%include('header.sas');
or whatever in every program you write in that project. Modifying the code programmatically like this is a bad idea, both because you might not have the most up to date version of the headers, and because it risks damaging the programs if you do it incorrectly). Putting it as an include is easy, avoids replicating the same code 20 times (with possibility of error), and guarantees up-to-date code.
In your case, you can modify the 'header' file for the new day, and assuming you've set things up properly (which it sounds like you have), then the 100 or whatever other programs all can stay the same, unchanged, just including the updated header (automatically). This has the added advantage that you don't make lots of tiny changes to the programs, meaning you know when a meaningful update to the program occurred (as opposed to just a daily run).
In general, this modular approach is superior - divorcing the 'individual run' part of a program/process from the main part - because of these reasons, and because it makes it easier to reuse programs for other purposes as well if you have it set up so the module is already prepared and just needs a header file in the same directory to automatically run. (You can get the name of the current program and its path; if you need that, comment with what mode you use - batch or interactive - and what OS you are in).
This is also one of the places where the Enterprise Guide model is a bit better; there you have all of your project-related files in one project file (.egp), so you don't have to do even this - the project itself can have an autoexec process flow (which runs first, to set libnames and such) and can have notes/author/etc.
This should work. If a line starts with "Author:" it replaces the line with "Author: ME, ONLY ME!!!".
If you are on Windows, change all the forward slashes ("/") to backward slashes ("\").
%let infolder=/folder/where/sas/programs/are;
%let outfolder=/folder/where/new/sas/programs/are/going;
filename dummy temp;
data _null_;
attrib currentinfile currentoutfile length=$32000;
infile "&infolder/*.sas" filename=currentinfile lrecl=32000;
input;
currentoutfile="&outfolder./"!!scan(currentinfile,-1,"/");
file dummy filevar=currentoutfile lrecl=32000;
if index(_infile_,"Author:")=1 then put "Author: ME, ONLY ME!!!";
else put _infile_;
run;
I'd like to get scons to read a previous version number from a file, update a source file with a new version number and current date and then write the number back to the original file ready for the next build.
This needs to happen only when the target is out of date. IOW the version number doesn't change if no build takes place. The original file is source controlled and isn't a source file else it could trigger another build on check-in (due to CI). CLARIFICATION From scons' point of view the code will always be out of date due to the auto-generated source file but scons will only be run from a Continuous Integration job (Jenkins) when a SCM change is detected.
I've looked into AddPostMethod, but this seems to fire for all files within the list of source files.
Command and Builder methods use the VARIANT_DIR so I can't edit these files and then check them back in as they no longer map to the repo.
I'm hoping I'm just misunderstanding some of the finer details of scons else I'm running out of ideas!
Update
Thinking this through some more, Tom's comment is correct. Although I have two files, one version controlled text file (non-source code) and one non-source controlled source file there is no way to check one file in and prevent a continuous build/check-in cycle. Jenkins will see the new text file and spin off a build, and scons will see the new generated file. So unless I delete the generated file at some point, although this seems to go against the workflow of both tools.
Does anyone have any method for achieving this? It seems pretty straightforward. Ultimately I just want to generate build numbers each time a build is started.
From SCons User Guide section 8, Order-Only Dependencies, you can use the Requires method:
import time
# put whatever text you want in your version.c; this is just regular python
version_c_text = """
char *date = "%s";
""" % time.ctime(time.time())
open('version.c', 'w').write(version_c_text)
version_obj = Object('version.c')
hello = Program('hello.c',
LINKFLAGS = str(version_obj[0]))
Requires(hello, version_obj)
Two things to note: first you have to add the explicit Requires dependency. Second, you can't make version_obj a source of the Program builder, you have to cheat (here we pass it as a linkflag), otherwise you'll get an automatic full dependency on it.
This will update the version.c always, but won't rebuild just because version.c changed.
I want to make a GUI . I have a code that runs, made in C++. The project is made in Visual Studio(Visual C++ 2010 Express).
The outputs now are printed in command line. I want to tranform this to be printed to a window.
Is there a way to do this in this already made project ? Or I have to make a new one.
P.S. The code is consists of many, about 20 .cpp files and about 5 .h headers.
Following my comment on your original post here's some more information that will help you get through this:
Simply turn your "cout << ...." calls (or printf if the code is
actually C) to append the text to the UI control you want the output
to be displayed in? Or you can check this "hack" out:
cplusplus.com/forum/general/27876
Now simply add a new source file to the project: call it.. MyProjectGUI.cpp
Follow this guide here to setup the window on your project:
http://msdn.microsoft.com/en-us/library/bb384843.aspx
Then go through the rest of your code (or use the hack mentioned above or some kind of pipe to redirect your output (probably a lot! more complicated than the following method) and simply replace your cout << / printf calls with something like what's detailed in here: http://www.programmersheaven.com/mb/windows/105327/105327/appending-text-to-edit-control/
You'll find the basic idea of your modifications to be along these lines:
Create a simple window
Add a new edit field to the window (http://en.wikibooks.org/wiki/Windows_Programming/User_Interface_Controls and http://msdn.microsoft.com/en-us/library/windows/desktop/ms632680(v=vs.85).aspx)
Replace all console printing calls with a call to your append function for the edit box in the GUI
Best of luck with this (I might write up some code if I'm bothered but don't count on it -> no time. You should be able to figure it out with what I've posted though)
You dont have to do another project. It is enough to include headers and add libraries to linker. You should try a QT which is portable, well written and easy to learn. My one advice is to stay as portable as possible, in example you can create a makefile for your project so add new libraries will be a quiet easy job and not related to IDE . Dont stick to one environment.
I am trying to insert a custom preprocessor into the VC++ 2010 build-pipe after the regular preprocessor has finished, so far i figured that the way of doing this is via MSBuild.
To this point I wasn't able to find out much more, so my questions are:
Is this possible at all?
If so, what do I need to look at, to get going.
If you are talking about the c/c++ preprocessor, then you are probably out of luck. AFAIK, the preprocessor is built into the compiler itself. You can get the compiler to output a pre-processed file and then you MIGHT be able to send that through the compiler a second time to get the final output.
This may not work anyway due to the code being produced, at least in previous versions of cl.exe, doesn't seem to be 100% correct (white space gets mangled slightly which can cause errors).
If you want to take this path, what you'd need to do is have an MSBuild 'Target' that runs before the 'ClCompile' target.
This new target would have to run the 'cl.exe' program with all the settings that 'ClCompile' usually sends it with as well as the '/P' option which will "preprocess to a file".
Then you need to run your tool over the processed file and then finally feed these new files into 'ClCompile'.
If you need any more info just reply in the comments and I'll try to add some when I get the time (this question is rather old, so i'm not sure if it's worthwhile investing more time into this answer).