I am passing a character value to a HTML page. All of the fex's on the page run correctly, but the value in the object that displays the value passed has "true" added to the end of the value. For example if the value passed was B1111. It would display B1111true. I even tried to do a trim and that does not work. I believe it is an unreadable character stuck at the end of the value. Has anyone seen this before.

This message has been edited. Last edited by: Jay Potter,

How are you "passing a character value to a HTML page"?

I have a fex create the parameter and then call the html page or via a menu option on a report, I pass the value via the fex to the html page.

Jay, I'm not sure I understand. A fex creates a parameter. How is the HTML page called? Via -HTMLFORM html_page.htm? Some other manner?

-HTMLFORM ItemScreen.HTM

And how is the variable value used in this HTML page?

This is difficult to debug without seeing any code.

quote:

I am passing a character value to a HTML page. All of the fex's on the page run correctly, but the value in the object that displays the value passed has "true" added to the end of the value. For example if the value passed was B1111. It would display B1111true. I even tried to do a trim and that does not work. I believe it is an unreadable character stuck at the end of the value. Has anyone seen this before.

From this description we can't tell how this variable value is being used in the HTML page. Are you using

!IBI.AMP.varname;

What kind of control? etc.

Yes I use the !IBI.AMP.varname; format for the value of a text object.

I assume this is an HTML Composer GUI designed HTML page? If so, the documentation states that !IBI.AMP and !IBI.FIL and -HTMLFORM are not supported, despite the fact that almost everyone is doing it. How are you placing the !IBI.AMP? Do you have quotes around the variable? it should look something like this:

<INPUT style="Z-INDEX: 122; POSITION: absolute; OVERFLOW-Y: visible; WIDTH: 135px; HEIGHT: 22px; OVERFLOW: visible; TOP: 30px; LEFT: 5px"
id=edit1 tabIndex=914 value=!IBI.AMP.P_BM_REF; hspace=0 size=8 defaultselection="1" persistentuniqueid="compUid_44"
defaultlocation="0,0,22,147" boundtovariable="1" requiredfield="1" name="edit1"></SPAN> 

The problem with this:

If you're using the GUI and typing !IBI.AMP.varname; into the Value attribute of the control - the generated HTML does not include any quotes around the value, so if there's a blank in the middle of the value, the control could break. This may not be occurring in your case since the value is B1111. Have you viewed the source and looked at the HTML line that contains B1111?

Meanwhile, when there is a blank in the middle of the value, if you add the quotes to the control Value, it will not break, so the Value would look like: "!IBI.AMP.varname;" - these quotes get sent to the HTML.

The approved method of using the GUI: Create the HTML page using the GUI; Control values that must be retrieved from data should come from embedded or external procedures; Run the HTML page rather than a fex that calls the HTML page...

I have seen "funnies" like this in the past in these scenarios:
- If e.g. -READ is used to populate the amper-variable, and the length that specified on the -READ is larger than the value/field, it reads the characters of the next field
- If -READ reads data created by ON TABLE HOLD (instead of ON TABLE SAVE) and it was not formatted as FORMAT ALPHA, then there may be binary data
- The data being read actually has a "funny" character captured in it e.g. tab or line break
- The HTML code in the -HTMLFORM is translated to something "invalid" after the !IBI.AMP.varname; references are resolved (right-click / view source when viewing the HTML page and check for missing tags, quotes etc.

Here is what my code looks like.



I tried having the menu option call the html page directly. It did the same thing.

I don't see any code. Please put your code between

[code]

code goes here

[/code]

Twannette, that is expected behavior.
Remember, &vars are not sitting in a database in a reserved space; They are in memory, taking up only how much space they need, and whatever is sitting next to them in memory can/will be rubbish to your app.
Commands like TRUNCATE and ARLGEN and .LENGTH become very useful for managing these memory variables

Hi Susannah,
Thanks. Yes, I know that.
I was hoping that one of the scenarios that I listed may actually assist Jay in debugging his problem.

Jay, I think you'll need to post the code that you're using to populate the variable as well as the HTML - as per Francis's instructions. We'll need to "see" what you're doing.

This case says "CLOSED". What is the solution for this issue?

Is it a expected behaviour in devstudio html page?

Yes it was a dev studio html page.

The expert room at the conference could not figure it out. I will be rebuilding the html page and testing it as I go to see if the behavoir happens again and at what point.

Just out of curiosity, if you use -READFILE instead of READ, do you get the same results? We tend to use -READFILE since you don't have to specify variable formats, the variables are called the same as the columns, you don't have to hold the tables as alpha, etc.

Hi everybody,

I believe I have seen a similar behaviour on one or several of my html pages in the past with 7.7.03. I believe it happened when WF Javascript got "confused" whenever parameters for a HTML page were submitted via GET or POST + the same varnames where also contained in the resp. WF cookie.
I am not sure if this is the same problem that produced Jays bug. I do not remember exactly where the problem occured in JS but I think it was in ibirls3.js somewhere in getAmperValue where the value for an & was constructed.

Workaround: Rewrite IBIs whole JS

Please... is there any clue of what you have done in that js?

Is there any other way to solve it?

I?ve got this issue since the very moment I updated my versión of DS, Client and Reporting Server. I cant believe this issue can´t be fixed by IBI.

No this hasn't been fixed. They could even figure it out what is causing it. Fortunately it does not come up in often. If you find out what the issue is, I would be happy to find out. Did you just change to version 8? And are you using 8.0.8 or 8.1.0?