Thread: CVS Commit by dpage: Allow query cancel/terminate

CVS Commit by dpage: Allow query cancel/terminate

From
cvs@cvs.pgadmin.org
Date:
Log Message:
-----------
Allow query cancel/terminate

Modified Files:
--------------
    pgadmin3/src/include:
        frmStatus.h (r1.10 -> r1.11)


Attachment

Re: CVS Commit by dpage: Allow query cancel/terminate

From
Andreas Pflug
Date:
cvs@cvs.pgadmin.org wrote:

>Log Message:
>-----------
>Allow query cancel/terminate
>
>
>

Hm,
I'm not too happy about "Hi there, I did it" message boxes. Do we need
that at all? Then we should add a status bar.
Should we use wxDEFAULT_NO on the security question msg box?

IMHO cancel/terminate is also usable on the locks page, so the buttons
could go to the top line.

Regards,
Andreas


Re: CVS Commit by dpage: Allow query cancel/terminate

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 22 June 2004 14:35
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] CVS Commit by dpage: Allow
> query cancel/terminate
>
> cvs@cvs.pgadmin.org wrote:
>
> >Log Message:
> >-----------
> >Allow query cancel/terminate
> >
> >
> >
>
> Hm,
> I'm not too happy about "Hi there, I did it" message boxes.

I think they are needed as sending signals doesn't always work, or they
may be a slight delay before they get handled - you need something to
stop the user clicking the button repeatedley if things don't happen
instantly.

> Do we need that at all? Then we should add a status bar.
> Should we use wxDEFAULT_NO on the security question msg box?

Probably, I'll add that.

> IMHO cancel/terminate is also usable on the locks page, so
> the buttons could go to the top line.

Hmm, I guess so. I'm inclined to leave them at the bottom though as the
top will be getting crowded. Bottom should be reminiscent of the Windows
task manager... Might have to wait 'till tomorrow for that one.

BTW, on the restore dialogue, the 'contents' tab doesn't seem to do
anything useful (nor for that matter does the view button).

Regards, Dave.

Re: CVS Commit by dpage: Allow query cancel/terminate

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of Dave Page
> Sent: 22 June 2004 15:25
> To: Andreas Pflug
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] CVS Commit by dpage: Allow
> query cancel/terminate
>
>
> > Do we need that at all? Then we should add a status bar.
> > Should we use wxDEFAULT_NO on the security question msg box?
>
> Probably, I'll add that.

'cept there doesn't appear to be any such thing for a wxMessageBox...

/D

Re: CVS Commit by dpage: Allow query cancel/terminate

From
Andreas Pflug
Date:
Dave Page wrote:

>>
>>
>>
>>>Do we need that at all? Then we should add a status bar.
>>>Should we use wxDEFAULT_NO on the security question msg box?
>>>
>>>
>>Probably, I'll add that.
>>
>>
>
>'cept there doesn't appear to be any such thing for a wxMessageBox...
>
>

so let's call it wxNO_DEFAULT :-)


Regards,
Andreas





Re: CVS Commit by dpage: Allow query cancel/terminate

From
Andreas Pflug
Date:
Dave Page wrote:

>
>BTW, on the restore dialogue, the 'contents' tab doesn't seem to do
>anything useful (nor for that matter does the view button).
>
>
Did you select a valid file? It should retrieve (-l) the contents for
distinct selection and restoration of objects.
I'm trying to finish the gui for LinuxTag, not necessarily implementing
all detail stuff immediately. Will complete that next week.

Regards,
Andreas



Re: CVS Commit by dpage: Allow query cancel/terminate

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 22 June 2004 16:13
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] CVS Commit by dpage: Allow
> query cancel/terminate
>
> Dave Page wrote:
>
> >
> >BTW, on the restore dialogue, the 'contents' tab doesn't seem to do
> >anything useful (nor for that matter does the view button).
> >
> >
> Did you select a valid file? It should retrieve (-l) the
> contents for distinct selection and restoration of objects.
> I'm trying to finish the gui for LinuxTag, not necessarily
> implementing all detail stuff immediately. Will complete that
> next week.

I see what's happening. I dump things in text format more often than
not, and that's what it's barfing on. I think that needs to be handled a
lttle more cleanly when we release - perhaps check the file format
before passing it to pg_restore, and if text, just load the first
hundred lines or so for inspection.

Whilst we're on that subject, most of my backups have .sql extensions -
any objection to adding that as a defaul extension in the file open
dialogue.

Finally, on a vaguely related note, I think we need to do some
re-factoring of the context and tools menus. Perhaps have a copy of the
tools menu as a sub menu of the context menu, rather than a seemingly
random inclusion of some items. Also, when items are active could do
with some though - for example, you cannot access the server status when
clicking a server node(!), only a database. Any thoughts?

Regards, Dave

Misc topics

From
Andreas Pflug
Date:
Dave Page wrote:

>
>
>I see what's happening. I dump things in text format more often than
>not, and that's what it's barfing on. I think that needs to be handled a
>lttle more cleanly when we release - perhaps check the file format
>before passing it to pg_restore,
>
Ok, checking the file signature seems reasonable.

> and if text, just load the first hundred lines or so for inspection.
>
>
No. Advice to use Query Tool instead or sth like that.

>Whilst we're on that subject, most of my backups have .sql extensions -
>any objection to adding that as a defaul extension in the file open
>dialogue.
>
>
For backup only, not restore; we don't want to offer arbitrary scripts
to pg_restore.

>Finally, on a vaguely related note, I think we need to do some
>re-factoring of the context and tools menus. Perhaps have a copy of the
>tools menu as a sub menu of the context menu, rather than a seemingly
>random inclusion of some items. Also, when items are active could do
>with some though - for example, you cannot access the server status when
>clicking a server node(!), only a database.
>
Well, if you insist we might enable server status on servers too :-)
I admit we should have a look at the context menu. I deliberately left
backup/restore out of it, because it's not so often in use, though it
belongs there.

Maybe we should *create* the context menu on-demand, instead of
enabling/disabling. Disabled menus always signal "this item might be
enabled under some circumstances", which is usually not true in that
very context.

Regards,
Andreas