Re: table OCX control

I'll do a better job of quoting below. :)

-----Original Message-----
From: pgadmin-hackers-owner(at)postgresql(dot)org
[mailto:pgadmin-hackers-owner(at)postgresql(dot)org]On Behalf Of Tim Finch
Sent: Thursday, March 07, 2002 3:01 AM
To: pgadmin-hackers(at)postgresql(dot)org
Subject: [pgadmin-hackers] table OCX control

Dear all,

Firstly may I apologise to Mark. The work I outline in this message was
done before I realised you had already made the first version of the
DataWidget ocx control. I had totally missed it.

http://www.fosterfinch.co.uk/pgadmin

The site has a link to a screen grab of my first table ocx control design.
it has absolutely no code in it yet.
Things to note, and for discussion
- Tables will be able to be themed (blue, red, white, yellow), wher the
background colours all change to that theme, if the user wishes to, in
order to spot tables quicker in the designer
- Bold fieldnames are Primary Keys
- italic fieldnames have some form on constraint other than FK on them
- underlined fields are FKs
- tick boxes on left do what MS SQL designer does, selects fields for
display
- White boxes at end of fieldname line tell you the column type in
abbreviated form (i8 - Int8, Vc - Varchar etc.)
- The idea will bwe that when the user hovers over one of these a pop up
tells you additional info like Varchar length, or check/FK constraint
details

<Mark>Sounds great.</Mark>

Thoughts:
- Mark, I see you have fleshed out more on the code side of your
datawidgets, I will use these methods/props etc where feasible. I feel that
my design of the datatable ocx is a bit more clean and less fussy.
<Mark>Tim said: As the
designer is going to be pressured for screen space at the top for the
tables we are going to need to keep the tables small.
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>

- I know the wish list for pgAdmin contains the idea of a project file in
the future. This is going to be a key requirement, esp where query
designing is concerned as the user will position tables and colour them
etc. and will want this to be retrieved. Surely one of the best places to
keep the project file is actually in a table in database itself? In the
meantime, what will we do about storing the non SQL aspects of a view
design for retrieval later on - simply save them to a .pvd (PgAdmin View
Design) file on the local drive of the user?

<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>

Hope this input helps get ideas rolling.

Tim.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org