Re: I need to LoadString() programmatically based on ID not Value
"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message
news:Xns9C36B8F45D34MihaiN@207.46.248.16...
I am open to suggestions or alternate ideas. It seems like this might be
possible using FindResource and EnumResourceNames, but I am not sure how
to
go about using those as they are fairly cryptic.
In my experience a numeric string ID with resource-only DLL works best.
You don't have any conflicts
- because the numeric ID is really the resource-dll-handle + ID
- you can aboid naming conflicts by addopting a naming convention
So SHARED_IDS_PRINT is the stuff un the resource dll, IDS_PRINT can be
your
local stuff. (or G_ or GLOBAL_ or whatever you want)
You can just provide the dll and a header file.
I don't like the overhead of maintaining the numeric constants in the header
file. Even though resource.h is somewhat managed by the IDE, it does not do
things like renumber the id's to remove holes caused by deleting unused
strings, etc.
String IDs are slower,
Not necessarily... a good hash table/map/dictionary (whatever you call it)
causes performance to be quite good. Maybe not as good as an integer id,
but good enough.
and cannot be checked a compile time.
With numeric IDs, if I spell a string wrongly in code I get a compile time
error. With strings everything compiles well, and explodes 5 months later.
Same for XMLs and any other string-id based idea.
True, although this does not cause many problems in real life due to the
English file also using the string constants, and if there was a
misspelling, it would be caught in the English as well. Of course the
misspelling could be introduced by a localizer in the localized file only,
but as the localizer is focused on the value of the string and not the id, I
don't think the id is in great danger of being accidentally edited.
Besides, any localizer tool could take care of this automatically by not
making the id editable.
So I find not needing to maintain resource ID's a big win. Further, I am
finding the approach used by Qt of using the tr() macro to embed the literal
string directly in the source code to be refreshing indeed. The programmer
is entirely freed of managing strings in any resource; this is done by the
pre-compiler. You had previously said this approach causes issues as the
context is not apparent to localizers, and sometimes strings get
accidentally merged. The tr() macro allows you to specify a string for the
context, as well as full-blown comments to the localizer, to keep these
things straight.
-- David