Thread: Re: Function editor

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of
> Andreas Pflug
> Sent: 09 October 2004 21:41
> To: tony.caduto@amsoftwaredesign.com
> Cc: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
>
> Provide a viable patch or shut up.

Steady on, this is supposed to be a friendly list and I'd prefer to keep
it that way.

Tony;

I appreciate your problem, however Andreas is correct - Windows returns
duff position/size values when windows are maximised or minimised. I
have exactly the same problem in pgAdmin II which was written in VB.

Andreas;

In previous apps like pgAdmin II I overcame this problem by only saving
the size/position if the form is normalised. If minimised or maximised
then I simply didn't bother writing the new sizes. Any reason this will
not work in the pga3 code? It might also be reasonable to record whether
the form is maxmised and restore that state if needed - certainly Word
and other Microsoft apps do that (that would have to wait for 1.4
though).

Regards, Dave.

Dave Page wrote:

> 
> In previous apps like pgAdmin II I overcame this problem by only saving
> the size/position if the form is normalised. If minimised or maximised
> then I simply didn't bother writing the new sizes. Any reason this will
> not work in the pga3 code? 

- There's no facility for that in wx
- We certainly dont want win32 gdi calls in pgadmin

This was discussed exhaustively earlier.

Regards,
Andreas

Hi Dave, 

In order to make everyone happy, it does not matter what values window 
returns from a minimize or maximize.  Why can't a option be added(a end user 
option) that when enabled the function editor window just maximizes 
automaticly when opened?
Most users want the window fully maximized anyway when writing a function.
Surely WxWidgets can accomplish something as trivial as what I am 
describing.
We are just talking about some simple if then logic to accomplish the task.
There is nothing wrong with adding a option like this to a app, it does not 
even have to be default, it just needs to be persistant if the end user 
enables it. 

Does everyone see what I am getting at? 

Thanks, 

T 



> 
> I appreciate your problem, however Andreas is correct - Windows returns
> duff position/size values when windows are maximised or minimised. I
> have exactly the same problem in pgAdmin II which was written in VB. 
> 

Hi,

Am Mo, den 11.10.2004 schrieb Tony Caduto um 3:36:
> Hi Dave, 
> 
> In order to make everyone happy, it does not matter what values window 
> returns from a minimize or maximize.  Why can't a option be added(a end user 
> option) that when enabled the function editor window just maximizes 
> automaticly when opened?
> Most users want the window fully maximized anyway when writing a function.
> Surely WxWidgets can accomplish something as trivial as what I am 
> describing.

Well, an option if dave/andreas feel like. 
I should say I'm not one of the "most" users
- I certainly dont want any window automatically
occupy a 1920x1440 screen.

Tino.

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 10 October 2004 21:16
> To: Dave Page
> Cc: tony.caduto@amsoftwaredesign.com; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
> Dave Page wrote:
>
> >
> > In previous apps like pgAdmin II I overcame this problem by only
> > saving the size/position if the form is normalised. If minimised or
> > maximised then I simply didn't bother writing the new sizes. Any
> > reason this will not work in the pga3 code?
>
> - There's no facility for that in wx

wxTopLevelWindow::IsIconized
wxTopLevelWindow::IsMaximized

Both wxFrame and wxDialog are derived from wxTopLevelWindow. Any reason
these cannot be used?

Regards, Dave

> -----Original Message-----
> From: Tino Wildenhain [mailto:tino@wildenhain.de]
> Sent: 11 October 2004 06:34
> To: Tony Caduto
> Cc: Dave Page; Andreas Pflug; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
> Hi,
>
> Am Mo, den 11.10.2004 schrieb Tony Caduto um 3:36:
> > Hi Dave,
> >
> > In order to make everyone happy, it does not matter what
> values window
> > returns from a minimize or maximize.  Why can't a option be added(a
> > end user
> > option) that when enabled the function editor window just maximizes
> > automaticly when opened?
> > Most users want the window fully maximized anyway when
> writing a function.
> > Surely WxWidgets can accomplish something as trivial as what I am
> > describing.
>
> Well, an option if dave/andreas feel like.
> I should say I'm not one of the "most" users
> - I certainly dont want any window automatically occupy a
> 1920x1440 screen.

No, I quite agree (1600x1280 here). The problem with adding such an
option is that we would have to do it consistently for all properties
dialogues, *or* have one setting for all. The first option would create
a ridiulously oversized options dialogue, and the second would affect
dialogues that the vast majority of ppl would certainly not want
maximised by default, if ever.

Regards, Dave.

Dave Page wrote:
>  
> 
> 
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] 
>>Sent: 10 October 2004 21:16
>>To: Dave Page
>>Cc: tony.caduto@amsoftwaredesign.com; pgadmin-support@postgresql.org
>>Subject: Re: [pgadmin-support] Function editor
>>
>>Dave Page wrote:
>>
>>
>>>In previous apps like pgAdmin II I overcame this problem by only 
>>>saving the size/position if the form is normalised. If minimised or 
>>>maximised then I simply didn't bother writing the new sizes. Any 
>>>reason this will not work in the pga3 code?
>>
>>- There's no facility for that in wx
> 
> 
> wxTopLevelWindow::IsIconized
> wxTopLevelWindow::IsMaximized
> 
> Both wxFrame and wxDialog are derived from wxTopLevelWindow. Any reason
> these cannot be used?

You discussed yourself it's not easily done in dlgProperty.
wxFrame does handle sizes correctly (frmMain etc, still has the maximize 
button), wxDlg not. I won't spent a second to find out why.

Regards,
Andreas

pgAdmin3 ver. 1.2.0 Post Beta2 (Oct 09 2004) crashes when I'm trying to
connect to a postgresql 7.4.2 database. Same behavior if I want to add a new
server. Was tested only on postgresql 8.0.0?

Postgres log:
Oct 11 13:10:59 linux postgres[2248]: [1-1] LOG:  connection received:
host=172.16.2.49 port=1358
Oct 11 13:10:59 linux postgres[2248]: [2-1] LOG:  connection authorized:
user=test database=ts
Oct 11 13:11:04 linux postgres[2248]: [3-1] LOG:  could not receive data
from client: Connection reset by peer
Oct 11 13:11:04 linux postgres[2248]: [4-1] LOG:  unexpected EOF on client
connection

Virgil

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 11 October 2004 10:25
> To: Dave Page
> Cc: tony.caduto@amsoftwaredesign.com; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
> You discussed yourself it's not easily done in dlgProperty.

I did? Sorry, don't remember that.

> wxFrame does handle sizes correctly (frmMain etc, still has
> the maximize button), wxDlg not. I won't spent a second to
> find out why.

No, I don't think spending time trying to find a workaround or fix in wx
is a good use of time. Any reason why the following might cause any
undesirable side effects though? It certainly appears to solve the
reported problem.

Regards, Dave


Index: src/ui/dlgClasses.cpp
===================================================================
RCS file: /projects/pgadmin3/src/ui/dlgClasses.cpp,v
retrieving revision 1.14
diff -u -r1.14 dlgClasses.cpp
--- src/ui/dlgClasses.cpp    10 Oct 2004 17:25:44 -0000    1.14
+++ src/ui/dlgClasses.cpp    11 Oct 2004 10:18:37 -0000
@@ -96,7 +96,8 @@void pgDialog::SavePosition(){
-    settings->Write(dlgName, GetSize(), GetPosition());
+    if (!IsMaximized() && !IsIconized())
+        settings->Write(dlgName, GetSize(), GetPosition());}void pgDialog::LoadResource(wxWindow *parent, const wxChar
*name)
@@ -255,7 +256,8 @@void pgFrame::SavePosition(){
-    settings->Write(dlgName, GetSize(), GetPosition());
+    if (!IsMaximized() && !IsIconized())
+        settings->Write(dlgName, GetSize(), GetPosition());}
Index: src/ui/dlgProperty.cpp
===================================================================
RCS file: /projects/pgadmin3/src/ui/dlgProperty.cpp,v
retrieving revision 1.98
diff -u -r1.98 dlgProperty.cpp
--- src/ui/dlgProperty.cpp    8 Oct 2004 10:18:51 -0000    1.98
+++ src/ui/dlgProperty.cpp    11 Oct 2004 10:18:37 -0000
@@ -89,10 +89,6 @@    wxWindowBase::SetFont(settings->GetSystemFont());    LoadResource(frame, resName);
-#ifdef __WXMSW__
-    SetWindowStyleFlag(GetWindowStyleFlag() & ~wxMAXIMIZE_BOX);
-#endif
-    nbNotebook = CTRL_NOTEBOOK("nbNotebook");    if (!nbNotebook)    {
@@ -118,9 +114,11 @@dlgProperty::~dlgProperty(){    wxString prop = wxT("Properties/") +
wxString(typesList[objectType].typName);
-    settings->Write(prop, GetPosition());
-    if (GetWindowStyle() & wxTHICK_FRAME)
+    if (!IsMaximized() && !IsIconized())
+        settings->Write(prop, GetPosition());
+
+    if ((GetWindowStyle() & wxTHICK_FRAME) && !IsMaximized() &&
!IsIconized())        settings->Write(prop, GetSize());}

Virgil Frum wrote:
> pgAdmin3 ver. 1.2.0 Post Beta2 (Oct 09 2004) crashes when I'm trying to
> connect to a postgresql 7.4.2 database. 

Please enable full logging to trace down the reason.

Regards,
Andreas

Debug logging doesn't seem to be useful in this case:

2004-10-11 15:20:26 STATUS : Retrieving server properties...
2004-10-11 15:20:26 INFO   : Displaying properties for Server
172.16.2.47:5432
2004-10-11 15:20:26 INFO   : Displaying properties for server
172.16.2.47:5432
2004-10-11 15:20:26 STATUS : Retrieving server properties... (0.00 secs)
2004-10-11 15:20:26 INFO   : Attempting to create a connection object...
2004-10-11 15:20:26 INFO   : Creating a connect dialogue
2004-10-11 15:20:30 INFO   : Destroying a connect dialogue
2004-10-11 15:20:30 STATUS : Connecting to database...
2004-10-11 15:20:30 INFO   : Creating pgConn object
2004-10-11 15:20:30 INFO   : Server name: 172.16.2.47 (resolved to:
172.16.2.47)
2004-10-11 15:20:30 INFO   : Opening connection with connection string:
hostaddr='172.16.2.47' dbname='ts' user='test' password='password' port=5432

I've attached tcpdump's output of crashing session. Last client's
(172.16.2.49) packet is a TCP reset. My database has client_encoding =
'UNICODE'.

Virgil

> > pgAdmin3 ver. 1.2.0 Post Beta2 (Oct 09 2004) crashes when I'm trying to
> > connect to a postgresql 7.4.2 database.
>
> Please enable full logging to trace down the reason.

Virgil Frum wrote:
> Debug logging doesn't seem to be useful in this case:

Hm, I don't see too much either.
Is that my win32 snapshot? Do you have a stack trace (Dr.Watson)?

Regards,
Andreas

You do realize that have a monitor that large is not the norm right?
I myself have a 19inch LCD and it's max resolution is 1280x1024 and I 
maximize all my windows when editing in any app.
I keep VS.net maximised all the time along with Delphi 7, if I open up a 
Open Office writer doc, I maximize it.
With standard windows apps this is not a issue because you can simply click 
on the task bar and move to any other open app, you can't seem to do this 
with PGAdmin either because the function editor does not show in the task 
bar because it's form style is set to be a dialog.
In my opinion the function editor should not be considered a dialog like the 
sequence properties is, it works for the sequence because you don't edit any 
text with it.
Not having the function editor in the task bar cuts down on productivity 
because it's difficult to have more than 1 open at a time, you can do it,but 
you have to drag them around on the screen because they open right on top of 
each other and because they don't go to the background they block the main 
form of the application. 

Maybe if I had a huge monitor I might change my habits, but I like many many 
others don't. 

I work for a large corp and most of the PC's in the wild are still running 
at 800x600 or 1024x768. 

Now if you were running at one of these lower resolutions wouldn't you want 
to maximize the editor window? 


The funciton editor is the one place that really needs some improvement to 
increase productivity. 

I am not trying to be a jerk about this, just pointing out the facts. 




> Well, an option if dave/andreas feel like. 
> I should say I'm not one of the "most" users
> - I certainly dont want any window automatically
> occupy a 1920x1440 screen. 
> 
> Tino. 
> 

> Hm, I don't see too much either.
> Is that my win32 snapshot? Do you have a stack trace (Dr.Watson)?

Binary size (less than previous version): 5.500.928 bytes (CRC32: 1DA3940B;
MD5: F86F0A85151495DD4C74EFA7DFBD9F89), timestamp: 09.10.2004 23:39:08. Dr.
Watson's stack trace attached.

Virgil

Tony Caduto wrote:
> You do realize that have a monitor that large is not the norm right?
> I myself have a 19inch LCD and it's max resolution is 1280x1024 and I 
> maximize all my windows when editing in any app.
> I keep VS.net maximised all the time along with Delphi 7, if I open up a 
> Open Office writer doc, I maximize it.
> With standard windows apps this is not a issue because you can simply 
> click on the task bar and move to any other open app, you can't seem to 
> do this with PGAdmin either because the function editor does not show in 
> the task bar because it's form style is set to be a dialog.

Right. That's why maximize isn't cleanly supportable. I'm strictly 
against redesigning pgadmin property dialogs as frames, and thus 
flooding the taskbar.

BTW, I use 1152...1200 on my monitors.
Regards,
Andreas

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of
> Andreas Pflug
> Sent: 11 October 2004 15:27
> To: Tony Caduto
> Cc: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
> Right. That's why maximize isn't cleanly supportable. I'm
> strictly against redesigning pgadmin property dialogs as
> frames, and thus flooding the taskbar.

Yeah, definitely with you on that one.

Back in the old pga2 days, we used to use a control developed by the
quietest member of the devteam (Mark) for all the multiline edit boxes.
It had a handy feature in that it had it's own maximise button which
would maximise it to fill it's parent frame. This was actually quite
elegant and worked rather well. Before pgAdmin 3 was started, we had
toyed with the idea of making the textbox detachable (this is roughly
the point at which Andreas' head will probably explode :-) ) into a
mini-editor.

Now, if we added such a control to pga3, we could immediately make all
the dialogues back into 'real' dialogues. All we would need to do is
figure out how the detachable editor should behave (modally speaking for
example) with respect to it's parent dialogue and the rest of the app
for it to be able to work in a fashion that's acceptable and liked by
all.

Thoughts (preferrable constructive)?

Regards, Dave.

Virgil Frum wrote:
>>Hm, I don't see too much either.
>>Is that my win32 snapshot? Do you have a stack trace (Dr.Watson)?
> 
> 
> Binary size (less than previous version): 5.500.928 bytes

The reason is that we now use libpq dynamically linked. The libpq 
packaged in that zip should work with both pgAdmin and pg_dump/pg_restore.

OK, I found out what's happening. I've been testing with the correct 
versions from 
http://pgadmin.postgresql.org/snapshots/postgresql/libs-win32-20040927.zip  but my distribution batch copied older
versions.

Please download that zip, replace the dlls and try again. This will 
hopefully fix the problem; I'll upload a corrected snapshot tonight.

Regards,
Andreas

Dave Page wrote:
> 
> Back in the old pga2 days, we used to use a control developed by the
> quietest member of the devteam (Mark) for all the multiline edit boxes.
> It had a handy feature in that it had it's own maximise button which
> would maximise it to fill it's parent frame. This was actually quite
> elegant and worked rather well. Before pgAdmin 3 was started, we had
> toyed with the idea of making the textbox detachable (this is roughly
> the point at which Andreas' head will probably explode :-) )

Fortunately, hard hats not only prevent from damage caused by outer 
impacts :-)

> into a mini-editor.

> 
> Now, if we added such a control to pga3, we could immediately make all
> the dialogues back into 'real' dialogues. All we would need to do is
> figure out how the detachable editor should behave (modally speaking for
> example) with respect to it's parent dialogue and the rest of the app
> for it to be able to work in a fashion that's acceptable and liked by
> all.

When mentioning modal you're scratching the problem. Making the 
additional window modal would probably have more impact on other parts. 
In this case, it would be a frame (eventually covering the whole 
screen), being child of a dialog. This is probably not gonna work 
smoothly (pgadmin-wide modal). Modal dialogs mean "the developer didn't 
now how to handle the stuff better, so he locks the rest of the 
machine", reducing to single task programming.

All apps that offered such kind of editing facility I can remember drove 
me nuts  (VB 'zoom', SyBase AppModeler too). I do see the necessity to 
have much space available for editing, but I'd expect that in practice 
extended functions/views aren't edited using the property dialogs, but 
with the query tool instead to have the code saveable into a file any 
time, including the test code used for developing it. Using the property 
dialogs is a bit like fixing your app by applying patched bytes at 
runtime instead of modifying your sources and recompiling.

Redesigning dlgFunction/dlgView to be nonsizeable and have the Zoom 
button would probable make these dialog look nicer, but make them quite 
unusable too (unless Zoom is pressed; did I mention I hate the M$ 
epidemic use of windows layering one atop another?).

Regards,
Andreas

> OK, I found out what's happening. I've been testing with the correct
> versions from
> http://pgadmin.postgresql.org/snapshots/postgresql/libs-win32-20040927.zip
>   but my distribution batch copied older versions.
>
> Please download that zip, replace the dlls and try again. This will
> hopefully fix the problem; I'll upload a corrected snapshot tonight.

Downloaded and tested. It's nice to see that things are working as expected.
Thanks.

Regards,
Virgil

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 11 October 2004 16:06
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
> Fortunately, hard hats not only prevent from damage caused by
> outer impacts :-)

I thought you ran Debian? Perhaps you should consider Fedora...


> When mentioning modal you're scratching the problem. Making
> the additional window modal would probably have more impact
> on other parts.

Oh, I realise that. Hence the call for discussion.

> In this case, it would be a frame (eventually covering the
> whole screen), being child of a dialog. This is probably not
> gonna work smoothly (pgadmin-wide modal). Modal dialogs mean
> "the developer didn't now how to handle the stuff better, so
> he locks the rest of the machine", reducing to single task
> programming.

Agreed - I'd rather avoid using anything modal, and I know if I tried
I'd have another fight with you about it :-)

> All apps that offered such kind of editing facility I can
> remember drove me nuts  (VB 'zoom', SyBase AppModeler too). I
> do see the necessity to have much space available for
> editing, but I'd expect that in practice extended
> functions/views aren't edited using the property dialogs, but
> with the query tool instead to have the code saveable into a
> file any time, including the test code used for developing
> it.

That's kinda heading off in the direction I think Jean-Michel was tryng
to take pga1 when he experimented with an Oracle like Packages system.
It would require far more thought and redesign to make it natural to
/not/ use the prop dialogues.

My thoughts on a GUI editor are less complex. There's no reason it
couldn't have a Save button, or a Save Definition button that saved not
just what you were editting, but the entire SQL query that would be run.

> Using the property dialogs is a bit like fixing your app
> by applying patched bytes at runtime instead of modifying
> your sources and recompiling.

Yes, but without having a full blown package system, there's not much
else we can do.

> Redesigning dlgFunction/dlgView to be nonsizeable and have
> the Zoom button would probable make these dialog look nicer,
> but make them quite unusable too (unless Zoom is pressed; did
> I mention I hate the M$ epidemic use of windows layering one
> atop another?).

Depends what you're doing. I don't often resize them myself, but then my
usage patterns don't necessarily match other ppls.

Incidently, wrt the other solution of converting all dialogues to be
wxFrame based, assuming it works you should be able to set
wxFRAME_NO_TASKBAR to prevent the taskbar icons showing up. Not sure
what other effects that would have, but it probably would then need some
dialogue refactoring to include sizers on everything.

Regards, Dave.

Dave Page wrote:
>  
>  > That's kinda heading off in the direction I think Jean-Michel was tryng
> to take pga1 when he experimented with an Oracle like Packages system.
> It would require far more thought and redesign to make it natural to
> /not/ use the prop dialogues.

I don't know how that's supposed to work.

e.g. designing views doesn't only mean to design them until all columns 
are included, and the syntax is correct. Additionally, the query plan 
needs investigation. To do that, you'd execute the select with some 
restriction, check the plan, optimize etc. At the end, you add "CREATE 
VIEW xxx AS" and hit F5. This is clearly more than property dialogs can 
deliver. Extending them would mean duplicating query tool facilities. 
For large views/functions, the property dialog advantages seem 
neglectable compared to the query tool.

> 
> Incidently, wrt the other solution of converting all dialogues to be
> wxFrame based, assuming it works you should be able to set
> wxFRAME_NO_TASKBAR to prevent the taskbar icons showing up. Not sure
> what other effects that would have, but it probably would then need some
> dialogue refactoring to include sizers on everything.

<shrug>
I won't accept resizing of non-resizable contents, which includes most 
property dialogs.

REgards,
Andreas

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 11 October 2004 16:47
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Function editor
>
> Dave Page wrote:
> >
> >
>   > That's kinda heading off in the direction I think
> Jean-Michel was tryng
> > to take pga1 when he experimented with an Oracle like
> Packages system.
> > It would require far more thought and redesign to make it
> natural to
> > /not/ use the prop dialogues.
>
> I don't know how that's supposed to work.
>
> e.g. designing views doesn't only mean to design them until
> all columns are included, and the syntax is correct.
> Additionally, the query plan needs investigation. To do that,
> you'd execute the select with some restriction, check the
> plan, optimize etc. At the end, you add "CREATE VIEW xxx AS"
> and hit F5. This is clearly more than property dialogs can
> deliver. Extending them would mean duplicating query tool facilities.
> For large views/functions, the property dialog advantages
> seem neglectable compared to the query tool.

Well, yeah, that's the point - you wouldn't use the properties dialogues
in such a situation. You'd have more of a development environment type
setup where you could design, build and debug entire sets of objects as
packages or projects.

> > Incidently, wrt the other solution of converting all
> dialogues to be
> > wxFrame based, assuming it works you should be able to set
> > wxFRAME_NO_TASKBAR to prevent the taskbar icons showing up.
> Not sure
> > what other effects that would have, but it probably would then need
> > some dialogue refactoring to include sizers on everything.
>
> <shrug>
> I won't accept resizing of non-resizable contents, which
> includes most property dialogs.

You already added it to dlgFunction etc. when you made them sizeable in
order to enlarge the function body textbox. We should aim for
consistency - either all dialogues are fixed (and appropriate fields can
be editted in a pop-off editor or similar), or they are not - hence both
of my suggestions so far.

Regards, Dave

Dave Page wrote:

> 
> 
> You already added it to dlgFunction etc. when you made them sizeable in
> order to enlarge the function body textbox. We should aim for
> consistency - either all dialogues are fixed (and appropriate fields can
> be editted in a pop-off editor or similar), or they are not - hence both
> of my suggestions so far.

This is restricted to dlgs that really need it. One death has to be 
died: accept uglyness for two property dlgs or having them nearly 
unusable. All other dlgs are perfect, dont spoil them.

Regards,
Andreas