Re: Multi row blocks

From: Mark C. Stock <mcstockX_at_Xenquery>
Date: Sat, 10 Apr 2004 14:26:42 -0400
Message-ID: <pp-dnfk9Du3zoeXdRVn-jg@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 - 13:26:42 CDT