Re: table OCX control
От | Mark A. Taff |
---|---|
Тема | Re: table OCX control |
Дата | |
Msg-id | LOBBLBDHPFLLCMMKPMFKIEJJDDAA.mark@libertycreek.net обсуждение исходный текст |
Ответ на | table OCX control (Tim Finch <pgadmin@timfinch.cix.co.uk>) |
Ответы |
Re: table OCX control
(Tim Finch <pgadmin@timfinch.cix.co.uk>)
|
Список | pgadmin-hackers |
I'll do a better job of quoting below. :) -----Original Message----- From: pgadmin-hackers-owner@postgresql.org [mailto:pgadmin-hackers-owner@postgresql.org]On Behalf Of Tim Finch Sent: Thursday, March 07, 2002 3:01 AM To: pgadmin-hackers@postgresql.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@postgresql.org
В списке pgadmin-hackers по дате отправления: