No… I tried that and it was ok…[/quote]
There might be some subtle difference between your development toolchain and ours. What VS version (inc service pack level) and Windows SDK do you use on your Win7 development machine?
Did you try building Bram’s test program on Win7 with VS2010 (without any changes to his Introjucer project) and running it on Win8? That would at least rule out any compiler/linker flags being the root of the problem.
I’m using the latest patched VS2010. I think that it was a 32-bit build I’m running though - are you guys using 64-bit? If so that’d use the 7.1 SDK rather than whatever version comes as default in VS2010.
I’m doing 32-bit builds…
Anyone could run the faulty binary in a debugger to figure out why the offsets are wrong ?
OK, possible solution…
I built Bram’s project on Win7 with “Optimisation = Optimise for maximum speed” in Introjucer, and the bug disappears on Win8. Rebuilt with the original “Optimise = Optimise for size and speed”, and the bug reappeared. No idea what the root cause might be yet, but would be good if others can confirm this finding.
(The way Introjucer maps this option into VS2010 does seem a little odd. “Optimise for size and speed” maps onto “Minimize Size (/O1)” in VS2010. Not what most of us want for a release binary, but it’s the default setting for a new Introjucer project. “Optimise for maximum speed” maps onto the much healthier “Maximise Speed (/O2)”. There seems to be no way in Introjucer to select the sexy sounding “Full Optimization (/Ox)” in Visual Studio, although I’m not entirely why this might be better than “Maximize speed (/O2)”)
None of those settings break it for me (I tried heaps of combinations).
Ah… Yes, occasionally there’s a strange compiler bug that pops up. Here’s another thread:
http://rawmaterialsoftware.com/viewtopic.php?f=3&t=4944
Seems like the MS compiler can sometimes screw up the floating point behaviour in a way that makes the graphics go haywire.
I’m facing the same problem. I’m testing on Windows 8, French. Could it be that the problem happens on non-English language systems?
I was getting the problem with a standard Win8 English language install. To fix the problem, I had to upgrade my projects from VS2008 to VS2010 on my Win7 dev machine (in addition to the optimisation tweak above). I couldn’t find any VS2008 config on Win7 that worked on Win8. But as this is quite a nebulous problem - some developers aren’t seeing the bug at all - there’s probably no guarantee that my fix will work for you.
But the problem only appears on Messages Boxes so far, right?, so maybe its not to hard to find a “work-around”, and change the way how text is drawn on Messages Boxes.
Disabling JUCE_USE_DIRECTWRITE (JUCE_USE_DIRECTWRITE=0 in settings) did it for me. 
Thanks for the workaround.
Hmm. Ok, but that’s treating the symptom, not the cause. Wish I could track it down, but compiler errors are very elusive…
Has this been fixed?
I’ve not even reproduced it, let alone fixed it!
This need to be fixed!
funny,
release build -> run with debugging -> ok!
release build -> run without debugging -> wrong layout
maybe uninitialized values…?
Do you mean the difference is whether you run it using the debugger, or whether you build it with debug info?
If the only difference is whether the debugger is attached, then no, it’s definitely not uninitialised data. It must be that there’s a different OS behaviour in some way, though I can’t think why that’d be the case…
Its when running the release Build without debug info.
If you see the graphics, which could be the variable which is wrong? Maybe this information would be helpful to spot the problem.
[attachment=0]wrong_offset.png[/attachment]
Tried a release build of a couple of my apps, and have no problems like that. Also had a quick look in the DWrite code, and can’t see any uninitialised variables (Pah! As if I’d do such a thing anyway!)
Can you suggest a simple test program that triggers it?
