Detail block design for SIMPOL

[Michael]

Hi, we are currently implementing detail blocks for SIMPOL. For those of you have delved at all into SIMPOL development, you will know that the data aware forms are represented by a set of data types all beginning with the type name dataform1. These are implemented in SIMPOL and wrap the C language components of wxform and its associated types. Most Superbase programmers are familiar with detail blocks (older Superbase programmers may still know them as transaction lines). The detail block in Superbase is a very powerful, and at the same time, very frustrating tool. In their simplest form, they can be replaced by a data-aware grid, one of which was added in read-only form with the initial release in April. The more complex aspects of detail blocks make them a miserable thing to design and implement anyway (especially things like columns plus rows, plus children and grandchildren, etc.). There are also performance related issues. Finally, as we all know, using them for data-entry is nothing resembling fun. They weren’t really designed for it. There are no standard visual methods of selecting a row, deleting one, adding one, etc. The goal of this discussion topic is to come up with a feature set that meets everyone’s needs as much as possible, and at the same time is also implementable in any kind of reasonable way. I have already had some discussions about this off list, and I will place those comments below. Please feel free to comment on any aspect of this topic, the more the merrier. Ciao, Neil ———————————————————————— Richard Tannenbaum: The Superbase Functional Specifications are fine and would be nice if they all worked reliably. NR: Actually, they are very insufficient. There is no reliable and standard way to add or delete records. RT: indeed no delete is there – but that can be reliably programmed. RT: adding records is part of the functional specs – but is not reliable RT: on click event on a row – tells me what row with detailblockrow – that is reliable NR: There is no standard method to select a row. RT: on click event on a row – tells me what row with detailblockrow – that is reliable NR: I am debating various ways of solving this at the moment. One is to NR: add a right-mouse pop-up menu that has Add, Modify, and Delete. NR: Another is to always force the first row to act as a template row, NR: where the selected row is copied into, but that would be a problem NR: if always supported, not to mention taking up space. RT: The right mouse menu would conflict with any other right mouse menu RT: that may be active at that time. RT: One feature that occurs to me is an easy way of relocating within RT: the detailblock. RT: If you’ve paged and modified say the fifth row having scrolled thru RT: a few pages – Updated the row (using a dialog) then to redisplay the RT: form with the detailblock as it was. Clearly a redisplay of the RT: detailblock will be necessary if the modification implied a change RT: of order within the detailblock. ————————————————————————- Jim Foy: I’ve never used detail blocks for direct entry because most of my apps require more data than could be seen in a single line. I always set them up with read-only with buttons to the left of each line (see attached) which brought up a dialog box for entry. The box was large enough to enter all required data, not just that included in the detail block line. Users have never objected to not entering directly into the detail block…and the button to the left of each line is easily remembered as the way to drill down into the detail of the record represented in the detail block line. It also focuses user action on the work they are doing, blocking further action until the modal dialog is completed. I suggest that you implement a non-enterable detail block which gives the option to add the buttons to the left of each line and accepts the name of a proc which the buttons will call…and automatically sets up the line number, file, and record ID in the call. For that matter, if the detail block includes linked fields from another file, clicking on a specific field of the detail block would pass the line number and link info to the proc which is called by the click. Thus, clicking on each element in a detail block line could direct the user to a different proc with the info on the file and record ID. The setup for this feature could also select the entire line as clicked vs. individual line elements. This new feature, IMHO, would offset the loss of direct entry into a detail block line and give an ease of use which is not available in competing development platforms. ————————————————————————- Roland Bellington Actually, I have created detail blocks that handle row selection, add, edit, and delete. But this was done from code. Row selection is shown by reversing the color scheme or an indicator. For an indicator would use a Webding of Wingding font. The data files that are represented in the detail all have a unique record id, so that I don’t lose track of which detail record I am working with. There is also additional code so that nothing happens if you select an empty row. ————————————————————————- Ian Stephenson How Detail Blocks Could Be Improved =================================== Detail blocks have worked very well. Suggestions on how they could be improved are: Standardisation ————— Any feature that could help a programmer to standardize the look and feel of the GUI (including detail blocks) throughout their project. When Defining a Detail Block —————————- – Set a standard font, size, colour – Automatically pick up how many columns there are and allow for the top row to become the column headers with a default shading. – Set the format for a column of values such as the colour red for negative, black for positive – Allow user to set the default for Row and column offset – Automatically pickup index fields and make the heading selectable so that data re-sorts on the heading – Make the graphics of the scroll bar user definable – Have the ability to set the “on click “ action for each row. See “On Click Actions” topic below – Select a detail block and have an option to automatically adjust column position so that space between columns, width and height of cells is standardised – Automatically place a bounding boarder and background shade When user uses a Detail Block —————————– – On mouse over, wake up the column but do nothing until clicked – Have a different action available for left and right click – Allow mouse wheel to scroll through a detail block On Click Actions —————- 1. If the left and right mouse buttons could call up different procedures. 2. At the moment I have to place rows of hidden buttons behind the detail blocks. Mouse Over ———- On Mouse Over there could be different actions such as: – Enlarge – Awake (make some subtle action that makes the data just a little different such as Glow – Jump up – Play quick sound “tud, tud, tud” – play sound in field abc.sbf – Display supplementary text in field xyz.sbf Mouse Pause ———– If a user pauses for x seconds on a field, a different action could be called such as 1. Show picture in field dfg.sbf 2. Play sound in field xyz.sbf Most Important ————– 3. Transparent field backgrounds so that the detail block can be placed on a cool background. 4. Allow for a shadow (user definable colour, distance, direction) 5. Glow on mouse over 6. When a user selects, edits an item in the detail block, automatically refresh and hold the position of the record

[John Roberts]

Some quick thoughts.

IMHO selection highlights should follow the current standards so users don't
get confused.
This is usually a highlighted row, mostly in blue and possibly a dashed
border but dependent on the system theme , with reverse coloured text.
Left and/or right single click should select the row as should the down or
up cursor keys once a DBlock row has focus.
There were some pretty awful looking apps out there that did not do this.
Hidden buttons went out when the use of events for non button controls
became available.

Mostly that style of selection will be ok but if you want to turn it into a
spreadsheet looking control it won't work as you need a single cell
highlighted for that – usually with a rectangular bold border. Perhaps a
switch to flip between the two modes. (or roll your own out of a grid or
listview control)
eg an appointment book with different days on display. Perhaps each day
would need to be a child detailblock set next to each other to look like a
multirow/column control but that would involve complex tabbing routines to
get from one child row to the one next to it and get them all to scroll at
once. Believe me, I have done it.
Buttons on the left or top are usually used to select a whole row or column
although it used to be the fashion in DB4 and Win3.6 etc. to select rows
with left side buttons.

Adding records is always problematic once the number of rows exceeds the
DBlock's rows. Do you leave it to the user to scroll to the bottom of the
dataset and add a row a la MS Access – I think this is very inconvenient for
the user with a large datarowset. You could programmatically SelectLastPage
and scroll up one more to leave a blank row for entry. On a WAN that
approach may slow things. Dialogs are mostly easier and can display a more
full range of fields from a table or tables and data in combo boxes. The
other option is to overlay a fake "row" of cells over the detailblock for
editing or new record adding. This might cause ZOrder display problems.

Dialogs are easier but there are times when it is good to edit "in situ".
Either way the record needs to added to the dataset so it is not lost when
the dblock is scrolled or when the new record assumes its place in the sort
order.
There lies another problem. Invoices needs to be created without being
stored until they are finalised so a temporary store is needed in that case
particularly if the number of records exceeds the control's num of rows. Not
good enough to read it from the DBlock's cells/textboxes text unless you add
multiple rows of DBlock cell controls. Probably better to have a virtual
store with each row having a "dirty" or edited/new flag.

With SB if you had child detailblocks and new records you could not scroll
as I remember. If you could you lost the records.

Editing a detailblock with intra row links is not easy unless you add a
button in a "border" cell between one table and the next in the same row.

If you add a right click menu, it needs to be able to be overidden and/or
appended to. Certainly an ability to add a right click menu and a
doubleclick event needs to be added.
A selection single click would need to update the selected row/cell storage
member as would key up/down strokes. The right click and the double click
need to have access that. If data is bound to the row then access to the
uniqueid of the datarow record would be necessary. Also access to the cells
parent DBlock that holds link details for retrieval.
I think the ability to dictate which approach (in table or in dialog) is
used should be available.

Cheers, John

[John Roberts]

> Buttons on the left or top are usually used to select a whole row or
> column although it used to be the fashion in DB4 and Win3.6 etc. to select
> rows with left side buttons.

Pity we can't edit our posts or can we.
Cheers, John

[Phil Alexander]

Why not make both a detail block and a detail row visual, container-type
objects?

If the block itself is a container, you can have the field names
(/column titles) in the main object.

If each row is a container, then that could be the bit that gets
highlighted (either by colour change – "default colour"/"highlight
colour" properties, or possibly an OnSelect even that allows the
programmer to set a background bitmap; or a simple frame..).

[Michael]

John Roberts wrote:
>> Buttons on the left or top are usually used to select a whole row
>> or column although it used to be the fashion in DB4 and Win3.6 etc.
>> to select rows with left side buttons.
>
> Pity we can't edit our posts or can we. Cheers, John

No, this is essentially a news server using the news:// protocol ala
inn. If you went in via the forum, that is a php-based front-end to the
news server. I tend to use the standard newsgroups support in Thunderbird.

Ciao, Neil

[Michael]

Phil Alexander wrote:
> Why not make both a detail block and a detail row visual,
> container-type objects?
>
> If the block itself is a container, you can have the field names
> (/column titles) in the main object.
>
> If each row is a container, then that could be the bit that gets
> highlighted (either by colour change – "default colour"/"highlight
> colour" properties, or possibly an OnSelect even that allows the
> programmer to set a background bitmap; or a simple frame..).

I think it is important to note that detail blocks are being implemented
*in SIMPOL* not in C. All of dataform1 is implemented in SIMPOL as
wrappers to the wxform type tree that is done in C. As such, anything
that is done has to be a reasonably viable thing to do in the SIMPOL
language.

I think we want to keep the ability to select a group of disparate
controls and then to treat them as a view into a separate table. I
currently am planning to support:

– dataform1text
– dataform1edittext
– dataform1combo
– dataform1bitmap
– dataform1checkbox

I may not include these yet, since it complicates things quite a bit (I
will need to add an optiongroup for each block of option buttons that I
replicate as well).

– dataform1option (requires all members of the group to be included)

I am not convinced there is a good reason to support adding listboxes to
a detail block. If someone can make the case for it, I am all ears, but
anything that can reasonably done with a listbox can also be done with a
combobox and it will fit on the same row more easily.

– dataform1list

As for the concept of a container, there are several aspects to that.
The current design has the concept of a section, which is all the
controls in a detail block that are from the same table. For each
defined row or column, there is a dbunit, which contains the controls
associated with that row/column.

Any controls from a different table will be added to another section.
One of the sections will be considered the master section (this can be
changed programmatically, comparable to the way the dataform1datagrid
works. The other sections that are not the master section will not allow
modification of the data (it is recommended that such sections are
represented by pure text or else by edit controls set to readonly). I
can't reasonably prevent modification if an edit control is not readonly
(though I can force that state), but I can't set a checkbox or combobox
to readonly, I can only disable it.

Ciao, Neil

[Michael]

John Roberts wrote:
> Some quick thoughts.
>
> IMHO selection highlights should follow the current standards so
> users don't get confused. This is usually a highlighted row, mostly
> in blue and possibly a dashed border but dependent on the system
> theme , with reverse coloured text. Left and/or right single click
> should select the row as should the down or up cursor keys once a
> DBlock row has focus. There were some pretty awful looking apps out
> there that did not do this. Hidden buttons went out when the use of
> events for non button controls became available.

Please note, that anything in this area I will have to add. Detail
blocks are meant to follow the Superbase approach of collecting a group
of controls into a working unit. As for selection, clicking on a control
will give it focus, and at that point I can do something to mark the
row. What is not yet established. Please note the row could contain
controls of differing sizes, like in Superbase.

> Mostly that style of selection will be ok but if you want to turn it
> into a spreadsheet looking control it won't work as you need a single
> cell highlighted for that – usually with a rectangular bold border.

If someone wants that, they can use the dataform1datagrid, too.

> Perhaps a switch to flip between the two modes. (or roll your own out
> of a grid or listview control) eg an appointment book with different
> days on display. Perhaps each day would need to be a child
> detailblock set next to each other to look like a multirow/column
> control but that would involve complex tabbing routines to get from
> one child row to the one next to it and get them all to scroll at
> once. Believe me, I have done it. Buttons on the left or top are
> usually used to select a whole row or column although it used to be
> the fashion in DB4 and Win3.6 etc. to select rows with left side
> buttons.

Part of my current thinking is: given a detail block much like Superbase
builds them currently, what would be the best way to:

Mark a row (visually as selected)
Select one or more rows (do I add a checkbox potentially to the
beginning of each row?)
Add a record
Delete a record
etc.

> Adding records is always problematic once the number of rows exceeds
> the DBlock's rows. Do you leave it to the user to scroll to the
> bottom of the dataset and add a row a la MS Access – I think this is
> very inconvenient for the user with a large datarowset.

You mean Microsoft took this ugly thing from Superbase as well? You
would think they could have found a better way. Thinking about it
though, there is a real problem with adding records, since if they
scroll off, how do you reselect them? They won't yet exist in the
database, so there is no way to add them back into the sort order.

> You could
> programmatically SelectLastPage and scroll up one more to leave a
> blank row for entry. On a WAN that approach may slow things. Dialogs
> are mostly easier and can display a more full range of fields from a
> table or tables and data in combo boxes. The other option is to
> overlay a fake "row" of cells over the detailblock for editing or new
> record adding. This might cause ZOrder display problems.

I don't think it would cause this kind of problem, but it may be better
to add them by reserving the top row of controls for modification, and
then when a row is selected, its content is copied to that row for
modification. When adding, that row is blanked. The real problem is if
the records are not to be committed until they all are.

> Dialogs are easier but there are times when it is good to edit "in
> situ". Either way the record needs to added to the dataset so it is
> not lost when the dblock is scrolled or when the new record assumes
> its place in the sort order. There lies another problem. Invoices
> needs to be created without being stored until they are finalised so
> a temporary store is needed in that case particularly if the number
> of records exceeds the control's num of rows. Not good enough to read
> it from the DBlock's cells/textboxes text unless you add multiple
> rows of DBlock cell controls. Probably better to have a virtual store
> with each row having a "dirty" or edited/new flag.

I had already planned a modified blocks list where I would look first
when scrolling records back into view. The real problem that I see with
new records is their order in the data set. Where do new records get
sorted? If they are simply in the same order as they were added, then I
probably have to maintain some internal list of all record IDs with some
form of interim ID for new records (ugly).

> With SB if you had child detailblocks and new records you could not
> scroll as I remember. If you could you lost the records.

Interesting point. Upon thinking it through under the hood, I can see why.

> Editing a detailblock with intra row links is not easy unless you add
> a button in a "border" cell between one table and the next in the
> same row.

Actually, I would always make these controls read-only/disabled. The
only way they could get their content filled is by exercising the link.

> If you add a right click menu, it needs to be able to be overidden
> and/or appended to.

That was the intention. A menu with Add, Modify, Delete, which can be
added to after Delete. The main entries can be disabled if required.
Modify and Delete will also be disabled if no row is currently selected.
Selecting one would just call the associated callback function.

> Certainly an ability to add a right click menu
> and a doubleclick event needs to be added. A selection single click
> would need to update the selected row/cell storage member as would
> key up/down strokes. The right click and the double click need to
> have access that. If data is bound to the row then access to the
> uniqueid of the datarow record would be necessary. Also access to the
> cells parent DBlock that holds link details for retrieval. I think
> the ability to dictate which approach (in table or in dialog) is used
> should be available.

Doubleclick events don't really exist for everything I think (maybe
onmouse can help here though). Again, are we talking about selecting a
control, or selecting some piece of window dressing that is trying to
indicate a row is selected?

Detail blocks are not grids. They are more versatile than grids. For
grids, I already have dataform1datagrid.

Ciao, Neil

[JD Kromkowski]

Two cents or less.

Detailblocks, to me, are first about the DISPLAY of data.

So the first thing is the sorting of the children. The data-aware grid
totally fails at this. For example, if I have a bunch of records
representing dates that are linked to the master by some unique id, I'd
want to display that detailblock in date order. Right now you can't do
that.

By the emphasis on DISPLAY I also mean that the adding, modifying and
deleting of a record associated with a row, I think, needs to happen
separately via a dialog/form.

To that end, I always make the detail blocks READ ONLY and I always have
an "Add" button and a "Modify/Delete" button under the detail block. The
Add button brings up a dialog/form on which I can add a record. The
Modify/Delete button brings up a Requester (I suppose in simpol a dropdown
in a form/dialog) by which one can select (sometimes using a search like a
drilldown is necessary) a record to be modified or deleted (via
form/dialog). After all it is often the case that you can't show all of
the records in detailblock.

So to me, the presence of an Add button and a Modify/Delete button really
should be incorporated right into the detailblock as a option, like a
parameter to have a scroll bar or not.

When the detailblock records refer to externals (images or documents),I
still like using the invisible button. You are really not doing anything
to the row/record "selected", but are using some data in the row/record to
open up the image or document (e.g., PDFs, TIFFs, BMPs, Word or
WordPerfect) in its native program usually via ShellExecute.

In the data-aware grids, it's kind of odd that there is no onSelectRow
event nor an onSelectColumn.

Think about it. If you click on the row number, all of the row gets
"selected" or at least it "appears to get selected" because of the color
change.

The same is true when you click on the column head, the entire column gets
"selected" or "appears to get selected".

If the entire row is getting selected then should you be able to use that
to select that particular record.

And if the entire column is getting selected then it seems like it should
be standard behavior that that would sort the records by that field.
First click ascending, next click the opposite sort, i.e. descending. (Or
you could handle it like googledocs spreadsheet.

Just adding these behaviors (OnSelectRow and OnSelectColumn to the
data-aware grid would make them useful enough to use in lieu of a one
level detail block. (That and being able to adjusted the size of the row
numbers, way too wide now.)

[Jim Locker]

"Thinking about it though, there is a real problem with adding records,
since if they scroll off, how do you reselect them? They won't yet exist
in the database, so there is no way to add them back into the sort order."

Give the detail block the capability to handle virtual rows. There will
be the physical rows defined by the user on the form, and a scroll bar.
All uncommitted detail block entries go into an appropriately formatted
volatile database file, and the detail block displays the segment of that
volatile database file that is selected by the scroll bar on the right.

When the data is committed, the volatile database file is deleted and the
detail block now shows appropriate entries from the real database file –
which continues until another change is made, which causes the
instantiation of a new volatile database file.

[Michael]

jim wrote:
> "Thinking about it though, there is a real problem with adding
> records, since if they scroll off, how do you reselect them? They
> won't yet exist in the database, so there is no way to add them back
> into the sort order."
>
> Give the detail block the capability to handle virtual rows. There
> will be the physical rows defined by the user on the form, and a
> scroll bar. All uncommitted detail block entries go into an
> appropriately formatted volatile database file, and the detail block
> displays the segment of that volatile database file that is selected
> by the scroll bar on the right.
>
> When the data is committed, the volatile database file is deleted and
> the detail block now shows appropriate entries from the real database
> file – which continues until another change is made, which causes the
> instantiation of a new volatile database file.
>

I suppose it depends on how current the data should be. In a real world
Superbase scenario, if records were added to the data set by another
user, when scrolling the detail block up and down, the new records would
actually appear. OTOH, if we were to make the decision that the detail
block shows a snapshot of the data from the moment of the original read,
then it could work as you describe. What I am trying to avoid is
unnecessary data reads, and creating a volatile table would not
necessarily avoid the issue. I can actually just create an array of
record objects, where the content of the array is any record object that
has been created or modified but has not yet been committed.

Ciao, Neil

[Michael]

JDK wrote:
> Two cents or less.
>
> Detailblocks, to me, are first about the DISPLAY of data.

To some degree, I agree with this, but this discussion is intended to
track down what people want from detail blocks, since any decisions we
make here are going to affect anyone using them. I want to keep peoples'
options open as much as possible (that is the job of a tool kit after all).

> So the first thing is the sorting of the children. The data-aware
> grid totally fails at this. For example, if I have a bunch of
> records representing dates that are linked to the master by some
> unique id, I'd want to display that detailblock in date order. Right
> now you can't do that.

The grid component we are using is not a good choice for this sort of
behavior, but when we added it, it was one of the few options available
within wxWidgets. In the interim there are others, but they all require
a significant investment of time and money.

> By the emphasis on DISPLAY I also mean that the adding, modifying and
> deleting of a record associated with a row, I think, needs to happen
> separately via a dialog/form.

Some people do it this way in Superbase, others do it by defining a row
at the top that is not actually part of the block, but which acts as if
it were, and every selection is copied to that row.

> To that end, I always make the detail blocks READ ONLY and I always
> have an "Add" button and a "Modify/Delete" button under the detail
> block. The Add button brings up a dialog/form on which I can add a
> record. The Modify/Delete button brings up a Requester (I suppose in
> simpol a dropdown in a form/dialog) by which one can select
> (sometimes using a search like a drilldown is necessary) a record to
> be modified or deleted (via form/dialog). After all it is often the
> case that you can't show all of the records in detailblock.
>
> So to me, the presence of an Add button and a Modify/Delete button
> really should be incorporated right into the detailblock as a option,
> like a parameter to have a scroll bar or not.

It is one of the options up for consideration, as is the right-mouse
pop-up menu approach (less screen real-estate involved).

> When the detailblock records refer to externals (images or
> documents),I still like using the invisible button. You are really
> not doing anything to the row/record "selected", but are using some
> data in the row/record to open up the image or document (e.g., PDFs,
> TIFFs, BMPs, Word or WordPerfect) in its native program usually via
> ShellExecute.

This could be done by using the double-click support in the onmouse
event for each control. An extra button is not required.

> In the data-aware grids, it's kind of odd that there is no
> onSelectRow event nor an onSelectColumn.

I have them on my internal wish list, but they have not yet been
implemented.

> Think about it. If you click on the row number, all of the row gets
> "selected" or at least it "appears to get selected" because of the
> color change.
>
> The same is true when you click on the column head, the entire column
> gets "selected" or "appears to get selected".
>
> If the entire row is getting selected then should you be able to use
> that to select that particular record.

Actually, I use the oncellselect event of the grid to get that information.

> And if the entire column is getting selected then it seems like it
> should be standard behavior that that would sort the records by that
> field. First click ascending, next click the opposite sort, i.e.
> descending. (Or you could handle it like googledocs spreadsheet.

Sorting is a know requirement, but it also impacts the issues related to
performance. There are only two ways to do this, read all the related
records and then sort them, or allow a link on a partial field value
that is essentially a combined index. Such as linking the master record
ID which might be "00000025" plus the desired sort field and then
allowing a link on the first 8 characters of the target field. I have
considered it, and may yet implement it.

> Just adding these behaviors (OnSelectRow and OnSelectColumn to the
> data-aware grid would make them useful enough to use in lieu of a one
> level detail block. (That and being able to adjusted the size of
> the row numbers, way too wide now.)

As for the row numbers, I am pretty sure you can change them
programmatically yourself, just call the setrowlabelwidth() method I
think it is.

Ciao, Neil

[Jim Locker]

Well that is a good point.

But all users will have current displays of committed data, only
uncommitted data will be held locally in the volatile file.

An option for the detail block could be provided; commit line by line, or
commit only when told to. This way, the developer/end user could choose
the case that works best for their situation.

As for minimizing file access, obviously you want to avoid unnecessary
disk thrashing or network traffic in your design but you can't go too far
with that. Most of those decisions quite properly belong with the
application developer/end user. If you go too far, you restrict the
usability of the resulting control.

Think C, not Basic. Assume the developer knows what he is doing, at least
to some extent.

[Michael]

Jim wrote:
> Well that is a good point.
>
> But all users will have current displays of committed data, only
> uncommitted data will be held locally in the volatile file.

Possibly, but it is probably a lot of unnecessary overhead to retain
this in a volatile table, which is a very complex structure, when an
array will probably do the job nicely, possibly with an associated btree
structure for indexed access.

> An option for the detail block could be provided; commit line by
> line, or commit only when told to. This way, the developer/end user
> could choose the case that works best for their situation.

That is worth a thought.

> As for minimizing file access, obviously you want to avoid
> unnecessary disk thrashing or network traffic in your design but you
> can't go too far with that. Most of those decisions quite properly
> belong with the application developer/end user. If you go too far,
> you restrict the usability of the resulting control.
>
> Think C, not Basic. Assume the developer knows what he is doing, at
> least to some extent.

Quite true. I am trying to create something that will give people the
option, not force them into a straightjacket.

Ciao, Neil

[JD Kromkowski]

1. Sorting

>> So the first thing is the sorting of the children. The data-aware
>> grid totally fails at this. For example, if I have a bunch of
>> records representing dates that are linked to the master by some
>> unique id, I'd want to display that detailblock in date order. Right
>> now you can't do that.

> The grid component we are using is not a good choice for this sort of
> behavior, but when we added it, it was one of the few options available
> within wxWidgets. In the interim there are others, but they all require
> a significant investment of time and money.

OK, but being able to sort the detailblock the way you want I think is
essential.

> Some people do it this way in Superbase, others do it by defining a row
> at the top that is not actually part of the block, but which acts as if
> it were, and every selection is copied to that row.

Wow, talk about a kludge.

2. Add and Modify/Delete buttons as optional parameters

>> So to me, the presence of an Add button and a Modify/Delete button
>> really should be incorporated right into the detailblock as a option,
>> like a parameter to have a scroll bar or not.

> It is one of the options up for consideration, as is the right-mouse
> pop-up menu approach (less screen real-estate involved).

>> When the detailblock records refer to externals (images or
>> documents),I still like using the invisible button. You are really
>> not doing anything to the row/record "selected", but are using some
>> data in the row/record to open up the image or document (e.g., PDFs,
>> TIFFs, BMPs, Word or WordPerfect) in its native program usually via
>> ShellExecute.

> This could be done by using the double-click support in the onmouse
> event for each control. An extra button is not required.

Yes, the invisible button was a way to simulate a particular ROW onmouse
event.

3. OnSelectRow and OnSelecColumn

>> In the data-aware grids, it's kind of odd that there is no
>> onSelectRow event nor an onSelectColumn.

> I have them on my internal wish list, but they have not yet been
> implemented.

OnCellSelect event

> Actually, I use the oncellselect event of the grid to get that information.

I've not been able to successfully get that to work with the data-aware
grid.

[Georg Redder]

At least a short comment:
I tend to the idea of detailblocks being readonly. As has been said in
other posts, data entry should be made in additional controls or a dialog.
My current approach in SB is to have some not databound controls above or
under the detailblock. If a row is selected, the values are being copied
into these controls, where they can be edited. When saving, I read the
values from these
controls, select the appropriate record and write the values into the
database.
Creating a new record is done by blanking the above controls. Only when
the user saves, a new record is created.
So I don't have to care about adding blank records to the detailblock
My users like this more than the possibility to edit directly in the
detailblock, which I gave them in older programs.
If a Dialog is used for editing, one could even think about a generic
edit-dialog. That means a lot of work, though.
Marking a selected row by highlighting would be a nice and needed feature.
A detailblock could have a property which contains the number of the
selected row or even an array with rownumbers, if multiple

rows have been selected eg. for deleting.

til the days
Georg

[Author]

Posts