Subject | Re: Future of IBObjects |
---|---|
Author | Marco Menardi |
Post date | 2004-10-10T10:03:46Z |
--- In IBObjects@yahoogroups.com, "Jason Wharton" <jwharton@i...> wrote:
- client side sorting. I've some "long" last query (10 seconds) that
provides a small set of data (100 rows?), but is data that provides
important information if you can sort them in 2 or 3 fields order. Now
it's really annoying since you have to wait 10 seconds every time the
sort order is changed. btw, the sort should be performed based upon
multiple columns criteria (i.e. last_name, first_name, order_no).
- "editable" calculated (or dummy) fields. See my previous posts with
"Editable calculated field" topic
- standard multiselect-deselect IB_Grid behaviour. I've to put some
patch code in my apps to make it behave like a standard windows grid.
I don't care if your method could be better, since my users aspect the
standard behaviour and they conclude that my program is "broken" or
"strange", or "non standard", or "not so usable".
- AFAIR there are some bugs left in no-so-frequently used capabilities
of IBO (seem to me to remember the IB_Grid search capability in
read-only datasets, that does not always work as expected, but I
should try to find my notes about that... I simply give up at those
times).
- a sample and good documentation about "cuncurrent record editing".
I've not understood it, I always use "pessimistic lock" and it's the
only way I've found to avoid the second use to overwrite the first
user edits.
- about this, if you use the automatic editing capability the
syncbefore edit does not work. There must be a workaround because
auto-edit is really useful, but since the client has an "old" version
of the data, the sync befor the edit is also very important. You could
fetch the row from the database, update all the other fields but the
one currently edited and compare the old buffer of the edited field
with the database value. If they match keep going, if not... well,
something clever must be done.
- I would love to have an additiona color property for the focused
field to be used by visual components (i.e. IB_Edit), and a less
invasive field checking, like Alan Cooper suggest in his books
(www.cooper.com). If you want I can elaborate this further, but in
brief would be good having a "ok" sound when you leave a field without
error, and absence of it if any error occurs, with the (background)
color changed. At the end an interna flag avoids you to post the
record. It's like having the spell check with a red underline in a
word processor: you keep writing fast to fix your ideas, and then look
back to edit the misspelled words. Something like this, AFAIR was
implemented in the now Free Software Orpheus components.
In any case, IBO is a really *great* piece of software. I really thank
you for the code, for the fact that you include improvements and fixes
that are sent to you and you consider ok, and for the license (even I
suggest you to consider a "dual license" model like MySQL, because I
would love see IBO as part of GPL software). It's really a pity that
kylix was killed by Borland, since I do need to develop for GNU/Linux
in the near future and I can't see anything comparable to IBO code
around (and also Delphi RAD environment).
Thank you Jason!
>The first two things that comes in my mind are:
> What kinds of things do you want or expect from IBO?
>
- client side sorting. I've some "long" last query (10 seconds) that
provides a small set of data (100 rows?), but is data that provides
important information if you can sort them in 2 or 3 fields order. Now
it's really annoying since you have to wait 10 seconds every time the
sort order is changed. btw, the sort should be performed based upon
multiple columns criteria (i.e. last_name, first_name, order_no).
- "editable" calculated (or dummy) fields. See my previous posts with
"Editable calculated field" topic
- standard multiselect-deselect IB_Grid behaviour. I've to put some
patch code in my apps to make it behave like a standard windows grid.
I don't care if your method could be better, since my users aspect the
standard behaviour and they conclude that my program is "broken" or
"strange", or "non standard", or "not so usable".
- AFAIR there are some bugs left in no-so-frequently used capabilities
of IBO (seem to me to remember the IB_Grid search capability in
read-only datasets, that does not always work as expected, but I
should try to find my notes about that... I simply give up at those
times).
- a sample and good documentation about "cuncurrent record editing".
I've not understood it, I always use "pessimistic lock" and it's the
only way I've found to avoid the second use to overwrite the first
user edits.
- about this, if you use the automatic editing capability the
syncbefore edit does not work. There must be a workaround because
auto-edit is really useful, but since the client has an "old" version
of the data, the sync befor the edit is also very important. You could
fetch the row from the database, update all the other fields but the
one currently edited and compare the old buffer of the edited field
with the database value. If they match keep going, if not... well,
something clever must be done.
- I would love to have an additiona color property for the focused
field to be used by visual components (i.e. IB_Edit), and a less
invasive field checking, like Alan Cooper suggest in his books
(www.cooper.com). If you want I can elaborate this further, but in
brief would be good having a "ok" sound when you leave a field without
error, and absence of it if any error occurs, with the (background)
color changed. At the end an interna flag avoids you to post the
record. It's like having the spell check with a red underline in a
word processor: you keep writing fast to fix your ideas, and then look
back to edit the misspelled words. Something like this, AFAIR was
implemented in the now Free Software Orpheus components.
In any case, IBO is a really *great* piece of software. I really thank
you for the code, for the fact that you include improvements and fixes
that are sent to you and you consider ok, and for the license (even I
suggest you to consider a "dual license" model like MySQL, because I
would love see IBO as part of GPL software). It's really a pity that
kylix was killed by Borland, since I do need to develop for GNU/Linux
in the near future and I can't see anything comparable to IBO code
around (and also Delphi RAD environment).
Thank you Jason!