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