Re: table OCX control
От | Tim Finch |
---|---|
Тема | Re: table OCX control |
Дата | |
Msg-id | 5.1.0.14.0.20020308110439.01e4dce8@mail.cix.co.uk обсуждение исходный текст |
Ответ на | Re: table OCX control ("Mark A. Taff" <mark@libertycreek.net>) |
Список | 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
В списке pgadmin-hackers по дате отправления: