[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] BaseStr::MakeMsg problems
- From: "Gerry Iles" <GerryI@xxxxxxxx>
- Date: Mon, 10 Apr 2006 22:44:46 +0100
- Subject: RE: [XaraXtreme-dev] BaseStr::MakeMsg problems
These should really be left as they are. In an effort to resolve this
issue (among others) I have made lots of changes in my working copy that
changes the string function usage to use new camStrcpy type functions
that map to the wx equivalents. This means that %s will always mean a
TCHAR string as wx does the translation you suggest on OSes that require
it. This also removes the need for the PERCENT_ macros.
I can't really check this in until after 0.4 though as the changes are
very widespread.
There is still quite a lot of code (that is mostly not compiled at
present) that will not currently work correctly due to char/TCHAR
mismatches (e.g. CCLexFile and most of the text based filter types such
as EPS).
If you need to fix something for 0.4 then I suggest you redefine
tsprintf (and any related functions) as the wx equivalent (e.g.
wxSnprintf) and change the PERCENT_ macros to be just %s and %c. This
should still compile and should fix you issue with MakeMsg for the time
being...
Gerry
-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 10 April 2006 21:04
To: xara-dev
Cc: Alex Bligh
Subject: [XaraXtreme-dev] BaseStr::MakeMsg problems
Gerry (mainly),
In BaseStr::MakeMsg(), it tries to interpret things like #1%s. It
decodes this to a %s which is merrilly passes to tsprintf.
In our string resource file, #1%s means a string, and this should
be independent of whether the build is unicode or not (we should
not need to retranslate resources to do a non-unicode build).
But tsprintf sees '%s' (it seems) as pointing to a non-unicode
string, so we only get the first letter. It wants "%ls" passed.
It's obviously an unreasonable requirement that this should
be in all the string definitions.
I could go fix this (write a tsprintf variant that goes through
and fixes up the format string), but I know we were looking
at Unicode bogosity. That's what I do on errors etc.
Where did you get to on this?
Alex