Re: table OCX control

From: Tim Finch <pgadmin(at)timfinch(dot)cix(dot)co(dot)uk>
To: "Mark A(dot) Taff" <mark(at)libertycreek(dot)net>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: table OCX control
Date: 2002-03-08 11:36:34
Message-ID: 5.1.0.14.0.20020308110439.01e4dce8@mail.cix.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers


>Mark's reply: I don't think we are going to pressured at all for space. The
>form opens up at the current default of 80% of available screen space, and
>all but one pane can be hidden by the user. So they could easily have just
>the diagramming pane take up their entire screen, if they wanted the room.
></Mark>

Thats good. Its just the default opening workspace is 1/4 to each pane, and
realistically they will need the diagram, field selection and possibly
SQL panes open all the time. I agree the results pane is optional for
design time.

><Mark>All the view designer stuff can easily be regenerated based on a .sql
>file or the reverse-engineered SQL code, with the exception of the placement
>and other changes the user made to the layout of the diagramming pane. That
>should indeed be saved in the database, I think.</Mark>

Your right, it was the diagramming pane I was referring to. Also the idea
of theming the table controls with the colour idea ought to be a database
scope setting (or optionally database scope) rather than View scope, would
mean some concept of a central 'project file' into which modules and
functions in pgAdmin have tyhe ability to write their settings, a sort of
'Registry' but stored in the pgsl backend.

In fact if we came up with a method of doing it Registry wise then
something like the view designer could determine its own 'hives' and 'keys'
and not care how, for example, the left hand tree view in pgAdmin stores
its own project related settings. What do you think Dave/Jean?

Tim

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Tim Finch 2002-03-08 11:53:37 Re: table OCX control
Previous Message Mark A. Taff 2002-03-07 22:35:56 Re: table OCX control