At 06:24 PM 15/7/99 +0200, Dominik Gruntz wrote:
>> Hi Folks,
>>
>> I'm wondering if someone can help me here...
>>
>> I have a view (PrivGraph.View) that displays a directed graph. The display
>> is affected by a number of different parameters, so I defined a
>> Properties.Property to represent them:
>>
>> Prop* = POINTER TO PropDesc;
>> PropDesc* = RECORD (Properties.Property)
>> options* : SET;
>> xAngle*, yAngle* : REAL;
>> separation* : REAL;
>> nodeColour*, edgeColour* : Ports.Color;
>> ...
>> END;
>>
>> ...
>>
>> VAR graphProp* : Prop;
>>
>> The view responds to Properties.SetMsg and Properties.PollMsg.
>>
>> I want to be able to control some of the view's properties are directly via
>> mouse interaction (e.g.. rotation changes xAngle, yAngle) and some via a
>> dialog. I want it to work like the control Inspector: the dialog edits the
>> properties of the focus view, and updates automatically when these change.
>>
>> As far as I can see, the only way to achieve this is to set up a background
>> task (Services.Action) to poll the properties of the Focus view using
>> Properties.CollectProp.
>yes, an action is necessary in order to update the dialog.
>The information, that the selection changed in a container
>is not distributed by any broadcast. Thus, you have to define your
>own action or you define a guard which adjust your dialog. Guards
>are executed regularly (in order to have a chance to react upon the
>change of a selection).
>
>> My Action copies these properties into a global
>> variable (graphProp) which is linked to my dialog. It then calls
>> Dialog.Update(graphProp) to update the dialog state.
>ok. The Action in ObxCubes first checks, whether a cube is
>visible at all. If not, the action terminates. It is restarted in the
>restore procedure of ObxCubes. Second it picks the singleton
>view and checks, whether it is a cube. If this is the case, then
>it is compared with the last singleton cube view. If it is different,
>then the properties of the new cube are picked and stored in
>the interactor, and then Dialog.Update is called to update the
>dialog.
>
>> The notification
>> procedure for the dialog copies the properties and calls
>> Properties.EmitProp to update the view state.
>I do not see why this is necessary, as only the dialog needs
>to be updated, not your view.
The dialog controls are bound to fields in a property record. As the user
changes values in the controls, I want the changes to be reflected in the
view that they are editing. One way of doing this is to use a view-specific
operation. For example, in ObxCubes:
PROCEDURE Notify*(op, from, to : INTEGER);
VAR v : View;
BEGIN
v := Singleton();
IF v # NIL THEN v.colors := para.colors;
END Notify;
Another way of doing it is via the Properties mechanism. Since I had
already implemented handlers for PollMsg and SetMsg, this seemed to be a
good idea.
If I understand it correctly, the notification procedure for my dialog
controls has to forward the modified Properties.Property to the view via a
Properties.SetMsg. Within the framework, the way to do this seems to be via
Properties.EmitProp. I presume this is how a generic property editor would
need to do it.
The notification procedure for my dialog controls looks roughly like this:
PROCEDURE Notify*(op, from, to : INTEGER);
BEGIN
IF (op = Dialog.changed) OR (op = Dialog.included) OR (op =
Dialog.excluded) THEN
Properties.EmitProp(NIL, graphProp);
END;
END Notify;
Unfortunately, it doesn't always work. Certain dialog controls seem to vary
the focus within their notification procedures. Text boxes and check boxes
work fine. The colour picker seems to focus itself (sometimes). If I print
the type name of the focus view obtained from Controllers.FocusView()
within Notify, I get:
pressed: PrivGraph.View^
released: PrivGraph.View^
changed: Controls.ColorField^
The view returned by Containers.FocusSingleton() seems to be correct, but
either way the SetProp message does not get sent to the view.
Could this be a bug? It seems strange that it works for some controls and
not for others.
>> It seems to work ... up to a point. Two problems that have me mystified.
>>
>> 1) In order to receive a Properties.PollMsg from the framework, it seems
>> that my view must be part of the selection within its container. I used
>> ObxCubes as an example of how this should work. In ObxCubes, if the user
>> clicks on the view with the modifier key, the view opens a dialog, and sets
>> itself as a singleton selection using:
>>
>> c := Containers.Focus();
>> IF c.opts # Containers.mask THEN
>> ...
>> c.SetSingleton(v);
>> END;
>yes, this is not the most elegant solution, probably we will change this
>for a next release. The usual case is that the view is selected as singleton
>in order to be manipulated by a property editor. Second, the editor
>should be accessible over the Edit->Object Properties menu.
>
>> Once my view is a selected singleton, it a receives Properties.PollMsg in
>> response to Properties.CollectProp. Unfortunately, in this state it doesn't
>> receive any control messages. Even when deposited in its own window, the
>> views container interprets control messages (eg. for resizing, moving, etc)
>> so I can no longer interact with it using the mouse.
>>
>> Question 1: How do I make my view so that it can receive PollMsgs AND
>> control messages at the same time? I realise that I can implement this
>> myself by bypassing the Properties/Focus mechanism, but it ought to be
>> possible to do within the framework.
>ok. In general, properties are only collected from the selection, thus your
>view has to be selected in order to receive Properties.PollMsg/SetMsg.
>
>However, the methods Properties.EmitMsg/CollectMsg are sent to the
>focus view (these are controller messages!). If the focus is a container,
>then he asks for the properties of its selection (and returns the
intersection
>of all the properties). If the focus is a simple view as in your case,
>then the these two messages have to be answered as well. You have
>to send a PollMsg/SetMsg to the view itself. Then you can change
>the properties even if the view has the focus.
>
>I have attached a simple view with a color. This color attribute can be
>changed using the Attributes menu either if the view is contained in a
>selection or if the view has the focus.
Thanks for that example. By forwarding Emit/CollectMsg I managed to get the
desired effect.
- Stewart
Received on Thu Jul 22 1999 - 05:04:53 UTC