At 06:47 PM 28-02-02 +0500, gkrishna wrote:

>Problem 2
>A neat data entry and display screen with for a Master -> Detail ->
>SubDetail.
>Right now I am working on making it work with woll2woll's grid which has a
>editable hierarchical grid.
>
>It does not have to be a hierarchical grid. But I cannot design a neat
>master -> Detail -> Sub Detail entry / Display screen with the IB_
>components. I am open to
>suggestions on this one. Even a screen shot of such a thing would help me
>move in the right direction. A sample application would be great.

OK, I've uploaded 5 screenshots from an app which I use for maintaining the
online FAQ.

http://groups.yahoo.com/group/IBObjects/files/ibo_ui_samples.zip

ibobase1.gif :: The main form of the app shows a select list of all topics
in the main grid with master-detail dependencies to the KeywordTopic and
Keyword tables. The KeywordTopic detail query is in the top grid of the
main panel, the keyword grid is in the lookup control below it. Notice in
the right-hand panel the device I use extensively for data entry interfaces
- displaying the editable/insertable columns in a detail panel which
follows the selector-list scroll. The "Filters" panel above the main
selection grid involves several other master-detail relationships with the
main Topic query. It is disabled in this shot.

ibobase2.gif :: This shot shows the maintenance screen for several of the
inter-dependent tables, which involve several queries with interesting
dependencies. The panel on bottom right uses the devExpress dbExplorer
tree control over a detail dataset which is a TIBOQuery hooked to the main
ib_connection.

ibobase3.gif :: is just a shot with the treeview panel opened up to
demonstrate a master-detail-detail dependency between
topic-category-subcategory.

ibobase4.gif :: shows the main form view with the Filters panel
enabled. Here I'm preparing to do a master-detail-detail swap by picking
up to four optional parameters to "filter" the topics and all their
dependencies. (I NEVER use filters, always parameterised queries. The
filter mechanism is IMHO too noisy for a client/server application...). In
the screenshot I have selected to filter the sets so that I see only topics
to which Helen Borrie responded.

ibobase.gif :: shows the result of the filtering.

This style of ui is very, very fast on response because the IBO controls
don't do any "tickling" of the client-side data - it is all done in the
datasets. The data-linking mechanisms in the native TIB_Datasource involve
a very sophisticated and efficient paradigm. The master-detail
relationships use one member of this paradigm (MasterLinking) whilst the
embedded lookups in the grid use another (KeyLinking).

The mechanics of the native controls are quite different to the TDatasource
mechanics, where the controls "drive" the dataset buffers. In the native
IBO model, the controls derive their behaviour from the attributes of the
datasets and their TIB_Column objects. Since the objective of an efficient
client/server program is to reduce noise on the client side, the native IBO
control model is totally superior to the approach of Tww... controls.

If you want to add "noise and fuss" to the TIB_* controls, you can do it
easily by writing your own descendants.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com