Обсуждение: Mac OS "crash"

Поиск
Список
Период
Сортировка

Mac OS "crash"

От
"Adam H. Pendleton"
Дата:
Well pgAdmin3 on Panther runs and then suddenly exits, but it's not a
crash.  It's a clean exit when the program encouters a problem, but
there is no "sane" error handler for the problem.  The code in question is:

pgAdmin3.cpp:329

int count = wxDir::GetAllFiles(uiPath+COMMON_DIR, &files, wxT("*.xrc"),
wxDIR_FILES);
if (!count)
    return false;

On Panther count == 0, and since OnIni() just returns false, the program
just stops instead of printing an error.  There should probably be an
error handler here.  As for why GetAllFiles is returning 0, well, I
don't know.  The directory path seems okay ("/usr/local/pgadmin3/ui" +
"common") but it still loads nothing.  Any ideas?

ahp

Re: Mac OS "crash"

От
"Hiroshi Saito"
Дата:
Hi Adam.

From: "Adam H. Pendleton" <fmonkey@fmonkey.net>

> On Panther count == 0, and since OnIni() just returns false, the program
> just stops instead of printing an error.  There should probably be an
> error handler here.  As for why GetAllFiles is returning 0, well, I
> don't know.  The directory path seems okay ("/usr/local/pgadmin3/ui" +
> "common") but it still loads nothing.  Any ideas?

It looks like the conditions in Solaris9.
It failed by the UNICODE change at that time.
http://cre-ent.skcapi.co.jp/~saito/pgadmin3/Solaris9_debug1.jpg

It may not be helpful.:-(

regards,
Hiroshi Saito

Re: Mac OS "crash"

От
Andreas Pflug
Дата:
Adam H. Pendleton wrote:

> Well pgAdmin3 on Panther runs and then suddenly exits, but it's not a
> crash.  It's a clean exit when the program encouters a problem, but
> there is no "sane" error handler for the problem.  The code in
> question is:
>
> pgAdmin3.cpp:329
>
> int count = wxDir::GetAllFiles(uiPath+COMMON_DIR, &files,
> wxT("*.xrc"), wxDIR_FILES);
> if (!count)
>    return false;

Are the *.xrc files present there?
For testing purposes, you could change that #ifdef embracint that part
of code, to use embedded xrc dialogs instead of loading them from file.
Since usually xrc dialogs are piggy-backed on the executable, I didn't
bother about debug code here.

Regards,
Andreas


Re: Mac OS "crash"

От
Adam H.Pendleton
Дата:
On Mar 19, 2004, at 5:13 AM, Andreas Pflug wrote:

>>
> Are the *.xrc files present there?
> For testing purposes, you could change that #ifdef embracint that part
> of code, to use embedded xrc dialogs instead of loading them from
> file. Since usually xrc dialogs are piggy-backed on the executable, I
> didn't bother about debug code here.

Yeah, the .xrc files are there; the function should work as far as I
can tell.  I was going to try removing the "*.xrc" and see what
happened.  I will also try forcing the embedded XRC dialogs instead of
loading them.  Is there anything special I need to do to get that to
work, other than just adjusting the #ifdef...#endif code?

ahp


Re: Mac OS "crash"

От
Andreas Pflug
Дата:
Adam H.Pendleton wrote:

>
> On Mar 19, 2004, at 5:13 AM, Andreas Pflug wrote:
>
>>>
>> Are the *.xrc files present there?
>> For testing purposes, you could change that #ifdef embracint that
>> part of code, to use embedded xrc dialogs instead of loading them
>> from file. Since usually xrc dialogs are piggy-backed on the
>> executable, I didn't bother about debug code here.
>
>
> Yeah, the .xrc files are there; the function should work as far as I
> can tell.  I was going to try removing the "*.xrc" and see what
> happened.  I will also try forcing the embedded XRC dialogs instead of
> loading them.  Is there anything special I need to do to get that to
> work, other than just adjusting the #ifdef...#endif code?
>
No, just define EMBED_XRC. Even in debug compiles the xrc is linked to
the executable.

Regards,
Andreas