[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

353.0. "Index form techniques" by BRUMMY::MARTIN::BELL (Martin Bell, TCC, Birmingham UK) Mon Mar 30 1992 10:41

Yet again, brain fade has taken place, and i am unable to think logically!

Suppose i have an INDEX form with a scrolled region displaying some
phantom dataset (eg *PHANTOM) in the normal way.

Now the user can enter some index option to create another collection of
records and display them in the scrolled region, replacing the initial
collection, eg.

BIND *PHANTOM TO DATASET WITH {some RSE expression)

but if the RSE returns no records, i want to leave the original phantom
dataset intact and just display a message such as "no records found".

So i thought that i would BIND with another phantom dataset, and if that
contained records i would bind it to the first, otherwise i would leave
the first intact. Something along the lines of ...

bind *NEWPHANTOM to DATASET with(some RSE expression)
.if *NEWPHANTOM contains records
 then bind *PHANTOM to *NEWPHANTOM
 else display "No records found"

.. which works fine so far.

The trouble is, if i want to perform a similar action again, i cannot BREAK
the phantom dataset *NEWPHANTOM because it is still being used by *PHANTOM,
so i end up creating a new "version" of *NEWPHANTOM. This still allows me to
perform the code segment above, but when i re-bind *PHANTOM, the previous
version of *NEWPHANTOM still exists.

BIND_STATUS would look something like

*PHANTOM               - *NEWPHANTOM (some RSE)
*NEWPHANTOM             - DATASET
NEWPHANTOM              - DATASET

... and everytime you perform another index, another version of NEWPHANTOM
will appear.

How can i get rid of the old version of *NEWPHANTOM without destroying the
current one? Is this a sensible way of coding INDEXes in the first place?

Thanks in advance,

mb

p.s.

You can tell that we have _just_ changed to British SUMMER time over here,
because it has just started snowing!
T.RTitleUserPersonal
Name		DateLines
353.1Place to steal from?IOSG::MAURICEIOSG ain't a place to raise a kidMon Mar 30 1992 10:5415
    Hi,
    
    I think the technique you want is to alternate two phantoms. For an
    example have a look at form EM$INDEX. Symbols #EMIPH and #NEWPH are
    used to contain either "*EMI1" or "*EMI2". At the end of the ~~BIND~~
    XOP the logic is to test whether the #NEWPH has any records, and if so
    to do the following:
    
    OA$SCL_EXIT (break connection between scrolled region and phantom)
    BIND_BREAK  (old phantom)
    OA$SCL_INIT (make connection with new phantom)
    
    Cheers
    
    Stuart
353.2Another suggestionSHALOT::NICODEMWho told you I'm paranoid???Mon Mar 30 1992 15:4224
	The alternating of two phantoms can certainly work, and you already have
examples of that in EM and WP.  However, I wonder, in your specific case, if
there might not be a simpler, quicker method.

	You indicated that you *may* want to change the scrolled region, IF
there are records in the new "collection".  Well, you have some kind of RSE that
you're using to BIND the new phantom; why not first just run a FOR loop and
check OA$SEL_COUNT to see if it's non-zero?  In other words, if your eventual
BIND statement would say:

	BIND *PHANTOM TO dataset WITH rse

then right before that, do something like:

	FOR dataset WITH rse
	.IF OA$SEL_COUNT NE 0 THEN BIND *PHANTOM TO dataset WITH rse

	I realize that it may be a bit redundant, but you'll have to decide for
your specific case if that'll work.

	F

	P.S.  Our time doesn't change until *next* weekend...  so we're still
allowed to have crummy weather!
353.3GeminiBRUMMY::MARTIN::BELLMartin Bell, TCC, Birmingham UKMon Mar 30 1992 15:4810
Thanks for the pointer Stuart!

I started looking at standard ALL-IN-1 code, but just about every INDEX form
seems to use a different technique, thus i started from first principles.

The double-barrelled phantom alternator looks like the way to go!

Cheers,

Martin
353.4BRUMMY::MARTIN::BELLMartin Bell, TCC, Birmingham UKMon Mar 30 1992 16:2724
Re: .2

Frank,

I don't really want to perform unnecessary FORs as the source data-set will
probably be quite large and the RSE may be quite complex.

Even if i do a "FOR FIRST dataset WITH rse" it could take quite a search!

I reckon the dubbul-dabble is the way to go (and i have only just got my head
around the single one)  :-)


Incidentally, is there still a limit to the size of the BIND rse within named
data - is it best to use a script for complex (ie LONG) expressions?

Cheers,

mb

p.s.

Looking out of the window, it appears that we put our clocks backward 6 hours -
it is nearly dark outside and it is only 3:30!
353.5I just couldn't resist... 8-)SHALOT::DUNCANJoe - CIS/EIC Doc. Mgmt. Solution Set ConsultantMon Mar 30 1992 19:089
>	Incidentally, is there still a limit to the size of the BIND rse within named
>	data - is it best to use a script for complex (ie LONG) expressions?

	 Given that Rdb can handle much more complex "RSE's" than can
	 ALL-IN-1, one option might be to migrate your application to Rdb,
	 use SRA, and bind your dataset to a view!

	 Joe Duncan @ OPA