Re: Patch for EDB binary path not set by default.

As per your comments, you first need to check - it is 64 bit windows or
not, and then check it is 32 bit pgAdmin III.

Hence - the code should look like something like this:
*if (::wxIsPlatform64Bit() && programFiles == programFilesX86)*
*{*
*...*
* pgRegKey *pgKey = pgRegKey::OpenRegKey(HKEY_LOCAL_MACHINE,
wxT("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"),
pgRegKey::PGREG_READ, pgRegKey::PGREG_WOW64);
*
*...*
*}*

On Tue, Oct 29, 2013 at 3:37 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Ashesh - can you review/commit this please? I'm swamped at the moment.
> Thanks.
>
> On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
> <dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
> > Hi Dave,
> >
> > Thanks for your valuable inputs.
> >
> > On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >>
> >> Hi
> >>
> >>
> >> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
> >> <dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
> >>>
> >>> Hi Dave/Team,
> >>>
> >>> When we install a 32-bit pgAdmin-III in a windows 64-bit machine, which
> >>> is already having the 64-bit EnterpriseDB database installed, then EDB
> >>> binary path not set to by default.
> >>>
> >>> Further to my observation, below is the mechanism how the pgAdmin looks
> >>> for the PPAS binary path.
> >>>
> >>> A) Read the settings.ini for the entry "EnterpriseDBPath" and get the
> >>> value.
> >>>
> >>> B) Read the "EnterpriseDBPath" as a key in the registries. If the key
> is
> >>> not found, then create one key and assign the value of settings.ini
> file.
> >>>
> >>> C) If the registry is found, and still the value of "EnterpriseDBPath"
> is
> >>> null, then we are checking the %PATH% which will be having the
> "pg_dump.exe"
> >>> file and it's a type of "EnterpriseDB".
> >>>
> >>> D) If we don't find any "pg_dump.exe" edb version, then we go for the
> >>> default locations to search for the edb version.
> >>>
> >>> I have verified the above A, B and C cases, and those are working fine
> in
> >>> a 64-bit machine. But the case D is not working as expected in a 64-bit
> >>> machine. Hence, would like to submit a patch for this case.
> >>>
> >>> Kindly let me know your inputs on this patch.
> >>
> >>
> >> I don't think you can do it that way - what if the directory name
> doesn't
> >> end in "(x86)"? You can configure Windows to use any arbitrary
> directory for
> >> the Program Files folders. I suspect you'll need to use a preprocessor
> macro
> >> to handle the 32 vs. 64 bit cases accordingly.
> >
> > Sorry for the delay on this issue.
> >
> > I have done some google around the same problem, and found the solution
> to
> > use "programw6432" environment variable , if a 32 bit application runs
> in a
> > 64 bit machine. But, this option only works on windows 7 and windows
> 2008 R2
> > onwards. And after spending some time, i have found one suitable solution
> > for this case, which we need to read the key "ProgramFilesDir" from the
> > registry
> "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion",
> > and i have implemented this mechanism using pgRegKey.
> >
> > Here i have used, "wxIsPlatform64Bit()" as an alternative to preprocessor
> > macros.
> >
> > Kindly let me know your inputs on this patch.
> >
> > Thanks in advance.
> >
> > Regards,
> > Dinesh
> >>
> >>
> >> --
> >> Dave Page
> >> Blog: http://pgsnake.blogspot.com
> >> Twitter: @pgsnake
> >>
> >> EnterpriseDB UK: http://www.enterprisedb.com
> >> The Enterprise PostgreSQL Company
> >
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com>

*http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>