I'm not sure if this question has been answered satisfactorily or the problem has been corrected in a hot fix, but why, when rebinding a report to a parameter screen, does HTML Composer wipe out painstakingly entered static values in a previously existing control?

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

Are those static variables, the ones being wiped out, -DEFAULT'd in the fex being executed from the "Run" button?

Yes, they're being defaulted. I thought that this is standard practice - default the parameters that are used in the report. Don't tell me I have to remove the default when rebinding the fex - these manipulations seem ridiculous.

To my knowledge you don't need to default the parameters. I only do this for testing so the auto prompt is filled in and I don't have to.

Yep, as far as I am concerned, the -DEFAULTing is a standard practice (and imho, it should be for everyone). However, as MAdams1 said, They can be removed. I do leave them in in case I need to refresh anything fomr the HTML GUI later on or want to run the fex directly for futuer analysis... I'd never ask anyone "to remove the default when rebinding the fex".

BTW, off topic, I like this quote:

quote:

"An old coder never leaves a mess"

... You never know when you're the one who needs to come back to it...

Michelle,

Don't we all usually default the parameters?

As far as I can tell, If you have a control that does not require selection and that does not have an ALL option, then that parameter is not passed to the fex, so you would need a -DEFAULT...

quote:

default the parameters that are used in the report

Hi Francis,

No, I very seldom default parameters. I haven't found that defaulting or not defaulting makes a difference in the launch page. I only use it for the auto prompting in testing. Can you give me an example of a parameter in a fex that you wouldn't be passing from a control? I can only think of ones that I would use -SET for in the fex that are not required on the html page and would not need a control. Maybe I'm missing something here

Michelle

quote:

Don't we all usually default the parameters?

IMHO: That's the best way to set up a "Launch Page" for a fex...

If you have a control that does not require selection and that does not have an ALL option, then that parameter is not passed to the fex and the report would fail without a -DEFAULT.

Another reason to have defaults is to be able to run the fex directly, for development purposes, without having to run the parameter screen first.

quote:

If you have a control that does not require selection and that does not have an ALL option, then that parameter is not passed to the fex and the report would fail without a -DEFAULT

I may have been thinking about this in the wrong way. I
have been trying to figure out why you would have such a control. But I guess if you want to have the report run even if the user doesn't make a selection and there's no ALL option, then yes you would have to have a -DEFAULT in the fex. I wouldn't do this because I guess I want the user to choose an option from the control. And if it is not a required selection, I add the ALL option in the control. Which is like setting a default just in the page not the fex. So, IMHO I think it's a preference issue. If you do it your way, is the user really getting the report they want when the DEFAULT value is being used? In the event I don't use an ALL option, I have a norecords fex that will run on error that notifies the user to check the parameters selected, that way he/she can see that a selection wasn't made, correct it and get the report they want. I love WebFOCUS for this reason, many ways to achieve the same result

What if you had a filter that was not mandatory? In some design situations, an "All" option is not necessary...

Meanwhile, I just found that that -DEFAULT also wipes out the settings for a control that is populated by a dynamic external procedure. I just don't get what kind of usability study suggested that a simple -DEFAULT in an external program would supersede settings made by the GUI HTML Composer tool.

quote:

What if you had a filter that was not mandatory?

So, if the filter is not mandatory then the report would run with or without a -DEFAULT right?

The filter is not mandatory as a parameter, but you would need the WHERE statement in the code. So I would have a -DEFAULT of _FOCNULL and the WHERE clause. So whether or not the parameter is passed the fex will work with the WHERE statement.

quote:

So I would have a -DEFAULT of _FOCNULL

This is the same as selecting the 'No Selection' option in the GUI - Properties and Settings for the control. 6 to 1, 1/2 dozen the other, both are basically setting a default value.

I don't think the "No Selection" option was available in v7.6 when I got my feet wet (got drowned?).

In any case, this is only one of many issues I have.

Today I discovered that on a parameter screen I built using the GUI - no -HTMLFORM, no !IBI, the Run button wouldn't do anything, even though it looked like it was bound to a fex. And for some reason all the "Send Display Value" parameters were named "_TEXT" instead of "PARM_NAME_TEXT". I had to manually correct them in the code.

How stupid must I be to get myself into this hot water?

Francis, you are far from stupid!! Although I haven't had the Send Display Value issue, I have had the run button do nothing before. I think I had to create the hyperlink to it again and make sure the button was type = submit. So, how did you fix the run button issue?

I successfully managed to use the GUI to delete the hyperlink and add it again, carefully...

It can sometimes be challenging to work with the HTML Composer. Sounds like it keeps you on your toes. Glad you had success with the GUI. I'm anxious to see what Version 8 brings our way.

I'm anxious to have hotfix 7 applied on our client and on Dev Studio to eliminate the long-annoying "rtfilename" issue.

This just makes me want to cry. I thought I fixed it. Then I find the parameters and controls are somehow unbound. So I bind them. This makes all the dynamic external fex references disappear.

I spend so much time running in circles, I just don't know how it's more productive to use HTML Composer than to hand code.

I'm with you today. I could just scream right now. I'm working on a page that has a RIA theme (that I hate, but it isn't my design-I just have to fix it) I spent a few hours adding several hidden boxes and check boxes and all the code to get them to do what I want, I saved it, took a break, came back and it was all gone!!!! It didn't even save in the version control we have. I have no idea what happened to it. What a waste of time. I have to think it is the RIA theme, I don't normally have this trouble in HTML Composer. It was a smart move for IB to deprecate the RIA themes.

I've applied the V7703 Hotfix 7 on Dev Studio (not yet on the client) and it's made all the difference for me, after struggling to make even basic things work HTML-wise after the upgrade from 7702. I can actually add frames and graphics and links to other pages without worrying about file not found issues. I still can't do this working directly on the server ( same old errors) but I'm looking forward to getting Hotfix 7 installed there.