Dominik Gruntz wrote:
> Let me try to explain:
Your explanations are very good. Should be part of the manual.
>
>
> In the Form User Manual I could read:
> > The difference between auxiliary and tool dialog boxes is that auxiliary
> > dialog boxes are self-contained, e.g. dialog boxes to set up configuration
> > parameters or data entry masks. Tool dialog boxes on the other hand operate
> > on windows below them, e.g. the Find & Replace dialog box operates on the
> > text beneath the dialog box.
The word "beneath" is sort of confusing. This is not exactly how tool dialog
behaves, because I can literally sweep it aside.
May I suggest that the word "aux" is confusing as well? Does it mean "auxillary",
which means "helping, aiding", but also "additional, supplementary" (according
to Webster). It is not clear why these aux dialogs, which are quite fundamental,
are "additional". The name is rather confusing.
Another observation: the Tool and Aux dialogs introduce a hidden mode, since
their appearance is the same, though functionality is fundamentally different
(as shown by my buttons, which work in one mode but not the other).
This is quite confusing in a "modeless" environment.
> If you ask for the focus view in a command called from within a dialog,
> the result depends on whether the dialog was opened as tool dialog or
> as aux dialog. In the latter case, the dialog itself has the focus.
> Containers.Focus returns the dialog itself and you can start
> iterating over its content. Controllers.FocusView returns the view
> which currently has the focus, and this is the push button currently
> being pressed!
This means I can use view.context to get the enclosing view? Oh, no,context is
something different. I thought there was a way to get at the
enclosing container, what would solve the problem.
> Note, that the latter can also be accessed via Controls.par.
I did not know. Another jewel that got buried in the docu.That's important piece
of the puzzle. If I can jump from
that button to an enclosing Form, I would know the starting point
for the iteration.
But there is a better solution below.....
> In case of a tool dialog, the focus is the focus of the window below the
> tool dialog, e.g. a text (as for the Search&Replace dialog) or another
> form (as for the property editor dialog).
>
> Thus, if you want to search for a view in a dialog then
> 1) open the dialog as aux dialog
> 2) execute c := Containers.Focus() to access the form controller
> 3) look for the view you are searching for
> c.GetFirstView(Controllers.any, v);
> WHILE (v # NIL) & (v is not what you are looking for) DO
> c.GetNextView(Controllers.any, v)
> END
>
Great. That is what I will do.
It just occured to me that your "(v is not what you are looking for)"
in System-3 means a Gadget with a given name, that can be set
interactively. In your Forms however names do not exist.
The Properties item is greyed when I am launching Inspector
on my GrView. Thus, if I happen to have TWO GrViews in the same
form (why not?), I will have to introduce additional data field "name"
in order to differentiate. This si however application-specific,
and not supported in general by the environment.
Even though I can do this and thus solve my particular problem,
how about solving that in general in the next BB release?
Can you introduce Object names and a standard procedure
Containers.GiveMeThatDamnName ("MyName") ?
That would make the whole process more interactive, and less
application-specific.
And maybe make Tool dialogs and Aux dialogs different color,
so that the hidden mode is less hidden.
Just a suggestion.
Thank you again for explanations.
Wojtek
Received on Sun Feb 21 1999 - 04:41:04 UTC