Detail Blocks

[JD Kromkowski]

I was explicitly advised that detail blocks were part of this release. But alas, they are not. I see the data-aware grid. It isn’t quite the same thing. First, I can’t sort the child data. Second, I can’t get rid of the row labels. Third, I can’t control the graphic properties. In Form Designer, you can select the data-aware grid, and right mouse and chose graphic properties and “seem” as if you are changing things. But nothing obviously “sticks”. There are other niggles, which I’ve leave for later.

[Michael]

John Kromkowski wrote:

> I was explicitly advised that detail blocks were part of this release. But
> alas, they are not.

I am a little surprised, since I am sure we specifically said that they
would not be ready for this release, but that data-aware grids would be.

> I see the data-aware grid. It isn't quite the same thing.

Sure, it doesn't support multiple levels and doesn't support disparate
controls.

> First, I can't sort the child data.

I appreciate that. This is a first cut, meant primarily to invite comment
since this is the point where we can make changes and improvements before
it is set in stone.

> Second, I can't get rid of the row labels.

You can't do it graphically, and you probably shouldn#t be able to do it
(but you can) programmatically. The issue here is that once they are made
read/write, the row labes area will be used to indicate which row is being
changed, whether the row has been changed, etc.

> Third, I can't control the graphic properties. In Form Designer, you can
> select the data-aware grid, and right mouse and chose graphic properties
> and "seem" as if you are changing things. But nothing obviously "sticks".

Sorry about that. I will have to make sure that you can't select graphic
properties if you have the grid selected. If you double click on it, you
will see what can be done to the grid. If it isn't there, you shouldn't
look for it elsewhere. Some things can be changed programmatically. (You
can set the rowlabelwidth to 1 for example).

> There are other niggles, which I've leave for later.

I am sure there will be more, but we needed to start this process moving.

Ciao, Neil

[JD Kromkowski]

Neil Robinson wrote:
> John Kromkowski wrote:
>
>> I was explicitly advised that detail blocks were part of this release.
>> But alas, they are not.
>
> I am a little surprised, since I am sure we specifically said that they
> would not be ready for this release, but that data-aware grids would be.

Well, perhaps I am mistaken I thought I asked Rufus the question during
the conference. I'm not sure that going through the record will be of
any help at this point. You might also look at your 10/14/08 post,
which made it sound like the code was done.

But you'd have to admit that even a data-aware grid that doesn't support
sorting is basically not much of a sophistication over the grid stuffing
thing I previously posting.

Surely, if you revealed bit of the code you`re using to do the
data-aware grid, somebody here could whip up pretty quickly a
programatic version detailblocks, to tweek the dataform program
generated by the save as in the form designer.

I may even try my hand at but it would be kind of pathetic if the lawyer
non-programmer worked it before everyone else.

[Michael]

jdk wrote:
> Neil Robinson wrote:
>> John Kromkowski wrote:
>>
>>> I was explicitly advised that detail blocks were part of this
>>> release. But alas, they are not.
>>
>> I am a little surprised, since I am sure we specifically said that
>> they would not be ready for this release, but that data-aware grids
>> would be.
>
> Well, perhaps I am mistaken I thought I asked Rufus the question
> during the conference. I'm not sure that going through the record
> will be of any help at this point. You might also look at your
> 10/14/08 post, which made it sound like the code was done.
>
> But you'd have to admit that even a data-aware grid that doesn't
> support sorting is basically not much of a sophistication over the
> grid stuffing thing I previously posting.

Unfortunately, the grid control we are using doesn't provide for buttons
being inserted into the control. The only way to do sorting is via a
popup menu. We *are* looking at another control that is more like a
listbox, but with columns and clickable headers, but until that is
wrapped, we will have to live with the standard grid. As for the thing
you recently posted, which is little more than a basic table view, this
one is generic, linkable to other tables that themselves are controlled
by their own links, can support additional linked columns within the
block, etc. A large part of the development time was spent also creating
the linking tools. The programmatic version I had working fairly
quickly, the drawing support for the Form Designer was a lot more work.

> Surely, if you revealed bit of the code you`re using to do the
> data-aware grid, somebody here could whip up pretty quickly a
> programatic version detailblocks, to tweek the dataform program
> generated by the save as in the form designer.

A programmatic version of detail blocks that does what? It would have
been fairly trivial to give you single-level detail blocks. The problems
begin with the more advanced features, and unless they are accommodated
in the original design, the risk is very high that anything I released
early would be broken by later changes.

> I may even try my hand at but it would be kind of pathetic if the
> lawyer non-programmer worked it before everyone else.

Be my guest. If it were that simple I would have released them by now.
Don't forget that Superbase detail blocks support both rows and columns,
can be nested up to 8 levels deep, can have linked tables, each block
can be sorted ascending or descending, can have scroll bars (right or
left), and will need to support potentially thousands or even millions
of dependent records efficiently. They can also be unlinked. What do you
intend to do with the records that have been changed? If the form is
locked, do you lock all the records? When do you save changes? If you
don't commit them early, what happens when a changed record scrolls off
the screen? How do you add new ones? How do you delete a row? How do you
make sure it runs fast?

I have looked at all of these issues while doing the design work, plus
more as well. If you think you have a brilliant solution, I am all ears.
There is probably a good reason why you have never seen detail blocks in
any other commercial product. The design is difficult beyond belief to
get right and have work efficiently. Even the one in Superbase has
numerous flaws that we are all aware of, such as dealing with new
records after the first page is full, or deleting records.

Ciao, Neil

[JD Kromkowski]

First, I don't want you to take this personally, even though I know you
have invested a ton of your "person" in this. It is business. If you
don't have customers or potential customers complaining then you might not
actually have any customers. Most customers or potential customers don't
complain, they just drift away. If no is complaining or posting here, then
you should be worried.

NR: > Unfortunately, the grid control we are using doesn't provide for
buttons
> being inserted into the control. The only way to do sorting is via a
> popup menu.

JDK: I perhaps was not clear. We one creates the data-aware grid, one
selects the table and the fields and can make some minor adjustments.
(column labels, font, whether column are sizeable, etc.) It is at that
point that one should be able to sort the data that is being stuffed into
the grid. All that is required is setting the correct index. Unless the
problem is that the current solution must set the index to the linking
field for the right data to be put into data-aware grid.

For example, lest say a have a Master file for a particle Matter and then
I have another Child file for the Dates associated with that Matter. So
"Dates" get put into the array which correspond to the particle Matter.
But it does little good if those dates aren't in the grid arranged in date
order.

NR:
> We *are* looking at another control that is more like a
> listbox, but with columns and clickable headers, but until that is
> wrapped, we will have to live with the standard grid.

If you go back through the posts about detailblocks; you will find I
indicated that I have used Request 25 and or a Dialog with a Listbox as a
poor man's "popup detailblock" (which are obviously orderable), and I
wondered whether something like that was what was intended path.

You advised that your Drilldown thing was the better solution and that
detailblocks were going to be implemented. The problem has always been
WHEN.

I am interested in avoid "the Perfection is the Enemy of the Good"
problem. I am for Rapid Application Development WITH continuous and
incremental improvement.

If it would have been, as you say, "been fairly trivial to give you
single-level detail blocks", then why haven't you. As an interim working
solution, while you sort out all of the "advanced" features.

It doesn't matter to me, and I doubt to anybody, that what you release
later MIGHT break the "trivial single-level detail blocks". If your
subsequent improvement is better it will be trivial for the
developer/would be programmer to go click click click and redo the form
even from scratch with the advanced stuff.

What you indicated in October 2008 was the the detailblock stuff had been
coded and it was just a matter of the UI part. So show us the code so that
we can at least do it programmatically while the perfect UI stuff is being
fine tuned.

NR: > As for the thing
> you recently posted, which is little more than a basic table view,

JDK: Which quite frankly is all you data-aware grid is. Except mine is
sortable!

NR: > this
> one is generic, linkable to other tables that themselves are controlled
> by their own links, can support additional linked columns within the
> block, etc.

JDK: Of course, yours is generic. What I posted was a mess of spaghetti
and not generic. What got posted was a couple of hours worth of time that
represents an ideogram. I don't make my money by writing programs, I make
my money by going to court and negotiating on behalf of my clients.

> Be my guest. If it were that simple I would have released them by now.
> Don't forget that Superbase detail blocks support both rows and columns,
> can be nested up to 8 levels deep, can have linked tables, each block
> can be sorted ascending or descending, can have scroll bars (right or
> left), and will need to support potentially thousands or even millions
> of dependent records efficiently. They can also be unlinked. What do you
> intend to do with the records that have been changed?

JDK: First, I don't need 8 freaking levels deep. I do need to support
thousands of records efficiently and my little experiment with a table
view (which by the way is STILL absent from this release) really showed
that when you get passed a couple of hundred records there is a time
problem of efficiently running through the records. I just don't know
enough about how to optimize this kind of thing in Simpol with the SBME
object. The lack of a direct SELECT WHERE equivalent is problematic.

As to changing records, I abandoned changing detailblock records on the
form where they show up, over a decade ago. I either use an invisible
button to bring up a dialog or form masquerading as a dialog for the
record chosen, or I use a modify button to bring up a listbox or request
that allows the user to select precisely the record that they wish to
change or delete.

NR:>If the form is
> locked, do you lock all the records? When do you save changes? If you
> don't commit them early, what happens when a changed record scrolls off
> the screen? How do you add new ones? How do you delete a row? How do you
> make sure it runs fast?

I think I do that all now and don't even use ROW or DROW.

> I have looked at all of these issues while doing the design work, plus
> more as well. If you think you have a brilliant solution, I am all ears.
> There is probably a good reason why you have never seen detail blocks in
> any other commercial product. The design is difficult beyond belief to
> get right and have work efficiently.

JDK: Yes it is difficult. So what. Customers and Potential customer don't
care about that, they have their own difficult things they do. And that
is the choice that Simpol Ltd made.

But having detailblocks even one trivial level deep is what could separate
your product from the rest, it is one of the things that made SB powerful.

NR:> Even the one in Superbase has
> numerous flaws that we are all aware of, such as dealing with new
> records after the first page is full, or deleting records.

JDK: Of course it had flaws, but even a dingbat like me has figured a way
around them.

[Author]

Posts