Jump to content


Photo

[proposal] Save/restore columns pos, width, ...


  • Please log in to reply
5 replies to this topic

#1 steki

steki
  • Members
  • 10 posts

Posted 04 August 2006 - 11:36 PM

hi,

there have been some proposal for saving and restoring columns width, position, ... in this forum. Some of them use inifiles for storing, others prefere registry.

Why not using an existing persistent concept from jedi library: jvPersistant.
Jedi has a non visible control that easily enables programmers to save and restore form position and other params.configuration can be stored in registry, inifile, streams, ....

maybe boki can modify next components to work with jedi form storage. for testing download jedilib, make a form and drag jvFormStorage and JvAppRegistryStorage to the form.
(http://homepages.bor....com/jedi/jvcl/)

any comment / suggestion?

best regards
stefan

#2 wvd_vegt

wvd_vegt

    Master Member

  • Honorable Members
  • PipPipPipPipPip
  • 710 posts
  • Gender:Male
  • Location:the Netherlands

Posted 05 August 2006 - 03:45 PM

Hi,

QUOTE (steki @ Aug 5 2006, 12:36 AM) <{POST_SNAPBACK}>
Why not using an existing persistent concept from jedi library: jvPersistant.
any comment / suggestion?


Well in my view it's quite simple, not everybody has or wants to install the jedi code (me for instance only have it installed for a tiny bit of its code, but I could not rip it out because the code isn't modulair enough. It's more like the all or nothing kind of lib). Linking the two is very undesireable in my opion as you force the jedi lib onto everybody using the Nextsuite. Another con is versioning of the library.

So if you want to use it, code it yourself and post it for others in the user code forum. If you write it the way i did with the library in there you just create functions that take a NexGrid as parameter. That way you don't have to integrate it into the sources.
G.W. van der Vegt

#3 steki

steki
  • Members
  • 10 posts

Posted 07 August 2006 - 12:40 AM

ok,

i can understand that no one should be forced to use jedi if he only wants to use next grid.
but reinventing the wheel is not the best way in software development :-)

maybe we can build a version that uses streams as persistent object, so everyone (inifile user, registry user, ...) can be happy and we dont get solution no 987 to save/restore dbgrid properties.


regards
stefan

#4 wvd_vegt

wvd_vegt

    Master Member

  • Honorable Members
  • PipPipPipPipPip
  • 710 posts
  • Gender:Male
  • Location:the Netherlands

Posted 07 August 2006 - 10:32 AM

Hi Stefan

Maybe my previous posting was a bit to strong but the folowing quote just points towards the problem:

QUOTE (steki @ Aug 7 2006, 01:40 AM) <{POST_SNAPBACK}>
maybe we can build a version


If you look at http://www.bergsoft....p?showtopic=194 it shows that you can make very usefull addons to Nextsuite without altering it's code by using procedures and functions (and not (sub)classes) like

CODE
procedure NG_SaveGridData(const NextGrid: TNextGrid; const FileName: string; const Prefix: string = '');


So if you write your jedi or streaming stuff this way we can all benefit from your code without being forced to using it.

As an example: I even managed to get the windows com based autocompletion working on NextSuite cells without any modification to the grid or linking it to com/activex.

So i would say: PLEASE write the jedi and streaming stuff as a procedure or function and share it with us.
G.W. van der Vegt

#5 deonvn

deonvn

    Senior Member

  • Honorable Members
  • PipPip
  • 313 posts

Posted 15 August 2006 - 10:37 AM

Hi All

NxCustomGrid already has procedures to save and load the grid settings from INI files (at least V3.9 does - I don't know when it was added?)

The only problem with the current procedure is that you can only save the settings of one grid per INI file, as the settings are not qualified.

Boki

This can easily be corrected by adding the component name to the front of the INI section name as is shown for the SaveToINI procedure below:

CODE
procedure TNxCustomGridControl.SaveToIni(const FileName: WideString);
var
  IniFile: TIniFile;
  i: Integer;
begin
  IniFile := TIniFile.Create(FileName);
  IniFile.WriteInteger(Self.Name + '.Common', 'ColumnCount', Columns.Count);
  for i := 0 to Columns.Count - 1 do
  begin
      if Columns[i].SortKind = skAscending then IniFile.WriteString(Self.Name + '.ColumnSortKinds', 'Column' + IntToStr(i), 'Ascending')
             else IniFile.WriteString(Self.Name + '.ColumnSortKinds', 'Column' + IntToStr(i), 'Descending');
    IniFile.WriteBool(Self.Name + '.VisibleColumns', 'Column' + IntToStr(i), Columns[i].Visible);
    IniFile.WriteBool(Self.Name + '.SortedColumns', 'Column' + IntToStr(i), Columns[i].Sorted);
    IniFile.WriteInteger(Self.Name + '.ColumnPositions', 'Column' + IntToStr(i), Columns[i].Position);
    IniFile.WriteInteger(Self.Name + '.ColumnSizes', 'Column' + IntToStr(i), Columns[i].Width);
  end;
  IniFile.UpdateFile;
end;


The same changes must then be made to the LoadFromINI procedure.

I have also removed the spaces from the section names, and added a full stop after the component name (it just makes it more readable in the INI file).

The sections are then saved as:

Grid1.Common
Grid1.VisibleColumns
Grid1.SortedColumns
etc...
Grid2.Common
Grid2.VisibleColumns
Grid2.SortedColumns
etc...

This is what I am currently using and it seems to works fine.

Regards,

Deon

#6 deonvn

deonvn

    Senior Member

  • Honorable Members
  • PipPip
  • 313 posts

Posted 15 August 2006 - 05:06 PM

PS: Come to think of it, you could still have two grids with the same name but on different forms, which would also cause a problem in the INI.

It would probably be better to use FormName.ComponentName.SectionName to qualify the sections of the INI.

Regards,

Deon




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users