Re: Patch for EDB binary path not set by default. - Mailing list pgadmin-hackers

Thanks Ashesh.

Let me send new patch as per the suggested changes.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 5:34 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

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@pgadmin.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.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.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.linkedin.com/in/asheshvashi