Works fine on Win2k. Is there a known reason the GetObject call could fail? Is there something that needs to be initialised before calling it that's done on Win2K, but not 98? Or are the only ways it can fail things like resource exhaustion?
I don't actually have a win98 machine to test with, but I can get the user to download a new version of ConflictSolver and test a work-around or fix.
Works fine on Win2k. Is there a known reason the GetObject call could fail? Is there something that needs to be initialised before calling it that's done on Win2K, but not 98? Or are the only ways it can fail things like resource exhaustion?
I don't actually have a win98 machine to test with, but I can get the user to download a new version of ConflictSolver and test a work-around or fix.
This sounds vaguely familiar, but I don't remember any details...
Does switching to the non-unicode version help? BTW, unless you have a non-NT mahcine to test thoroughly on I reccommend that you don't use the unicode version if it is going to be distributed to boxes with win9x. The MSLU layer is not a very good emulation of the wide char APIs...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Urgh. Well, I suppose I will have to castigate those who urged me to switch the entire system to unicode. Sigh. I guess we'll see what happens when I install the non-unicode version. Hopefully the python wrappers will do the right thing by encoding the values in the default local encoding. If not, it will break all over the place .
Thanks for giving me the lay of the land,
Mike
Robin Dunn wrote:
...
···
This sounds vaguely familiar, but I don't remember any details...
Does switching to the non-unicode version help? BTW, unless you have a non-NT mahcine to test thoroughly on I reccommend that you don't use the unicode version if it is going to be distributed to boxes with win9x. The MSLU layer is not a very good emulation of the wide char APIs...
This sounds vaguely familiar, but I don't remember any details...
It was in response to a problem I had, back in November. I was getting the
same LOGFONT error message from an executable I had built using Installer
and running under Win 98. It *was* to do with Unicode and was cured by
including unicows.dll in the Install'ed package. I guess, Mike, that you
need to do something similar with your p2exe'd app in order to continue
using unicode.
Regards,
David Hughes
Forestfield Software Ltd
www.forestfield.co.uk
···
Mike C. Fletcher wrote:
> This is in settings.cpp, with wxPython 2.4.0.2u in a py2exe'd
> application. The code in settings.cpp does this:
>
> LOGFONT lf;
> if ( ::GetObject(hFont, sizeof(LOGFONT), &lf) != 0 )
> {
> ...
> } else {
> wxFAIL_MSG(...)
> }
>
> Works fine on Win2k. Is there a known reason the GetObject call
> could fail? Is there something that needs to be initialised before
> calling it that's done on Win2K, but not 98? Or are the only ways it
> can fail things like resource exhaustion?
>
> I don't actually have a win98 machine to test with, but I can get the
> user to download a new version of ConflictSolver and test a
> work-around or fix.
This sounds vaguely familiar, but I don't remember any details...
Does switching to the non-unicode version help? BTW, unless you have a
non-NT mahcine to test thoroughly on I reccommend that you don't use
the unicode version if it is going to be distributed to boxes with
win9x. The MSLU layer is not a very good emulation of the wide char
APIs...
This sounds vaguely familiar, but I don't remember any details...
It was in response to a problem I had, back in November. I was getting the same LOGFONT error message from an executable I had built using Installer and running under Win 98. It *was* to do with Unicode and was cured by including unicows.dll in the Install'ed package. I guess, Mike, that you need to do something similar with your p2exe'd app in order to continue using unicode.
Ah yes. Thanks for reminding us!
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
.