You should be able to select whatever toolsets are installed on your system, from the Project properties of Visual Studio 2019. However, it is advisable to use the latest one which will contain all the most up to date fixes and enhancements, and be fully compatible with the latest version of Windows.
it compiled for one of the projects after some tinkering
i had to change the debug source files and point them to VC2003
added _CRT_SECURE_NO_DEPRECATE & _XKEYCHECK_H in preprocessors definitions
and fixed some codes
it runs even better than before, i have no clue how or why
ill try & do the same to the other projects and maybe i will get lucky
Too many % characters there. Remember in a printf/scanf format the % is the control character, so two of them means print (or read) a single "%" character. So in your call it expects to read a string of the form "%.2f", and requires no parameters. It should be:
sscanf(parm, "%5f", &f ); // single % character to introduce the format, read up to 5 character float value.
The width value for scanf indicates the maximum number of characters to read for that field, so does not require the dot prefix, but should be large enough for the largest number.
See updated code.
That’s a good example of why you should upgrade to a new toolset: sscanf is a variadic function with a variable number of arguments. Older toolsets didn’t bother to do any analysis on the arguments while the newer ones interpret the format string the same way it would be interpreted at runtime and check if the arguments match. In your case they don’t because the ‘%’ sign looses it’s special function if it is escaped by another ‘%’ sign. VC19 is just trying to warn you about a probable bug in your code.
Not sure what you mean by changing only the debug source. There are however two problems with your format specifier:
- sscanf formats do not have a point for number of decimal places (unlike printf formats).
- percent sign must be escaped to read a percent sign from the input.
So, if you want to read something like "%12.34", the correct sscanf format is "%%%5f".
VS2019 warns you if you are missing the triple percent because the last argument of sscanf will not used.
I can only assume that eclipse is doing something. Normally, a header file that can't be found results in a fatal error. If you really are using #include "gtkmm.h", maybe eclipse is searching the project directory for the include file and that is what is generating the warning message. GCC/G++ on the other hand, searches the project directory and then the normal system directories for "" delimited include files Include Syntax (The C Preprocessor) If it is the case that you're using #include "gtkmm.h" try changing to #include <gtkmm.h>, and see if that removes the warning.
If it is the case that you're using #include "gtkmm.h" try changing to #include <gtkmm.h>, and see if that removes the warning.
I do not know how to enter greater / less then charactere here.
I did try #include <gtkmm.h> ( i just cut and paste your text ) with same result.
If you czech my next post you will find the answer - I am inclined to believe it is IDE problem.
After I did "new project" from scratch the build fails as expected when the file cannot be found.
This is just to keep the discussion going.
I did not verify this , but it looks as every time backtick string is added the build process has no error but the includes which cannot be satisfied are flagged as such in source file.
I am begging to question WHERE does the backtick string belong - as an option to complier or elsewhere?
I have used eclipse extensively in the past and it works fine. Your comment re double quotes versus angle brackets is correct. But that (and all the other issues) are nothing to do with eclipse, but about how the compiler search paths work.