Re: [freesci-develop] Port problem investigation

[lskovlun]

Hi,

I'm writing this from webmail. Sorry if the formatting is a bit screwed
up.

[Christoph wrote]:

>> Obviously, SSCI did not use a widget system. This difference is the
>> source of a few problems already (the computer monitor in PQ2 springs
>> to mind).

> Are you referring to the odd behaviour of the "cursor"
> here, or is there something else that I'm missing?

Visual artifacts when thee game tries to delete text on the screen by 
overwriting
it with spaces, yes. This situation should also be detectable, btw.

[...]
>> In Jones, however, the wrong port is set and our code does
>> not detect the situation. Therefore, the new copy of the widget is
>> allowed to survive, and since it belongs to a different port, is
>> placed at the wrong location.

> All right. Do I understand this properly in that the widget should be
drawn to
> whichever port it was associated with the first time one of {DrawControl,
> HiliteControl, EditControl} was invoked on it? If so, is there a way of
> destroying this association, e.g. by destroying the port?

In the general case, no. If a game chooses to draw widgets on the window
manager port (bad, bad game!), there is nothing we can do about it since
it lives as long as the game runs. In the Jones case,
the window is disposed of as normal (DisposeWindow()). We could free the
association there.

> Well, re-drawing something which is currently drawn below something else
with
> the same priority (!) is inherently not innocuous.

It should be in the usual cases (Save/Restore dialogs and the like are all
I can think of). I may be missing something of course.

>> 2. Jones employs a class called the KeyMouse, allowing you to
>> control the game from a keyboard. This is not th
>> usual way keyboard control is handled (not even in SCI1), but a Jones
particularity. As
>> art of its processing it is meant to switch the window manager port
>> temporarily, saving the old one in a property. Due to a bug in the
>> class, this field gets clobbered (also in SSCI), but because of (1),
>> this has no consequences in SSCI.

I am going to elaborate on this because Matt asked about it on IRC. What
happens is that you
have a class with a property -oldPort- and two methods, setPort and resetPort.
Of course, for
resetPort to do the right thing, you mustn't call setPort more than once
before resetPort. But the code does just that.

> Updating the widget would also be an option, but I'm not sure what the
> semantics are supposed to be if you completely change a control structure
in
> between calls to EditControl-- will the old control leave visual artifacts,
or
> will it be destroyed?

You wouldn't do that. As I indicated (perhaps poorly), DrawControl is called
once on every update
(that is, when you use the KeyMouse to move between options, or regularly
when dragging sliders),
while EditControl is called by a generic event loop, beyond script control.
EditControl does not update the widget unless it absolutely has to (it received
a suitable event), and doesn't touch anything that doesn't have "editing"
behavior (i.e. anything besides Edit controls). In the cases where EditControl
actually does something, the script may be assumed to take proper care of
port numbers.

-- Christoph

Lars