How frustrating.
An experienced user/developer calls to see if I've had any problems getting "older" reports to open in the recently upgraded 7.1.4. Report Assistant. He shows me his report and sure enough, when I try to OPEN it, I get the report code text box displayed with
line 1: Encountered "* .01 );

The report has a defined field that looks like this:
ExtStdCost/D12.2 = QTY * (STD_COST * .01);

WebFOCUS, all of a sudden, doesn't understand what * .01 is supposed to mean.

Disbelieving that this was possible, I recreated the report in Report Assistant. When I tried to SAVE the report, I get an ERROR PARSING PROCEDURE message that points to the defined calculation containing the * .01.

The solution? Add a zero before the decimal point. WebFOCUS 7.1.4 seems to understand the calculation
ExtStdCost/D12.2 = QTY * (STD_COST * 0.01);

Unbelievable. Like we don't have enough to do. Now we have to re-code all of our define calculations.

I found Mickys POLL below on WHAT SHOULD BE THE PRIORITY. I really think the IBI GUI developers should get serious about this. How can something as simple as not having a zero before a decimal point in a calculation break the GUI? And they can't understand why people don't want to use the GUI and are more comfortable coding?

Sorry for the venting, but sometimes it's just a little hard to take.

Deb

Hi Deb,

To get issues fixed, please contact Information Builders' Customer Support Service and submit a new case. This way we can send it to programming/product management to work on the issues. The phone number 1-800-736-6130, or please access online InfoResponse.

Cheers,

Kerry

hi debbiej,
speaking of whacky...
76 on the as400 does the following:
NEWFIELD/A6=EDIT(OLDFIELD,'999999');
doesn't work
NEWFIELD/A6=EDIT(OLDFIELD,'999999$$$$');
does work
go figure.
i agree.

quote:

NEWFIELD/A6=EDIT(OLDFIELD,'999999');
doesn't work
NEWFIELD/A6=EDIT(OLDFIELD,'999999$$$$');
does work

Susannah, and you still want to use Lazy If's? They're gonna disappear one day soon!

Cheers,

Interesting...I was taught to use it the way it is now working 7.6...but other developers said...no you can do it the first way Susannah listed...so I started doing that. Guess it will break when we upgrade to 7.6

this particular edit can't break
if it does, then you can't edit an incoming &var , for ex, when you have no clue how long it is, and even knowing just isn't relevant.
this particular edit just strips off the first n characters of some string, regardless of the length of the string.
If they decide to break this, i quit.
and its only on Os400 for sure that this breaks.
and the bgh has agreed its a bug.
Can someone out there test it in 76 on a win plat?

quote:
NEWFIELD/A6=EDIT(OLDFIELD,'999999');
doesn't work
NEWFIELD/A6=EDIT(OLDFIELD,'999999$$$$');
does work

But, the question remains, does

 NEWFIELD/A6=EDIT(OLDFIELD,'999999$*'); 

still work?

Kevin

Unfortunately, * is not a valid mask character in EDIT.

quote:

EDIT works by comparing the characters in a mask to the characters in a source field. When it encounters a nine in the mask, EDIT copies the corresponding character from the source field to the new field. When it encounters a dollar sign in the mask, EDIT ignores the corresponding character in the source field. When it encounters any other character in the mask, EDIT copies that character to the corresponding position in the new field. EDIT does not require an outfield argument because the result is obviously alphanumeric and its size is determined from the mask value.

But, in v5.3.2, you can have more $ than the length of the input column. For example, this works:

TABLE FILE CAR
PRINT
COUNTRY
COMPUTE COUNTRY1/A1 = EDIT(COUNTRY,'9');
COMPUTE COUNTRY2/A2 = EDIT(COUNTRY,'99$');
COMPUTE COUNTRY2/A10 = EDIT(COUNTRY,'999999999$$$$$$$$$$$$$$$$$$$$');
END

Susannah, perhaps you could use a whole lotta $ in the EDIT statement when you don't know the length of the input column - just a thought.

dude..not gonna happen

The following would work for Dialogue Manager variables when the length is unknown:

-SET &OLDFIELD='This is the old field';
-SET &NEWFIELD=SUBSTR(&OLDFIELD.LENGTH,&OLDFIELD,1,10,10,'A&OLDFIELD.LENGTH');
-TYPE &OLDFIELD
-TYPE &NEWFIELD

This define will fail with an error:
NEWFIELD/A6=EDIT(OLDFIELD,'999999$*');
because the RESULT of the EDIT is 7 characters, but the target is A6.
Why A7 -- since * is neither a 9 or a $, it is considered a literal that is copied to the output.
Susan, I tested the following on windows and it works fine.
DEFINE FILE CAR
X1/A6=EDIT(COUNTRY,'999999');
X2/A6=EDIT(COUNTRY,'999999$$$$');
X3/A7=EDIT(COUNTRY,'999999$*');
END

Shouldn't the code become MORE intuitive and LESS redundant in higher releases?

Isn't it so much easier, nicer and understandable to code Susannah's EDIT function than this SUBSTR function?

I now have to go get my FUNCTIONS manual to see what the heck all those SUBSTR parameters even are ! ! Thanks Mickey . At least I will have re-learned something today ! !

And Francis, what would we do in the future release that makes entering more $$$$$$$ than the actual field length in the EDIT function an error? We're no better off, we just postponed the agony.

I still believe that IBI should STABILIZE a release (e.g, make everything work correctly) and PUBLISH the requirements (e.g., fully document the command structure) so we will ALL know what the rules are going forward. Then, any "modification" of those requirements in future releases would have to be fully documented and, hopefully, forward-compatible (e.g., if it worked before, it should continue to work, regardless of the modification).

I'm just not sure how we can continue developing our most-excellent applications not knowing what will cease to function (or require major rework) with the next upgrade because either we or they didn't follow someone's interpretation of the "rules".

Like Francis warns, the lazy ifs may disappear next. If they do, I will be re-writing A LOT of fexes . . . If it's not the lazy ifs, it could be anything else . . .

Kudos to all. Thanks for another entertaining and thought-provoking thread.

Deb

quote:

But, the question remains, does
NEWFIELD/A6=EDIT(OLDFIELD,'999999$*');
still work?

The '$*' isn't a valid masking combination in the EDIT/Mask function but it is a valid wildcard representation in a selection statement.