From: | Dinesh Kumar <dinesh(dot)kumar(at)enterprisedb(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | "pgadmin-support(at)postgresql(dot)org" <pgadmin-support(at)postgresql(dot)org>, John Foelster <johnfoelster(at)comcast(dot)net> |
Subject: | Re: Password setting having somewhat bizarre results. |
Date: | 2013-09-24 18:21:53 |
Message-ID: | CAKWsr7itxgYYjyo8TZVOZvoQ1-htCuEwJsCj4F2VLzgBkX2wwA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
Hi Dave,
Today, i have spend some time on this issue. But not able to figure out why
the event is not raising on single "delete" operation on the data control
combo box. I have tried to debug the wxMac's "src/generic/datectlg.cpp",
"OnText" method which is working fine in Linux but not in mac. But no luck.
Hence, like to request you to share your valuable suggestions.
Thanks in advance.
Dinesh
--
*Dinesh Kumar*
Software Engineer
Ph: +918087463317
Skype ID: dinesh.kumar432
www.enterprisedb.co
<http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
*
Follow us on Twitter*
@EnterpriseDB
Visit EnterpriseDB for tutorials, webinars,
whitepapers<http://www.enterprisedb.com/resources-community> and
more <http://www.enterprisedb.com/resources-community>
On Sat, Sep 7, 2013 at 12:09 AM, Dinesh Kumar <dinesh(dot)kumar(at)enterprisedb(dot)com
> wrote:
> Hi Dave,
>
> I have setup the mac build for testing this case.
>
> Further to my observation, if we perform the multiple "delete operations"
> like 2 to 3 on the same date control, then it's behaving as expected. I
> have tried a lot to figure out the cause why it's not raising an Event of
> EVT_CALANDER_SEL_CHANGED, EVT_DATE_CHANGED on mac for the single "delete
> operation", but unable to find out the reason.
>
> I will work on this parallel and will update you the status very soon.
>
> Thanks for your time.
>
>
> Dinesh
>
> --
> *Dinesh Kumar*
> Software Engineer
>
> Ph: +918087463317
> Skype ID: dinesh.kumar432
> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
> *
> Follow us on Twitter*
> @EnterpriseDB
>
> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community> and
> more <http://www.enterprisedb.com/resources-community>
>
>
> On Fri, Aug 30, 2013 at 9:08 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> On Fri, Aug 30, 2013 at 4:33 PM, Dinesh Kumar
>> <dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
>> > H
>> > i Dave,
>> >
>> >
>> > On Fri, Aug 30, 2013 at 8:58 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> >>
>> >> Hi
>> >>
>> >>
>> >> On Fri, Aug 30, 2013 at 4:18 PM, Dinesh Kumar
>> >> <dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> - Changing the time, but not the date, on an existing expiration
>> >>>> datetime, doesn't generate SQL and enable the OK button. Changing
>> just the
>> >>>> date does.
>> >>>
>> >>>
>> >>> Apologies Dave. I am not able to explain you the problem properly. But
>> >>> below are my findings.
>> >>>
>> >>> Further to my observation, it's not generating the event of
>> >>>
>> >>> EVT_SPIN(XRCID("timValidUntil"), dlgRole::OnChangeSpin)
>> >>>
>> >>> which is in pg_Roles.cpp. If the spin event occurs on spin button,
>> then
>> >>> it's directly going to
>> >>> "EVT_SPIN_x" in timespin.cpp. And also, i have observed that
>> >>> wxTimeSpinCtrl is our custom data type which we have been derived
>> from the
>> >>> wxControl class. That may be the reason the spin control event is
>> directly
>> >>> refering to timespin.cpp's EVT_SPIN_x functions. I have fixed this
>> issue
>> >>> by appending an dlgRole's event to timespin.cpp's event and it is
>> working
>> >>> fine.
>> >>>
>> >>> Kindly let me know if anything is unclear.
>> >>
>> >>
>> >> OK, that seems reasonable. Did you check if it breaks any other usage
>> of
>> >> that control?
>> >>
>> >
>> > Thanks Dave. I will verify this.
>> >
>> >> I wonder if, for 1.20, we should think about adding a 3rd party (or
>> >> creating a new) datetime control that we can use universally.
>> >>
>> >
>> >
>> > Yes true.
>> >
>> >>>
>> >>>>
>> >>>>
>> >>>> - If I clear the date and time, SQL is not generated to reset the
>> valid
>> >>>> until time to infinity.
>> >>>>
>> >>>
>> >>> If the role's "rolvaliduntil" property is NULL or infinity then there
>> is
>> >>> no password expiration for that user/role. I believe, in your case the
>> >>> "rolvaliduntil" might be the NULL. Hence, it's not generating any
>> "VALID
>> >>> UNTIL 'infinity'" since, NULL ~ infinity and also we haven't changed
>> >>> anything. In the rest of the cases, i believe it will generate as you
>> >>> suggested.
>> >>>
>> >>> Kindly let me know if i miss anything here.
>> >>
>> >>
>> >> Yeah, I think you misunderstood me:
>> >>
>> >
>> >
>> >>
>> >> 1) Create a new role, and set VALID UNTIL to some value. Close the
>> >> dialogue.
>> >>
>> >> 2) Open the properties dialogue, then clear the date/time fields. That
>> >> should cause the dialogue to attempt to set VALID UNTIL to infinity,
>> but
>> >> doesn't.
>> >>
>> >
>> > Sorry Dave. :(
>> >
>> > I am not able to re-produce the above case in windows/Linux. I don't
>> have
>> > mac setup to test this. :(
>>
>> Hmm, OK - it seems it does work on Windows. Well, maybe this is a good
>> time for you to setup a Mac build environment :-).
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2013-09-25 13:44:09 | Re: Password setting having somewhat bizarre results. |
Previous Message | Gang Liang | 2013-09-22 15:45:01 | Re: Bug report: pgAdmin III quit when pressing F1 or selecting "Postgresql Help" menu item |