Hi, my DX10 program works fine when, on initialisation, I create a font as
follows:

D3DX10CreateFont(m_pDevice,
SmallFont, 0,
FW_BOLD,
1,
FALSE,
DEFAULT_CHARSET,
OUT_DEFAULT_PRECIS,
DEFAULT_QUALITY,
DEFAULT_PITCH | FF_DONTCARE,
L"Arial",
&m_pFont);
assert(m_pFont);
CurrentFont=1;

D3DX10CreateSprite(m_pDevice, m_uiMAX_CHARS_PER_FRAME, &m_pFontSprite);

However, if I try to change the size of the font using:

[Please do not mail me a copy of your followup]

By "crash", I'm assuming you mean something like an access violation
exception. This means you have a bug in your code somewhere relating to
the use of pointers.

Any "change" is a bad point for DX (also for OpenGL too),
actually for DX10 with many internal closed solutions in
Vista.
Manually u must call lost device, reset, and reinit scene to see
the changes.

IMHO good idea is to prepare few sets of prerequisites fonts to
be more compatible with XNA too.
Look at your FONT likes on sets of pre-rendered sprites with
"looks like a letters".

Thanks Richard, but do you know how to change the font once it has already
been initialised?

Steg
"Richard [Microsoft Direct3D MVP]" wrote:

[Please do not mail me a copy of your followup]

=?Utf-8?B?U3RlZw==?= discussions.microsoft.com> spake the secret code
<841B0F53-6DDA-4059-8CE1-9F1DCC4D8352@microsoft.com> thusly:

The problem is not changing the font; the problem is that however you're
using the pointers in your program is causing a crash.

OK, the pointer involved is m_pFont.

If I call SafeRelease in function SetFontLarge this creates an immediate
problem. If I just go ahead and call D3DX10CreateFont in SetFontLarge things
work but the program eventually crashes due to the memory leak.

So, I understand what you are saying about it being a pointer problem, but
what is the correct way to associate a new font with the device?

Thanks, Steg

"Richard [Microsoft Direct3D MVP]" wrote:

[Please do not mail me a copy of your followup]

I'm saying you need to debug your crash before anything else. If you
use bogus pointers when trying to manipulate the device properly, it
will crash. If you use bogus pointers while trying to improperly
manipulate the device it will crash.

First, fix the crash. D3D doesn't crash on its own. You have to give
it bad pointers for it to crash.

Steg discussions.microsoft.com> wrote:

[Please do not mail me a copy of your followup]

Tim Roberts probo.com> spake the secret code
4ax.com> thusly:

I've asked MS that question many times when it comes to the samples and
why they don't exhibit best practices, but they always seem to have an
excuse.

One problem with CComPtr<> (but not _com_ptr_t, IIRC) is that CComPtr<>
is part of ATL and ATL isn't included with the Express editions of
Visual C++.