:FIND-FIRST method and the message(s) displayed - Forum - OpenEdge Development - Progress Community

:FIND-FIRST method and the message(s) displayed

 Forum

:FIND-FIRST method and the message(s) displayed

  • Hi,

    the last part of the documentation for the :FIND-FIRST() method of a buffer handle says:

    If FIND-FIRST succeeds, it returns TRUE, otherwise it returns FALSE.

    If FIND-FIRST fails, it does not raise an error but displays a message. You can suppress this message by using NO-ERROR on the statement containing the method.

    Am I the only one who get totally mad about these messages? I want to be able to use this directly in an IF statement like:

    IF hBuffer:FIND-FIRST() THEN DO:

    ELSE DO:

    END.

    I can't use no error here - so I always need to create a logical variable and use that as that's the only chance to suppress the error message. As the result of the message (yes/no) already tell if I can get the record, why isn't it possible to use it directly in an IF statement?

    Mike

  • Setting aside my feeling about FIND-FIRST() in particular...

    No, you're not alone. I agree that it should not behave that way.

    On a whim I tried session:suppress-warnings. No impact. (Not that I was surprised.)

    --
    Tom Bascom
    tom@wss.com

  • Too bad the FIND-FAILED event can't be used in a normal trigger like so:

    on "FIND-FAILED" of buffer customer do:

    return no-apply.

    end.

    --
    Tom Bascom
    tom@wss.com

  • Am I the

    only one who get totally mad about these messages? I

    want to be able to use this directly in an IF

    statement like: IF hBuffer:FIND-FIRST()

    THEN DO: ELSE DO: END.

    you mean you want hBuffer:CAN-FIND()...

    I can't use

    no error here - so I always need to create a

    logical variable and use that as that's the only

    chance to suppress the error message. As the result

    of the message (yes/no) already tell if I can get the

    record, why isn't it possible to use it directly in

    an IF statement?

    Mike

    Then do it this way:

    hBuffer:FIND-FIRST() NO-ERROR.

    IF hbuffer:AVAILABLE THEN

    The current structure of dynamic FF is exactly like how static FINDs work, so Progress got this right.

  • 1. Static FINDs aren't coded as functions either.

    2. If FF doesn't raise an error condition in the current block, then maybe that was an oversight on PSC's part. I wouldn't take it as an indicator they made a mistake by not providing a way to no set ERROR-STATUS on a failed FIND.

    (I can't quote because of Jive's buggy behavior with FF mucks up the resulting post - sorry).

  • It's documented not to raise an error condition:

    >> If FIND-FIRST fails, it does not raise an error but displays a message.

  • I'll grant that they didn't break anything that previously worked and that the FF() method is consistent with past programming practice.

    But it's a new feature and thus needs to work in new ways. One obvious way to use it is as Mike is attempting to use it. Any method -- be it FF() or XYZZY() should work inside an expression. That's kind of the point of returning a value. And it does "work", it just has this unfortunate side-effect

    Throwing an error message to the UI is, IMHO, antithetical to modern programming practice. It was a nice convenient thing to do in the 80s when we didn't know any better just as UPDATE EDITING was.

    SESSION:SUPPRESS-NAGGING might be the answer

    --
    Tom Bascom
    tom@wss.com

  • Any method -- be it FF() or XYZZY() should work inside an expression.

    There's some of the OO stuff that violates that rule, as does UDF's inside of WHERE clauses.

    It's too bad

    handle:FF(expression NO-ERROR)

    isn't supported, as that would be a viable workaround.

  • Tim, I'd like to see it like that.

    Or hBuffer:FIND-FIRST(expression, NO-ERROR).

    Mike

  • Anybody from PSC listening, who may explain why these messages have been implemented?

  • Any method -- be it FF() or XYZZY() should work

    inside an expression.

    There's some of the OO stuff that violates that rule,

    I guess that I believe you but I'm at a loss to understand why that would be anything but a bug.

    as do UDF's inside of WHERE clauses.

    I used a weasel word -- "method". And I'm not sure that a WHERE clause ought to be thought of as an "expression" in this context.

    I do like the thought of simply permitting "no-error" in the method call. It was the 2nd thing that I tried but, of course, it didn't actually work.

    --
    Tom Bascom
    tom@wss.com

  • I guess that I believe you but I'm at a loss to understand why that would be anything but a bug.

    Consider

    class-variable = NEW class-name(signature).

    While "NEW" is written similar to BUFFER table-name:HANDLE, it doesn't act like that, so that's why I suppose it's not supposed to be used where a value is required.

  • Well, this gets a bit off topic, but the NEW phrase of the assignment (=) statement is not just there to qualify the type of a static widget/object like the BUFFER or FRAME option.

    For me that's a different language element than an expression.

    Also if the NEW fails, it raises an error condition. It does not display silly messages without raising an error condition.