Hello everyone,

today I was again surprised by an awkwardly strange behaviour of one WebFOCUS function, yet not suprised to much as I have experienced the same awkwardness with other features and functions in this so-called powerful tool.

My today's favorite is STRREP - which is meant to replace all string occurences (param #4) in an input string (param #2).
Usually this works as expected - BUT:

Have you tried using this one with an input string shorter than the search string. Well you might say: what's the point in doing so - simple answer: when using dynamic strings you cannot a-priori tell what will be in there.
(I stumbled accross this problem btw. when trying to use STRREP on multi-selection strings from an HTML page - replacing the ' OR ' with a comma+space - for input strings with a length < 6 this won't work)

If you now try the following:

 
-SET &MYSMURF = 'PAPA';
-SET &SMURF = STRREP(&MYSMURF.LENGTH, &MYSMURF.QUOTEDSTRING, 6, 'CLUMSY', 5, 'HEFTY', 20, 'A20');
-TYPE &SMURF

You won't get your PAPA back - instead an empty string is returned. Even worse: in some versions of WF (I "successfully" tried 7.7.01)using the a.m. construction in a DEFINE FUNCTION part leads to an agent crash. At least this crash seems to have been fixed in 7.7.03

In every other computer language where you can script or program with strings a similar function would just return the in-string, as the string-to-replace can never be found.
But ... "Hocus-Pocus-Focus" ... WF doesn't.

So - again a check + exception handling is needed to test the dynamic string length and avoid performing a STRREP if instr.length < repstr.length. Pain in the ...

Cheers, Linne

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

Syntax of the STRREP procedure:
STRREP (inlength, instring, searchlength, searchstring, replength, repstring, outlength, outstring)
The manual states that 'searchlength' must be less than or equal to 'inlength' (searchlength: Is the number of characters in the (shorter length) string to be replaced). In your case it is not.
If you expand the string to be searched to at least 6 charcaters, you do get the original string in case the search string can't be found.
It is not documented however that it should return an empty string when something is not correct. You might want to bring that to the attention of IB tech support by opening a case.

quote:

Hocus-Pocus-Focus

Great Song!

Hocus Pocus by Focus, sad to say that, like Waz, I remember it well in fact it's in my head now and I can't get it out

T

My job is done....

Hi everyone,

@GamP

quote:

The manual states that 'searchlength' must be less than or equal to 'inlength'

I do not quite agree - that the restriction is stated there, for me it is only "hinted".
IMHO: A standard documentation should state: "The search length must be less than the in-string length" or similar.

Well, I must admit I have read this passage of "shorter length" after I had my superb experience with STRREP + multiple agent crashes. One might assume that this "shorter length" refers to the instr - nevertheless this is still at least strange.
But of course you are right, that the result actual result returned is not at all documented. I will consider opening a case here.

Nevertheless I am happy to have given you that catchy tune

Cheers, Linne

The song was not coming to me..so I had to go find it. Ever wonder what the Lyrics looked like in print?



Yodeadodoyodeadodoyodeadodoyodeadodo. yodeadodoyodeadodoyo-bab-baaaaa. Ahhhhhh-aaahhhh-aaaaaa-aaaaAAA

.... and I just walked over and put it on my turntable. Tjis van Leer on the flute.

I've always been a little perplexed about why I need to tell WF how long strings are in the first place. It can't figure out the length of 'abc' on its own?

J.

The issue with supplying string lengths was explained a long time ago, can't remember is it was in this forum or verbally to me.

But there was good reason for it.

As for the STRREP function, I guess it would be illogical to search for a string that is larges than the string you are searching through.

But it would have been nice to have the function return the original string in this case.

quote:

and I just walked over and put it on my turntable

You have a turntable, how retro....

quote:

supplying string lengths

The FUSELIB routines were originally either written in FORTRAN, or written to be callable from FORTRAN.

It's been a while (), but as I recall the FORTRAN function-call protocol just passed the address of the variable (or of a copy of its value), without supplying any info on the "type" of the argument. For that matter, there was no native Character data type -- we would sneak them into arrays of one of the numeric types.

And, since they were "contributed" to the library, without "editing" or peer review, you got a hodgepodge of length-then-value and value-ten-length designs for the parameter list. (Even the RJUST, LJUST, CENTER trio are not consistent.)

quote:

passed the address of the variable

That fired some old neurons.

Thats what I told/read.

Yep, that's it.
As I remember it, it is called parameter passing by reference. You only pass the memory address of the first byte of the parameter, which is why you really do need the length to be specified also and why you can't figure out what size string you have been passed.

quote:

... can't figure out what size string you have been passed.

That's the reason (aside from the cultural reference to FORTRAN I/O statements) for the parens in arg 2 of

FTOA(number, '(format)', outfield)

One mystery:

CHGDAT('in_display_options','out_display_options',date_string,outfield)

-- the output option string can be 1 to 5 characters long (e.g., 'Y' and 'YYMDX'). If shorter than 4, the value is blank-padded to a full word. But if it's 4 -- e.g., 'YYMD' -- what assures that the next word in memory does not start with T (or X), which would (mis)lead the routine to convert the month to alpha?

-Jack

In this special case, literal strings are being passed (the values are within quotes). In that case the parameters are not passed by reference, but by value. The receiving function will have to cater for the maximum number of characters passed.
What makes you state that if it is shorter than 5, it gets padded to a full-word?

quote:

What makes you state that if it is shorter than 5, it gets padded to a full-word?

That's the way it is (or was) in FORTRAN, in the 360 spawning ground of FOCUS -- all allocated variables and literals would start on whole-word boundaries, so the remainder of the last word of a character literal (if length is not a multiple of 4), would be padded with blanks.

It may be platform-dependent.