|
overloaded Name wrote: how would I know that which #if is missing in tapi.h heafer file??
by reading the content of said file, balancing each #if (or #ifdef or #ifndef) with its #endif, until you find an orphaned #endif. (That is also how the compiler does it). Chances are it is near the end of the file, but that is not a given.
|
|
|
|
|
There's likely nothing wrong with tapi.h. Check your project's stdafx.h file.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Perhaps if you showed the full message including the module name and line number someone could have a guess at what is wrong.
It's time for a new signature.
|
|
|
|
|
File: tapi.h...............
Line: 5281
|
|
|
|
|
overloaded Name wrote: File: tapi.h...............
Line: 5281
OK, so now go and look at that file - there should be a #endif statement on that line, so you can scan backwards to find out why it does not have an opening #if. However, as someone else has suggested, it is more likely something external to that header file that is causing the problem. Check your own source files to make sure you have not coded a spurious #if statement somewhere.
It's time for a new signature.
|
|
|
|
|
Unless you mistakenly modified tapi.h that is NOT the problem.
The message means that, while compiling a Cpp file (.h don't exist for the compiler, they are pasted in by the preprocessor in a previous compilation stage) and #endif ending nothing had been found.
Jut check if you didn't place an extra #endif in a file you include before including <tapi.h> in the Cpp file that gives the error.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Emilio Garavaglia wrote: Unless you mistakenly modified tapi.h ......
well i dont remember doing so but lets suppose I did that, what is the solution??
|
|
|
|
|
We come to a point where we have a lot of hard-coded string in our application (because laziness, design issues, release-scheduling, ...).
Most of our string are in the resources (string tables) and are used in the UI part of the application, but some of them are in the non-UI part (libraries) that does not have a direct access to the resources, and we don't want to have a dependence on the resources.
Is there a best-practice way to deal with large quantity of string ?
Simple header file with <code>const char*</code> ?
const char* myString = "my string";
or with <code>#define</code> ? Easy but not user friendly for potential localization.
#define myString "my string"
or an XML file with something like that (rough idea)?
<string ID="myString">
my string
</string&g
Or stick with the main resource file and string tables ? or one new resource for each libraries and include them in the main application resource ? possible issues with ID conflicts ?
Thanks.
Max.
Watched code never compiles.
|
|
|
|
|
Have a look at gettext. I've used it in a couple of projects and it's worked okay. It doesn't require loads of changes to the source and it's not too bad for localisation. It also handles strings from libraries fairly well.
One big bugger is that it's a bit arcane to support unicode, but you can get over that with a bit of reading.
Cheers,
Ash
|
|
|
|
|
Aescleal wrote: Have a look at gettext.
gettext what ?
I've googled a bit on MSDN and could not find a reference, are you talking about the gnu/linux/whateverux gettext ?
Watched code never compiles.
|
|
|
|
|
That's the one - GNU gettext. It's a library and a suite of tools for managing strings in applications.
Cheers,
Ash
|
|
|
|
|
A product family could have the following resourses division  :
- application level, with all libs used by an application:
one resource.h and one directory for resource DLLs
(the shared by applications libs could have a reserved ID-area
in an external header)
- that directory is the second (sub-)level:
DLLs - for each needed language
Of course, the only GUI-Strings should be placed in the resources
(which must be localized (translated ?)).
An application does set the resource handle to its needed dll,
for itself and all its libs at the run time.
A "counter question":
what role can have a non-GUI string constant in a real code ?
virtual void BeHappy() = 0;
|
|
|
|
|
Maintain Excel File for reading the strings used in application.
One Excel File for one language.
Each sheet in Excel File for each of your module or application or library.
Reading and writing from Excel File is easy with :
BasicExcel - A Class to Read and Write to Microsoft Excel - The Code Project - C++
|
|
|
|
|
use "ini" file
read string from ini file by GetPrivateProfileString method
|
|
|
|
|
This is what we used to do with DOS and 16-bit Windows.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
it store data in key value pair. and it work well in windowXP
|
|
|
|
|
Hi,
With something like
#include <tchar.h>
enum e_ID { ID_THIS, ID_THAT, ID_OTHER };
namespace App
{
const TCHAR* String(e_ID i);
}
and
#include <AppStrings.h>
#include <map>
#define ID_STRING(id, str) std::make_pair(id , _T(str))
namespace App {
typedef std::pair<e_ID, const TCHAR*> IdStr;
const IdStr IdStrings[] = {
ID_STRING(ID_THIS, "This"),
ID_STRING(ID_THAT, "That"),
ID_STRING(ID_OTHER, "Other"),
};
const std::map<e_ID, const TCHAR*> StringMap(IdStrings, IdStrings + sizeof IdStrings / sizeof IdStr);
const TCHAR* String(e_ID i)
{
const std::map<e_ID, const TCHAR*>::const_iterator it = StringMap.find(i);
return it == StringMap.end() ? NULL : it->second;
}
}
any part of the app after #include "AppStrings.h" may call App::String(SOMEID);. You may as well have different namespaces and id enums for different parts of your app.
cheers,
AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
modified on Thursday, September 16, 2010 6:15 AM
|
|
|
|
|
Hi all,
i m using CListCtrl of report style,sometime gray dotted line boundary display around the row of list ctrl.
please tell me how can i remove this.
thanks in advance.
|
|
|
|
|
The dotted lines constructs the focus rectangle, which is vital information for someone using the keyboard to navigate the GUI.
To get rid of it, you could custom draw[^] the list.
|
|
|
|
|
there is no option to remove this focus rectangle.
|
|
|
|
|
Le@rner wrote: there is no option to remove this focus rectangle.
If that's a question, then there is no style bit for that, no.
If that's a cry of despair, have my sympathy.
|
|
|
|
|
option is disable item selection.
|
|
|
|
|
Hi all, I have been trying to display Προσθήκη Όλων on a button control in Win-7 as well as in Win-xp machines. In Win-7 it is displaying properly but in Win-xp (SP3, 32 Bit) it is getting displayed as ???s???? ????. I have used unicode APIs. What may be the reason. Please help me to solve this issue.
Regards
msr
|
|
|
|
|
are you sure that 'Supplemental language support' and codepage conversion table for Greek is installed in XP?
|
|
|
|
|
This is just a blindshot, but maybe the font you are using needs the GREEK_CHARSET set to it, like shown here[^] for the LOGFONT structure's lfCharSet member?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
