[adm2-dev] Implementing non-blank fields - Forum - OpenEdge Development - Progress Community

[adm2-dev] Implementing non-blank fields

 Forum

[adm2-dev] Implementing non-blank fields

  • The main issue you will have is getting the correct handle to the toolbar. When an

    application is launched, to the level of a viewer, there are many instances of the

    toolbar running. From my last count, at least four. One for the Main Menu, one for

    the Browser, one for the Folder Window and one for the Viewer. From those you will

    need to determine which is the one you want, and this is of course if you do not

    have any other applications (browsers/viewers) running at the same time. The only

    method I know at the moment is to traverse the widget tree from the last and going

    up, and determining from some type of individulatiy of the object (we used the

    object name that is in the repository) and getting the handle to that toolbar.

    When you have the handle to the toolbar, run two functions in the toolbar instance.

    def var hToolbar as widget-handle no-undo.

    def var cButtons as char init 'AstraAdd,AstraCopy,AstraDelete':U no-undo.

    /* Or whichever buttons you want to disable */

    dynamic-function ('setDisabledActions':U in hToolbar, cButtons).

    dynamic-function ('disableActions':U in hToolbar, cButtons).

    Happy hunting

    Robert Langer

    Wim van der Ham wrote:

    At 08.26 12/11/2001 +1100, Robert Langer wrote:

    >Hi Wim,

    >

    >I think you are trying to make the process more complex than you need to.

    >

    I'm trying to make it USER FRIENDLY and I agree that does put more work

    (complexity?) on the programmer...

    >

    >There are some better alternatives I can think of involving procedure

    >over-rides. They are:

    >

    >1.updateRecord. Place your validation code before the RUN SUPER, to

    >validate to

    >your requirements.

    >

    >2. (FieldName)Validation. This a part of data.p in submitValidation.

    >

    >3. The SDO validation entry points/hooks of, writePreTransValidate,

    >writeBeginTransValidate, writeEndTransValidate, and writePostTransValidate, if

    >there are database dependant validations.

    >

    All given solutions will signal the problem TOO LATE. Why allow the user to

    press a button (like the Save button in this situation) if the only result

    is an ERROR message. I want to help the users, not make them feel stupid.

    >

    >In either case, you should have a read of each of the requirements of the

    >procedures, as they each have their own implications on use. Additionally you

    >are not messing around with trying to disable/enable the buttons. The usage

    >will fall into the natural flow of the ADM.

    >

    Some of the validations you propose are done on the server, which is even

    worse because the validation I'm trying to implement can be done entirely

    on the client side.

    >

    >Hope this helps

    >

    I'm afraid not much but thanks anyway.

    >

    Wim