Thread: Re: pga3: problem

Re: pga3: problem

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas.Pflug@web.de]
> Sent: 23 May 2003 14:16
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: Re: pga3: problem
>
>
> Dave Page wrote:
>
> >>I have experienced the same problem with pga3 crashing when
> >>opening the
> >>options screen. Debug output is below.
> >>
> >>
> >
> >That's odd - it crashes here with that snapshot, but not if
> I compile
> >my own release build version.
> >
> >Andreas: any ideas? How are you compiling the snapshots?
> >
> I had this problem just before we changed to autoconf. I got a lot of
> crashes when the resource was loaded, it  while creating a
> combobox (but
> this didn't all the time), starting to drive me crazy. This went away
> without modification after I cleanly updated from cvs.
>
> Right now, I only do "bootstrap" (if makefile.am was modified) and
> "make"; config.status will do its job automatically.
> On W32, I use the unmodified cvs pgAdmin3.dsp and
> pgAdmin3.dsw versions.

On the linux snapshots we actually clear the whole tree and get a fresh
copy, but this is one of your Windows builds from yesterday that's
crashing. Does it work for you (the release build)?

Regards, Dave.

pgAdmin3 resources

From
Andreas Pflug
Date:
Dave Page wrote:

>
>On the linux snapshots we actually clear the whole tree and get a fresh
>copy, but this is one of your Windows builds from yesterday that's
>crashing. Does it work for you (the release build)?
>
>
>
Are you talking about the latest 20030522-Win32 build on
snake.pgadmin.org? This includes an update frmOptions.xrc (2003-05-21
4464 bytes), which includes a freshly added control. If this file is too
old (missing this control), pgAdmin3 will crash.

I'll take this chance to describe how pgAdmin3 tries to locate resources
(mark this mail for later documentation :-)

pgAdmin3 will load all *.xrc files from the ui/common directory first,
then from the ui/win32 or ui/gtk directory. If a resource is present in
both directories, the platform specific version will win (that's how the
wxWindows implementation works now, to avoid future trouble a resource
should be present in one directory only).

On Win32, the standard location for the ui directory is relative to the
pgAdmin3.exe binary (aka loadPath) e.g.
c:\program files\pgAdmin3\pgAdmin3.exe
c:\program files\pgAdmin3\ui\common\*.xrc
c:\program files\pgAdmin3\ui\win32\*.xrc

On Linux, the location is determined by configure values; usually they
go to /usr/local/pgadmin3 (currently, they go to
user/local/pgadmin3/shared/pgadmin3, we should fix this unnecessary long
paths), so standard is /usr/local/pgadmin3/ui/common and
/usr/local/pgadmin3/ui/gtk.

To make developer's life easier (i.e. debugging without installing), for
both systems there are alternative directory locations.
On Win32, if no resource is found under loadPath/ui/common, files are
loaded from loadPath/../ui/common; same is done for ui/win32. This is to
reflect the project directory layout that the VC IDE creates, which will
put the pgAdmin3.exe in the ./Debug or ./Release directory, so ./ui is
under ../ui relative to the pgAdmin3.exe.

On Linux, similar things happen. If $(datadir)/ui/common contains no xrc
files loadPath/ui/common is used instead. Same is performed for ui/gtk.
Here, the freshly compiled pgAdmin3 will reside in the same directory as ui.

If necessary, we might restrict the alternate load location with a
command line option.

Regards,
Andreas