|
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. <
|
|
|
|
|
Hi
<br />
<br />
BeginPath(hdc)<br />
<br />
Ellipse( hdc,0,0,200,200 );<br />
<br />
EndPath(hdc);<br />
FlattenPath( hdc);<br />
<br />
LPPOINT pt;<br />
LPBYTE byt;<br />
int nCnt= 0;<br />
nCnt = GetPath(hdc, (LPPOINT)NULL,(LPBYTE)NULL,0);<br />
if( nCnt != 0 )<br />
{<br />
pt = new POINT[nCnt];<br />
byt =new BYTE[nCnt];<br />
}<br />
<br />
Is this code produce correct path count (nCnt) in the given ellipse?
|
|
|
|
|
Well, as far as i can see, according to the documentation[^], nCnt should give you the number of points the path consists of.
> 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. <
|
|
|
|
|
Hi!
I got the following error:
Error 1 error C2259: 'irr::gui::CImageGUISkin' : cannot instantiate abstract class d:\klagui\source\main.cpp 27
I checked the CImageGUISkin class for pure virtual functions. It has no pure virtual functions. Then why this error comes? How to resolve this error?
|
|
|
|
|
If CImageGUISkin inherits from other classes, you need to check them too, and make sure all pure virtual functions are overridden/defined.
|
|
|
|
|
Parent class contains pure virtual functions. But if I try override those functions, I got the following errors:
error C2259: 'irr::gui::CImageGUISkin' : cannot instantiate abstract class
1>d:\klagui\source\cimageguiskin.cpp(325) : error C2143: syntax error : missing ';' before 'irr::gui::CImageGUISkin::getColor'
1>d:\klagui\source\cimageguiskin.cpp(325) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\klagui\source\cimageguiskin.cpp(326) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\klagui\source\cimageguiskin.cpp(326) : error C2511: 'int irr::gui::CImageGUISkin::getColor(irr::gui::EGUI_DEFAULT_COLOR)' : overloaded member function not found in 'irr::gui::CImageGUISkin'
1> d:\klagui\source\cimageguiskin.h(37) : see declaration of 'irr::gui::CImageGUISkin'
|
|
|
|
|
There is something on the line d:\klagui\source\cimageguiskin.cpp(325) that the compiler doesn't understand. Usually a type name where you forgot to #include its declaration.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
