[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

RE: [XaraXtreme-dev] BaseStr::MakeMsg problems

Gerry,

Thanks for that. No, I have no need to fix it for 0.4. In fact the
stuff that's using it can't be checked in for 0.4 anyway. It looks like
this will magically fix itself when your stuff comes along.

BTW I thought CCLexFile etc. was working?

Alex

--On 10 April 2006 22:44 +0100 Gerry Iles <GerryI@xxxxxxxx> wrote:


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