Postgres Pro
Downloads
Home   >   mailing lists

Thread: Mac OS "crash"

Mac OS "crash"

From
"Adam H. Pendleton"
Date:
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"

From
"Hiroshi Saito"
Date:
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"

From
Andreas Pflug
Date:
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"

From
Adam H.Pendleton
Date:
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"

From
Andreas Pflug
Date:
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