Re: DATABASE listviews

Hi Dimitris,

Multi column listviews are also called DATABASE listviews.
This  page ends in :
"I will be adding various capabilities to them, as needed."
Am I talking about an old version of :
...\Gui4Cli\Gui4Cli.chm::/Fields.htm
In the table :
Date A date (not finished yet..)
is that finished now?
If so let me know, and please ignore these suggestions if they have been
completed.
~~~~~~~~~~~~~

This  page of the manual I believe, needs a couple of complete examples
of a .GCD file contents to make it clear.

The "Keyword link" is okay but "dedicated commands" should have an
anchor to take it to "Listview commands" in "Event commands" page of the
manual.
~~~~~~~~~~~~~
You say that fields contents with spaces needed quotes about them, but
it seems the example has none :
GCDB
#%one   'title/Column 1'
#%two   'title/Column 2/justify/center'
#%three 'title/Column 3'
field one field two field three
field oneb field twob field threeb
field onec field twoc field threec
--------------------------
Should it read ?  :
"field one" "field two" "field three"
"field oneb" "field twob" "field threeb"
"field onec" "field twoc" "field threec"
for them to be placed in 9 boxes (3x3)
~~~~~~~~~~~~~
Some questions arose when I read the page.

What is the practical limit on the listviews?  Is there  a maximum
amount of Ram memory that they can use?  Or can you add more lines to
them ad infinitum; up to the size of your free drive space?

Is only the field contents which is being written or read to a box in
the buffer, not multiple ones?

If the buffer default 1024 bytes will chop the end off the contents what
to do?  Do I make the script look for the maximum size of my contents
and increase the buffer to that as needed?  If I increase it does buffer
resize to default 1024 as it quits the script, or must the author reset
before quits.

Can a listview's field box hold more than one variable?  To elaborate,
that %field variable  is there when the the field is created
automatically.  Can a user script more variables attached to the box? 
How is that done?  Do those automatically die  as it quits the script,
or are commands needed to be added to delete them as the script ends.

The filename extension should also be ".gdb" but it doesn't have to. If
I record data into a .DAT, .BIN, .INI or any which I already have in my
windows filetype extensions associations, that will allow them to be
clicked open in my favourite note taker?
~~~~~~~~~~~~~
You wrote :

The first thing in the file must be the "GCDB" header. . Anything
following GCDB, on the same line is currently discarded - This will
change in the future!.
-------------------------
I had this idea.  How about you put the titles of sections following the
"GCDB" header in line #1 ?  You could terminate the listview data with a
"###" line you usually use for stopping.  The sections would need to end
the file after the hashes.  The section names in line 1 could have
pointers to the line the section is found on.  Then you could use your
existing INI reading and writing code, I assume, to load the sections
into script memory.  One file instead of a separate INI !  This scheme
would be useful to keep comments, variables, events like the listview
itself, Addcode lines, New Scripts, HTML and other codes, filepaths,
urls etc. all in one file so they dont get separated and lost.  You
could still allow the GCDB file to work the way it does now if the file
ends after the listview data, when it is not followed by any sections. 
The other stuff's sections can be titled in square braces, like they are
in INI.

If the buffers may need resizing, can that not be done automatically? 
It would de-mystify the use of variables treeviews and listviews if
users had not to worry about this problem of long lines.



I am trying to be helpful with my suggestions, and I don't criticise the
grand job you did in writing Gui4Cli.



Regards , Flicknemo.