One of the most tedious tasks I can imagine is to add a new parameter to an existing page. Compound that by having to do it for five pages and it becomes almost unbearable.

This message has been edited. Last edited by: Francis Mariani,

I agree the HTML editor isn't the best I've seen.

But simply reassigning the run button to the fex will prompt to add the new parameter(s).

You then can either:
Select the Form where to add it. Only thing you have to is some positioning and layout.
or
Just tell it to not add the parameter and add a inputcontrol yourself and assign in to the correct parameter.

Trick is ofcourse to add as much information about the parameter in the fex. This all will be copied to the fex.

e.g.
NOT
-PROMPT &PARAM_A;
And then having to rename it to "Choose reporttype" and changing it to a dropdown with TYPEA "Total recap" and TYPEB "Detailed".

But
-PROMPT &PARAM_A.(<'Total recap',TYPEA>,<'Detailed',TYPEB>).Choose reporttype.;


And as a good practice. I start all fexi with a list of -PROMPTs to prevent having such big parameter in the code some where.

e.g.
-PROMPT &MNTH.Please enter monthnumber.;

TABLE
...
WHERE MONTHNR EQ &MNTH
END

and not

TABLE
...
WHERE MONTHNR EQ &MNTH.Please enter monthnumber.
END



...don't leave a mess.

Interesting suggestion about the -PROMPT statement, I don't think we use that anywhere. I'll have to experimant with that a bit...

Adding a new parameter is not always that simple, unfortunately.

What happens with some regularity is that we create a launch page with dropdown selections for a few parameters and add some extra chained pre-selection dropdowns to guide the user to the relevant values.

Say, people need to select a CAR, but with the long list of available CARs, it helps to first select a COUNTRY. CAR gets posted to the report, COUNTRY does not.

Then at some later point, there is a requirement to add a COUNTRY parameter to the report as well, for which the existing COUNTRY dropdown is the obvious choice. So, as explained by Dave, we re-bind the Submit button control and let it detect the new parameter and choose to bind it to the existing COUNTRY control. So far so good, however...

On assigning that new COUNTRY parameter to the existing COUNTRY control, HTML Composer deems it necessary to wipe the embedded procedure definition of said control! What on earth for?!? VERY annoying!

Seems a small problem, but it's really not when someone else initially created the report some years ago and you don't even know which file they used to populate the now empty dropdown control!

In such cases we revert the changes to the HTML file using our source control system and start over, this time creating a copy of the contents of the dropdown before assigning the new parameter to it. That's the least painful method we've been able to come up with.

...that's why we NEVER use embedded code in HTML. Always use a seperate procedure and reference it.

dropdown_cars_in_country.fex

TABLE FILE CAR
SUM COMPUTE DISP/A80 = 'Car: ' | CAR;
BY CAR
WHERE COUNTRY EQ '&INPUT_COUNTRY'
ON TABLE PCHOLD FORMAT XML
END

Greets,
Dave

All I wanted to do was add a static parameter to five parameter screens.

Since the reports have evolved since they were first written, when I reassign the fex, a bunch of other variables appear. So I set up a dummy fex, with only the parameters I want controls for and point to that.

I get the new parameter added and give it a value.

After saving, the value disappeared and was replaced by a semi-colon. I had to tediously reopen the five parameter screens and used the GUI to replace the semi-colon with the text I originally entered.

On a couple of screens, the generated code for the new parameter was shoved in between code for an existing parameter, thus rendering them both useless. I had to recreate these screens from scratch.

I just never have understood why I cannot add a control and then connect it to a new parameter and have the parameter passed to the fex WITHOUT having to reassign the run button to the same fex.

If the parameter is added to a report or chart that exists on the page, you right-click that report or chart and select “Refresh parameters”. This will cause the “New Parameters” dialog to display for create a control for the new parameters. In the Grouping options area, you can select an existing form or panel to add the control into if desired. If you are adding a parameter to a page that has no report or chart associated, you draw the control, then on the Parameters tab, you create the new parameter and bind the two. Then you move the control into a form or panel if needed. To get it on several pages, you open them all and copy/paste.

@Kathyrn,

I find that "refresh parameters" doesn't work. Perhaps because I can not "Right-click" the report or chart. It's being opened in a new window.
Only opening the hyperlink properties and changing the settings work ( just clicking the "same, parent, new window"-dropdown ( even without actually changing something ) will "refresh" the parameters.

@Francis,

I understand. But isn't it odd that the reassigned fex has a bunch of variables that appear?
You have a fex being called by an HTML but not all variables are supplied by the HTML? Once again... isn't that odd?
I understand that you might have internal variables that do not need to be supplied by the HTML. If you initialize them ( -SET &PARAM1 = ''; ) they will not be shown in the HTML add paramater screen.

My two cents:
I'm think you issue with the HTML composer is just a symptom of an underlying problem/situation.


G'luck

Yes, refresh parameters only works when there is am iframe containing the report.

Tying the HTML page to the report is the most annoying thing about HTML Composer. Why can't I control what happens between the HTML page and the report?

When I reassign the fex, why, sometimes, does the GUI add an outlined box and push the Run button down by a couple of inches from where it was?

A couple of inches... ...lucky you.

Sometimes I need the "thumbnail" view to find out where an input ( or run button ) went. Positions in excess of 4000px+ have happend.

'fexi'
i love that!
frankie i do exactly what you do
and i do it with a 'container' fex.
so the html always calls the same fexname.
the container is:

-* this is budget_container
-DEFAULT &parm1 = 'lucy';
-DEFAULT &parm2='ethel';
-INCLUDE someapp/budget_report.fex

the defaulted 2 parms are the ONLY ones i want to appear in the launch page
When i want to rebuild, i comment out the -INCLUDE
so the launch page never knows it exists.
then add a new parm

-* this is budget_container
-DEFAULT &parm1 = 'lucy';
-DEFAULT &parm2 = 'ethel';
-DEFAULT &parm3 = 'fred';
-*INCLUDE someapp/budget_report.fex

This container concept is especially handy when backend fexes fexi are launched from other portals, over which you have zero control.
So the other portal launchs 'budget_container.fex'
and you're then free to do whatever the sam hill you want, without having to find bribe someone on the portal team to change its link.

This message has been edited. Last edited by: susannah,

susannah, I love this revolutionary idea! Fantastic! Thanks so much!

Dave, that is the only reason I use the thumbnail view, to find a missing control. The 4000px placement also happens when you do something reckless like cut-n-paste.

Dave,

If there is no iframe as in your case, you do need to reattach the FEX in the Hyperlink Properties dialog as you have found. That causes a reparse of it to find new parameters.

David,

I know, as I already mentioned...

quote:

Only opening the hyperlink properties and changing the settings work ( just clicking the "same, parent, new window"-dropdown ( even without actually changing something ) will "refresh" the parameters.

[QUOTE]Originally posted by susannah:
the defaulted 2 parms are the ONLY ones i want to appear in the launch page
When i want to rebuild, i comment out the -INCLUDE
so the launch page never knows it exists.
then add a new parm
[QUOTE]

Where were you the other day? I had a program that I wanted to create a new HTML with and all I wanted was 2 out of the 50+ parameters created. The program had several -INCLUDES and everytime I re-linked the report, the calendar control got "bunky" on me and would not display the calendar icon and gave me an error. I ended up working it another way, but I don't see why this way wouldn't have worked.

Out of curiosity... ...it might kill me.

Why do you have a fex with 50+ parameters and only 2 are real user entered parameters?

What are those other 48?

I use plenty of (internal) parameters that do not need user input. But I either use -SET &REPORT_TITLE = ''; or -DEFAULTH &COMPANY_ID = 0; to prevent it from prompting.

We use a lot of common modules for common routines. We have a list of &VAR's that are being passed across the portal to allow you to drill on hierarchy level, return to or do what ever you need to do to get from report to report.

I was asked to take an existing report out of our main portal and make a new portal with it only. This repport like all other reports calls common routines that go out and get dates, store levels, report layout, etc basically a whole bunch of stuff.

I ended up stripping a lot of uncessary items from it and included some of the common items into the report.

When they introduced HTML Composer, I feel a bad decision was made - suddenly the -DEFAULT parameters took on a new meaning. The decision should have been that the -DEFAULTH parameters are the ones that get attached to controls. I never remember to use -DEFAULTH for parameters that should be ignored by HTML Composer.

Meanwhile, it's all very nice to remind us how to refresh parameters, but how on earth do you prevent the resetting of certain control attributes? The simple procedure that I needed to perform and that prompted my comments also removed the static values I had set up for &WFFMT...

Copy/Paste was mentioned here.

I just tried copy/paste of a listbox populated by a dynamic external procedure. The pasted control was placed in position 4000,4000 and is populated by static values. As far as I can tell, you cannot use copy/paste reliably in HTML Composer.