Detail block design for SIMPOL

[Chris Outlaw]

I would like to see detail blocks working much as they do in Superbase.
Additional features, such as a right-click for deleting a row, may be
useful as long as you can revert to the original implementation. The
initial adopters of Simpol will be ex-Superbase users who will be familiar
with detail blocks as they are and most, such as myself, will want to port
applications to Simpol with as little re-design as possible.

I see no attraction in a read-only detail block with buttons, as has been
suggested elsewhere in this forum, as it undermines the power of detail
blocks for rapid data input, such as when entering many items on an order
form.

Chris

[John Roberts]

Whoops Neil, I think I posted this to your email address first.

More quick thoughts – maybe they are workable, maybe not:

>> 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.

NR wrote
> 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.

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

One of the good things about wxWidgets was it used native controls as
opposed to Java etc. I appreciate a detailblock is not a native control but
it should look like one otherwise it might end up like SB later in its life.

An overlaid semi-transparent rectangle with each control coming forward in
Zorder onGotFocus?
It could be resizable to accomodate different size row controls and multi
consectutive selections.
Perhaps another to accomodate the "Glow" onmouseover mentioned in another
post. It is becoming standard these days but depends how far you want to go.
I think the programmer should be able to place their own checkboxes.
That sounds like something you could implement in the personal edition but
not for professional.

> Add a record, Delete a record etc.

Up to the programmer isn't it unless you are thinking of the personal
edition?
Commands to insert/display added data or redisplay if cancelled are
necessary.
Got to be able to blank a row – any row and also edit any row "in-situ".
If someone wants to add a row extra "off DBlock row" for editing/new then
its up to them to decide where and what controls they add. It wouldn't be
much good if other undisplayed fields couldn't be included and another set
of controls had to built to do this.

> 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.

I don't think there is any solution to this other than some virtual store of
records whether it be all the records retrieved so far or just the
uncommitted new/edits. You have a record object so why not collect them with
a new/edit flag (unless it is void without a table object and disk file).
Populate from this. SelectNextPage() goes into the store and is used to
populate the DBlock page. Store saves only the flagged.

If the v store kept only new/edited records then it could be checked for the
presence of a record that might fit in the current page sort order and the
appropriate record inserted.
Screen updates for displayed records changed elsewhere are a problem. Does
the DBlock request an update periodically or does the server notify its
clients? I suppose there are no persistent clients with peer to peer so it
would have to be the former.

>> 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.

To clarify, I meant this needs to be done by the programmer.

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

I ended up doing this (readonly) in SB. It was too fiddly otherwise.

>> 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.

I suppose some sort of menu might make it quicker to place a DBlock on
screen but I don't think this is your responsibility (perhaps it is in
personal edition) but you do need to provide the means to easily place a
menu and appropriate onclick events and retrieval of which physical
row/control is clicked and which record is in there if it is linked to a
dbase.
I agree with a later post about not placing new/edit buttons as an integral
part of the DBlock.

> Doubleclick events don't really exist for everything I think (maybe
> onmouse can help here though).

They need to exist or at the least a method to distinguish between single
and double click.

>Again, are we talking about selecting a
> control, or selecting some piece of window dressing that is trying to
> indicate a row is selected?

Probably both but not just trying.

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

With the grids built in selection capabilities etc it is a pity the controls
can't be rendered straight onto the grid for different data types/display
controls. Then I think DBlocks would be more versatile only in the way they
have dbase links/display capabilities. Scroll the data, not the physical
rows.
Cheers, John

[Michael]

John Roberts wrote:
>> Mark a row (visually as selected) Select one or more rows (do I add
>> a checkbox potentially to the beginning of each row?)
>
> One of the good things about wxWidgets was it used native controls as
> opposed to Java etc. I appreciate a detailblock is not a native
> control but it should look like one otherwise it might end up like SB
> later in its life.

Possibly, but there is nothing like detail blocks that I am aware of.
everything else is just a grid with a single level in it. Some grids
allow the inclusion of additional controls (the wxGrid does not, by the
way, it has a couple of things it supports, like the combobox like cell,
but you can't just embed what you want in a cell, we investigated that
early on). Anything that gets decided on this level will be optional, of
course. The programmer can turn any of the things I am discussing on or
off. They are meant to provide easy-to-use default functionality, not
ram it down everyone's throat.

> An overlaid semi-transparent rectangle with each control coming
> forward in Zorder onGotFocus? It could be resizable to accomodate
> different size row controls and multi consectutive selections.
> Perhaps another to accomodate the "Glow" onmouseover mentioned in
> another post. It is becoming standard these days but depends how far
> you want to go. I think the programmer should be able to place their
> own checkboxes. That sounds like something you could implement in the
> personal edition but not for professional.

Basically only underlaid graphics are possible due to the way the
z-ordering works. I intended to size it according to the row dimensions,
whatever they might be. Since onmouseover is not an available event
(onmouse is, and I might be able to swing something here, but no
promises yet). As for the programmer placing their own checkboxes, they
will certainly have the ability to do that. They wouldn't be part of the
detail block, but outside it, of course.

>> Add a record, Delete a record etc.
>
> Up to the programmer isn't it unless you are thinking of the personal
> edition? Commands to insert/display added data or redisplay if
> cancelled are necessary. Got to be able to blank a row – any row and
> also edit any row "in-situ". If someone wants to add a row extra "off
> DBlock row" for editing/new then its up to them to decide where and
> what controls they add. It wouldn't be much good if other undisplayed
> fields couldn't be included and another set of controls had to built
> to do this.

As I said above, all of the things that I am planning to add to the
detail blocks in this general vein will be optional and can be switched
off by the programmer. As for blanking a row, any row, that depends an
awful lot on how data is added to the detail block. If someone blanks a
given row (by creating a new record), the issue arises what should be
done with the rest of the data. If the row is not committed, where does
it go in the sort order? Do I move it to the correct sorting position
(assuming there is one)? Do I leave it where it is and move everything
down? If instead they add the row via a dialog, the issue arise of is it
committed? If so do they insert it, or do I refresh the detail block and
reset to the top (like Superbase does)?

>> 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.
>
> I don't think there is any solution to this other than some virtual
> store of records whether it be all the records retrieved so far or
> just the uncommitted new/edits. You have a record object so why not
> collect them with a new/edit flag (unless it is void without a table
> object and disk file). Populate from this. SelectNextPage() goes into
> the store and is used to populate the DBlock page. Store saves only
> the flagged.

I had already decided that a virtual store for edited and new records
would need to exist. Any time the user scrolls the detail block, then
the code would have to check the virtual store as it reselects records.

> If the v store kept only new/edited records then it could be checked
> for the presence of a record that might fit in the current page sort
> order and the appropriate record inserted. Screen updates for
> displayed records changed elsewhere are a problem. Does the DBlock
> request an update periodically or does the server notify its clients?
> I suppose there are no persistent clients with peer to peer so it
> would have to be the former.

As the detail block is scrolled up and down, records outside the visible
range will be reread. If there are new ones, they will appear (which
affects the sorting of newly created but not yet committed 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.
>
> To clarify, I meant this needs to be done by the programmer.

That may be true, but the detail block design needs to foresee and
accommodate these sorts of issues.

>> Actually, I would always make these controls read-only/disabled.
>> The only way they could get their content filled is by exercising
>> the link.
>
> I ended up doing this (readonly) in SB. It was too fiddly otherwise.

The problem is that in 99.9% of cases, you shouldn't be locking and/or
changing a record in a lookup table this way. The rare case is where
someone has designed an extension table to the original which is
one-to-one with the other table. In these rare cases, the programmer can
manage this by themselves. Most people would just extend the table
definition to add the required fields.

>>> 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.
>
> I suppose some sort of menu might make it quicker to place a DBlock
> on screen but I don't think this is your responsibility (perhaps it
> is in personal edition) but you do need to provide the means to
> easily place a menu and appropriate onclick events and retrieval of
> which physical row/control is clicked and which record is in there if
> it is linked to a dbase. I agree with a later post about not placing
> new/edit buttons as an integral part of the DBlock.

Actually, there is no difference between Personal and the rest. It also
just uses the facilities provided. As for the other bits, if you click
on a control, every one of them has an ongotfocus event and the the
handler function, if defined, receives the control as an argument. Once
you have the control you can find out which row it is in, which detail
block, etc. There is a method for retrieving the record associated with
a given row. Adding buttons was just a discussion topic. Again, were
they to bae added as an integral option, the functionality could be
disabled.

>> Doubleclick events don't really exist for everything I think (maybe
>> onmouse can help here though).
>
> They need to exist or at the least a method to distinguish between
> single and double click.

Not every control has a click event. All controls have an ongotfocus
event. Checkboxes and option buttons have an onchange event, pushbuttons
have an onclick event, edit controls have a number of events, but no
onclick. All controls have an onmouse, which provides quite a wide array
of events that you can ask it to watch for:

left button down
left button up
left button double click
middle button down
middle button up
middle button dbl click
right button down
right button up
right button dbl click
motion

>> Again, are we talking about selecting a control, or selecting some
>> piece of window dressing that is trying to indicate a row is
>> selected?
>
> Probably both but not just trying.

The real issue with deciding what indicates a row is selected is
deciding what it will look like, how it is implemented, and to what
degree it can be modified by the programmer.

>> Detail blocks are not grids. They are more versatile than grids.
>> For grids, I already have dataform1datagrid. Ciao, Neil
>
> With the grids built in selection capabilities etc it is a pity the
> controls can't be rendered straight onto the grid for different data
> types/display controls. Then I think DBlocks would be more versatile
> only in the way they have dbase links/display capabilities. Scroll
> the data, not the physical rows. Cheers, John

True, but this limitation is built into wxWidgets. Although we could
potentially change that, it is not a trivial task.

Cioa, Neil

[Michael]

JDK wrote:

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

I agree. It is just important that people realize that it can be a
performance issue with large numbers of records (or if they are
retrieving their data over a slow connection).

>
>> 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.

I have seen these apps. They work, the solution is intuitive and fairly
elegant, and it keeps the user on the form instead of opening a dialog
for data-entry.

> 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.

Hmm. It should work. I will have a look see.

Ciao, Neil

[Michael]

Chris wrote:
> I would like to see detail blocks working much as they do in
> Superbase. Additional features, such as a right-click for deleting a
> row, may be useful as long as you can revert to the original
> implementation. The initial adopters of Simpol will be ex-Superbase
> users who will be familiar with detail blocks as they are and most,
> such as myself, will want to port applications to Simpol with as
> little re-design as possible.
>
> I see no attraction in a read-only detail block with buttons, as has
> been suggested elsewhere in this forum, as it undermines the power of
> detail blocks for rapid data input, such as when entering many items
> on an order form.

That is a good point. For detail blocks that are being used in this way,
all the standard Superbase design decisions work fairly well, up to and
including creating a new row when the user tabs out of the last visible
row. I am inclined to say that even that behavior should be an option
that is enabled or disabled.

Ciao, Neil

[Philip Goodfellow]

I do use detail blocks for data entry (although rarely for creating new
records: the forms used by others tend to enter data into pre-defined
records). One typical form for me mimics a school mark-book (U.S
grade-book ?). A spreadsheet style block, where a user can move focus
both horizontally and vertically, entering data, would be the ideal
here, although the current detail block pattern where the user tabs to
end of the the row and then focus move to the next is ok. Another
typical form format for my application is a school timetable
(schedule?). Here each lesson day within the timetable is a detail row
and each period in the day is a child of that row. Users do enter data
into records within that child cell – they do not create new records
(the number of lessons for a class is clearly a known fixed number and
the records created in advance by me).

I have not yet tried Simpol, definitely waiting for detail block
implementation. I've not seen any other program, either open source or
proprietary (at least not in my price range) that would do what I do
with Superbase yet either.

Philip Goodfellow

On 25/11/2009 14:28, Neil Robinson wrote:
> 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

[Philip Goodfellow]

I agree. Sorting of detail block, and child blocks is critical. At least
to "index order".

(I think it was Neil who gave me a code snippet to sort the detail
blocks in Superbase 1.2? that got me started in the first place, almost
20 years ago!)

Philip

On 25/11/2009 21:46, JDK wrote:
>
> 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.
>
>
>

[Philip Goodfellow]

I use all of this behaviour – although the tabbing off the end to create
new records tends to be limited to forms "for my use only". I can't make
it fool proof enough for other's use.
I think I would happily replace "tabing off the end" with an "add
button" if that were implemented but I wouldn't want to loose the
ability to edit within detail block fields.

Philip Goodfellow

On 26/11/2009 12:09, Neil Robinson wrote:

Chris wrote:
>> I see no attraction in a read-only detail block with buttons, as has
>> > been suggested elsewhere in this forum, as it undermines the power of
>> > detail blocks for rapid data input, such as when entering many items
>> > on an order form.

> That is a good point. For detail blocks that are being used in this way,
> all the standard Superbase design decisions work fairly well, up to and
> including creating a new row when the user tabs out of the last visible
> row. I am inclined to say that even that behavior should be an option
> that is enabled or disabled.
>
> Ciao, Neil

[Philip Goodfellow]

I am impressed with the care you are taking to get detail blocks right.
Detail blocks are *the* unique selling point of Superbase and could be
the same for Simpol. It is important that you do it well!

Philip Goodfellow

[Michael]

user@domain.invalid wrote:
> I am impressed with the care you are taking to get detail blocks
> right. Detail blocks are *the* unique selling point of Superbase and
> could be the same for Simpol. It is important that you do it well!

Thanks Philip,

I think that detail blocks done right could be a big selling point. I
just want to make sure that whatever design I finally settle on meets
the vast majority of people's needs. At the same time, it has to perform
at an acceptable speed, and it has to be doable. I am currently thinking
of implementing these in stages, where stage one may not include child
detail blocks. That way we can give a decent shakedown cruise to the new
design before complicating it even further.

Ciao, Neil

[John Roberts]

"Neil Robinson" <neil@simpol.com> wrote in message
news:heh6lv$g5t$1@ipx22096.ipxserver.de…
> 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.
>
> 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.
> Ciao, Neil

If it is a similar construct to SB then it will be hard to do a listctrl
type selection look. I expect you have already thought about it a lot but
some options I see are:

1. Reverse colour text and background for controls in the row – I have
tended to use this but may not work for bitmaps
2. Either an icon or rectangle that moves down the left and positions itself
next to the selected row to denote selection
3. A column of rectangles/buttons down the left with colour change +/- some
character to denote selection
4. Rectangular dotted line around the row with the height dimension of the
largest control

Cheers, John

[Michael]

John Roberts wrote:
> If it is a similar construct to SB then it will be hard to do a
> listctrl type selection look. I expect you have already thought about
> it a lot but some options I see are:
>
> 1. Reverse colour text and background for controls in the row – I
> have tended to use this but may not work for bitmaps 2. Either an
> icon or rectangle that moves down the left and positions itself next
> to the selected row to denote selection 3. A column of
> rectangles/buttons down the left with colour change +/- some
> character to denote selection 4. Rectangular dotted line around the
> row with the height dimension of the largest control

I was tending toward 4, though not dotted (I don't think I have dotted
lines currently in SIMPOL wxgraphicrectangle).

Ciao, Neil

[Author]

Posts