Re: Multi row blocks

Hi Mark,

Thanks for that comprehensive reply.
I'm not a forms programmer, so wont pretend to understand some all of what you say.
I needed to ask the question, as our main forms guru says it simply cant be done.

In a nut shell, we simply want ot have full (manual) control over the contents of a grid like structure, (presumably made with a MRB), with some cells empty, and some rows being able to show/hide them selves depending on the actions of the user.
The best way I can describe that would be similar would be the interaction with a Treeview, whereby one column of the grid would contain a + or - depending upon the current show/hide state of related (child data).

If all this seems like too much work, is there a simple way to get active-x grids into 9i forms?

Hope this makes sense, I'm writing this very late, and my mind is all foggy, although that could be thee wine :)

Regards
Jules

"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in message news:pp-dnfk9Du3zoeXdRVn-jg_at_comcast.com...
>
> "Julesm" <julesm_at_ip242yh.plus.com> wrote in message
> news:sxVdc.31589$Y%6.3947662_at_wards.force9.net...
> | Sorry I thought I made it clear enough.
> |
> | I'm trying to imitate grid functionality.
> | Am I right that (even for a database related system) oracle doesnt have
a
> | grid?
> | Am I also right that Multi Row Blocks are the closest a programmer get
to
> | having a real grid?
> | If an MRB is all we have, can I load it cell by cell with whatever I
want,
> | ie not point it at a datasource.
> |
> | Regards
> | Jules
> |
>
> actually it's not 'even for a database related system' but precisely
because
> its a database-centric tool that Forms does not have a built-in grid in
the
> sense that you want to use one
>
> the philosophy of forms was simply as a way to display and update database
> tables -- it did not evolve as/from a general-purpose programming
language
> to present any type of UI/GUI that seemed appropriate. in other words...
> it's a little narrow minded in its approach
>
> if you're not dropping in an active-x or java grid, then you'll have to
> program around oracle's standard table:block mentality. historically, if a
> row does not exist in the table, then the basic option allowed in forms is
> to add (queue up) one new row at time, in sequential order (that is,
> sequential within the list of displayed rows -- there is also an option to
> insert a new row after the current record). such rows are all flagged for
> insert and must either be writing to a database table (or updatable view)
or
> discarded
>
> forms functionality has been enhanced (cobbled) to allow blocks that are
not
> based on tables/views, and to have some control over the default
transaction
> processing
>
> so, you can :
> [_] create a block that has no base table (DML Data Target Name and Query
> Data Source Name)
> [_] allow the user to enter data in multiple rows of the block
> -- but only if all prior rows in the block have at least one column that
> contains data
> [_] write code to manipulate the data in the rows
> --- some of this code would typically be invoked from KEY-* triggers
> (KEY-ENTQRY, KEY-EXEQRY, KEY-COMMIT, KEY-CLRBLK, KEY-CLRFRM, etc), since
the
> triggers associated with keys are fired from both standard and custom menu
> items
> -- you could also supply a dummy table name (could even be the name of a
> real table), which would enable Query/Transaction processing, but then
write
> your own ON-INSERT, ON-UPDATE, ON-DELETE, ON-SELECT triggers to handle the
> actual transaction
>
> in order to do this successfully, you will need to have a thorough
> understanding of forms event processing
>
> among other things, you will need to prevent forms from clearing the block
> and/or the form until you've processed your rows
> you will probably need to pre-create some rows in the 'grid' so that the
use
> can mouse-click on the desired row (perhaps using the
> WHEN-NEW-BLOCK-INSTANCE trigger), and/or you will need to write a
> WHEN-NEW-RECORD-INSTANCE trigger to set some default value on new rows, so
> the user can arrow down thru the records
>
> you will also need to keep track of the status of each row (likely within
a
> hidden TEXT_ITEM)
>
> sample WHEN-NEW-BLOCK-INSTANCE trigger (assuming a TEXT_ITEM named SEQ:
>
> for x in 1..6
> loop
> :seq := x;
> next_record;
> end loop;
> go_record(1);
>
> sample WHEN-NEW-RECORD-INSTANCE trigger:
>
> :seq := :system.cursor_record;
>
>
>
> could you describe the actual business functionality you're trying to
> implement, rather than just the technique you want to use?
>
>
> ;-{ mcs
>
>
Received on Sat Apr 10 2004 - 17:42:45 CDT