As it turns out i was slightly off - the failure is further down in
main3.cpp in
SetupSharedMenu()
GetMenuPreferences(_R(IDM_SHARED_MENU)) returns a null pointer.
also the if (menu_sym == keyword) part of GetMenuPreferences is never
visited for that call, but a MenuScript is sucessfully opened and
shows
this with p in gdb:
(gdb) p MenuScript
$8 = {
<CCResourceFile> = {
<CCMemFile> = {
<CCLexFile> = {
<CCFile> = {
<CCObject> = {
<SimpleCCObject> = {
static BytesBeforeFail = 0,
static FailingMemory = 0,
static CheckMemoryFlag = 0
},
members of CCObject:
_vptr$CCObject = 0x8f9cc8,
static cc_classCCObject = {
m_lpszClassName = 0x7ec2ec,
m_nObjectSize = 4,
m_wSchema = 65535,
m_pfnConstruct = 0,
m_pBaseClass = 0x0,
static pFirstClass = 0x8a91d4,
m_pNextClass = 0x7ec284
}
},
members of CCFile:
static cc_classCCFile = {
m_lpszClassName = 0x7d754c,
m_nObjectSize = 20,
m_wSchema = 65535,
m_pfnConstruct = 0,
m_pBaseClass = 0x7ec2d4,
static pFirstClass = 0x8a91d4,
m_pNextClass = 0x7d7388
},
ReportErrors = 1,
ThrowExceptions = 0,
CompressData = 0,
GZipErrorID = 0
},
members of CCLexFile:
static cc_classCCLexFile = {
m_lpszClassName = 0x7d750c,
m_nObjectSize = 136,
m_wSchema = 65535,
m_pfnConstruct = 0,
m_pBaseClass = 0x7d7534,
static pFirstClass = 0x8a91d4,
m_pNextClass = 0x7d7534
},
m_pcHTMLBuffer = 0x0,
m_iCharsInHTMLBuffer = 0,
m_iLengthOfHTMLBuffer = 0,
m_fIsTag = 0,
m_fIsCharacterWaiting = 0,
m_cWaitingCharacter = 0 '\0',
m_fEndOfHTMLFile = 0,
EOFFound = 0,
DontFail = 0,
DelimiterFound = 0,
TokenIsCached = 0,
LineBuf = 0x0,
Buf = 0x0,
TokenBuf = 0x0,
TokenType = TOKEN_EOF,
Line = 0,
Ofs = 0,
Ch = 0 '\0',
CharsRead = 0,
LastLinePos = 0,
SeekingRequired = 0,
IgnoreStringEscapeCodes = 0,
WhitespaceChars = 0x0,
DelimiterChars = 0x0,
CommentMarker = 0 '\0',
StringDelimiters = 0x0,
IndentSpaces = 0,
IndentDelta = 2415933273,
LexerInitialised = 0
},
members of CCMemFile:
static cc_classCCMemFile = {
m_lpszClassName = 0x7d743c,
m_nObjectSize = 168,
m_wSchema = 65535,
m_pfnConstruct = 0,
m_pBaseClass = 0x7d74f4,
static pFirstClass = 0x8a91d4,
m_pNextClass = 0x7d7464
},
MemHandle = 436,
MemFile = 0x238b4c00 "MENU \"SHARED\"\r\n\tSUBMENU \"FileMenu
\"\r\n\t\tSUBMENU \"FileNew\"\r\n\t\t\tMENUITEM \"FileNewDrawing
\"\r\n
\t\t\tMENUITEM \"FileNewAnimation\"\r\n\t\t\tMENUITEM
\"1FileNewTemplate\"\r\n\t\t\tMENUITEM \"2FileNewTemplate\"\r\n\t\t
\tMENUITEM \"3Fil"...,
FileSize = 5632,
CurrentPos = 0,
IsOpen = 1,
FileProt = 0,
WasError = 0,
MemFileInitialised = 1
}, <No data fields>}, <No data fields>}
anything I can do?
cheers,
dom
On 19.03.2006, at 12:12, Alex Bligh wrote:
--On 19 March 2006 12:03 +0100 Dominik Wagner
<dom@xxxxxxxxxxxxxxxx> wrote:
any suggestions?
Yes. This is the rather annoying "the Kernel doesn't initialize
problem".
What's happening is it's running through all the initialization in
main1.cpp, main2.cpp & main3.cpp, and something (looks like
something
quite far down) is failing. Error reporting isn't quite right under
LX so you aren't seeing the error. Annoyingly the list of
initializers
is one big if() statement with && between the calls so setting
breakpoints
is not easy.
You can often find these by putting a few breakpoints in wxOil/
errors.cpp
in Error::XSetError (all the various flavours) which /should/ find
what is
producing the error. If not, I'm afraid it's a case of stepping in
and out
of each of the various init jobs (put a breakpoint in the obvious
place in
each of main1, main2, main3.cpp) and finding which class ::Init
function is
returning FALSE (clearly finding which of the "main" files causes
the
problem is the first step). It's a little time-consuming, but
normally once
you've done that debugging why the init fails is pretty simple. I
guess is
something pretty recent as the Mac build used to init OK.
I expect you could insert something like
&& TRACE(_T("Got here"))
etc. into the init lists.
Alex
--
Dominik Wagner Mail: dom@xxxxxxxxxxxxxxxx
TheCodingMonkeys http://www.codingmonkeys.de/
Blog - DasGenie: !Scrap http://scrap.dasgenie.com/