I have a launch page with two parameters chained together. I have associated two combo boxes with these parameters.

When I run the html page the first combo box gets populated but the second one doesn't. The first combo box get populated from a data source (text file). The second one gets populated using a fex file that reads another text file.

A similar html file using the same data sources but in a different domain is working just fine.

Balram,

Please post the two SELECT statements for the combos from your HTML and the two fexes that are used to populate them.

Also, please update your signature to show what release and what platform you are on. This helps us to target your particular requirements.

T

It's my understanding that in order to chain elements together the fields for each list box have to be from the same table (per NY). How I got around this was to create a fex that joins the two data sources together and create a hold file. The mfd will then appear in your list of mfds in html layout painter. You can now use the hold mfd to populate your list boxes and chain them together. I scheduled a job through reportcaster that would rebuild the hold file every night because it was possible that the data could change daily (student data)

As linus stated, the best way is to be able to join the resources together and have a sing result

JOIN F1 IN A TO F2 IN B
TABLE FILE A
PRINT DST.A1_DESC
DST.B1_DESC
BY A1_VALUE
BY B1_VALUE
ON TABLE SET HOLDLIST PRINTONLY
ON TABLE PCHOLD FORMAT XML
END

With this situation, the values would be cached which is the default.

What you did, where you have two separate sources that are not currently joined, you will need to turn the caching off. From the HTML painter, click on the button that shows the chain order. Once you have the chain order, right-click on one of the select boxes and uncheck the Cache Values option.

But as stated before, it would be preferable if you wrote a procedure to bring everything together first.

Just a warning, when you do use the cache feature from a procedure, it does not appear to be working from within the painter (all of the chains have the same values), but when you launch the HTML page, it works fine.

Tony Here are the SELECT statements from the HTML file
...SELECT id=ITEM3 style="Z-INDEX: 2; LEFT: 210px; WIDTH: 275px; POSITION: absolute; TOP: 180px; HEIGHT: 22px" name ="LOCID" elementname="combobox3" elementtype="combobox" sourcetype="typeMaster" labelid caption="combobox" operation="NONE" ibiformat datatype="1" addalloption="0" dynalldisplayvalue="ALL" inchainindex="1" chainnumber="0" cacheruntimedata="0" displayfield="LOCNAME" numofrecords="-1" datafield="LOCID" datasource="PHONE_MS.mas" datafieldtype="INTEGER"

...SELECT id=ITEM8 style="Z-INDEX: 7; LEFT: 210px; WIDTH: 275px; POSITION: absolute; TOP: 220px; HEIGHT: 22px" name ="RPTID" elementname="combobox8" elementtype="combobox" labelid caption="combobox" operation="NONE" ibiformat datatype="1" addalloption="0" dynalldisplayvalue="ALL" inchainindex="2" chainnumber="0" cacheruntimedata="0" displayfield numofrecords="-1" datafield sourcetype="typeFex" datasource="app/rpttypes.fex" IBIMR_folder="#newfolderysg" IBIC_server="EDASERVE" datafieldtype


The first combo box is getting populated by this master file
FILE=LOCS, SUFFIX=FIX, DATASET=C:\IBI\APPS\TELERPRTMETADATA\PHONE_MS.DAT
SEGNAME=ROOT_SEG, SEGTYPE=S1, $
FIELD=LOCID, ALIAS=FIELD1, FORMAT=I6, $
FIELD=LOCNAME, ALIAS=LOCNAME, FORMAT=A40, $

The second combo box is using the fex file below:
TABLE FILE RPTTYPES
PRINT
RPTID
RPTNAME
WHERE INT(LOCID) EQ &LOCID;
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT XML
END

linus/Gizmo, This html was working just fine. As I said before, another html with the same chain and the same data sources, is working OK. Only difference is that it is in a different domain. I would like to first try to resolve this issue (if possible) without changes to the code (which would have to be done in dev, qa and production). Appreciate your suggestions. I'll try it out.

This message has been edited. Last edited by: Balram Vedavyas,

Just a thought. Make sure a 'Display field' is entered in the Parameter tab.

1. Open the HTML file in question
2. Click on the 'Parameter' tab on the bottom of the 'Properties' window
3. Click on a control
4. In the window listing the fields, click and drag the appropriate field into
the 'Display Field' box.

Had similar issue, seems there is some setting relating to cache that needs to be 'off' regarding the properties of the selection box. Can't recall the 'fix' as I think our admin set it as a default.

Spence,

I am still running 5.3.3. The interface is therefore different. I assume the functionality is still the same. Please correct me if I am wrong.

In the first select there is a DISPLAYFIELD specified. In the second case, since the source is a FEX I cannot specify the DISPLAYFIELD.

Balram,

Looks OK all to me, you have the necessary components in the SELECT tags and the fex looks alright as well.

The only thing I would suugest you do (and this may not be the problem) is to add a DEFAULT value for &LOCID of FOC_NONE -

-DEFAULT &LOCID = 'FOC_NONE'

If that doesn't work then I would move on to the IBIRLS.JS module and add a few ALERT statements within the populatedynamicchain function to see what you are getting back (if anything) from the population.

If you do modify the IBIRLS.JS file then make a backup beforehand and remember to restore the original when you have sorted out the problem.

T

Tony,

Specifying a default value did not help.

About the IBIRLS.JS file. This is a file that is common to all defined domains, isn't it?

Balram

Balram,

It is an IB supplied file, it is common to an installation whether you have MRE, self serve etc. This file is hauled into each launch page created using RLP and is responsible for achieving the chaining and dynamic population of the form controls (amongst other things). It is a fairly lengthy (as you would expect) piece of coding and one that I would recommend trying to understand if you want to know about problems within launch pages. There are a lot of things that the code will allow that is not really used throughout most shops and it is a shame because a lot of effort has been put into it. I normally have a version with a fair few alerts contained within so that I just do a quick rename to start probelm determination.

In 7.1 (I think) the module was superceded by IBIRLS2.js but the former version still lurks around and can be used instead for backward compatability.

One of the problems (in my view) with the later version is that it creates onchange events for comboboxes and in doing so overwrites anything that the developer might have in place. It would have been better to have appended another onchange event rather than overwrite it. This new method caused quite a few problems initially! (for me anyway )

Good luck

T

Gizmo,

Checked the Cache Values option. It was already unchecked.

quote:

What you did, where you have two separate sources that are not currently joined, you will need to turn the caching off. From the HTML painter, click on the button that shows the chain order. Once you have the chain order, right-click on one of the select boxes and uncheck the Cache Values option.

Balram

Tony

I have put in a request to get a copy of the IBIRLS2.js file. In the meanwhile here is what I discovered.....

I copied and pasted files (every file except the html and fex that is launched by the html) from the domain A, where the chain was not working, to domain B, where it was working (Note that I also copied the fex that the second parameter/combobox uses). Both domains use the same application path and master file (for the first combo box). After the copy the chain stopped working in domain B too. The first combo box is populated but not the second one.

Do you think it is the fex associated with the second combobox that is causing the problem?

Balram,

Quite possibly ....

To test to see that it gets output just execute it to see the XML output. To see what you would expect upon initial page load, use a DEFAULT setting for your variable equal to the value used for the first entry in your first chained combo.

If you get no XML data output (just the headers etc.) then you can be fairly certain that your fex is at fault.

T

The fex runs fine... result looks ok too

Resolved the issue (I think so)........

I altered the WHERE clause in the fex from

INT(LOCID) EQ &LOCID;

to

INT(LOCID) EQ INT(&LOCID);

The question still remains... How was the WHERE clause working earlier (it was in place for almost two years now) and what caused it to stop working?