Display text over View

[MusicallyInspired]

I'm trying to put a Display on top of a button view but it keeps appearing underneath the button. Is it a priority setting or something?

[Doan Sephim]

I tried to change the priority settings of the view, but that didn't seem to have any effect. I also looked through the kernal reference help file on "Display" but it didn't have any parameters that looked like it would do anything to print over views.

I dunno! If you want it over the view, can you just draw it on the view?

[MusicallyInspired]

I suppose I could. It's just that it would be easier to use the same view for all 4 buttons I'm going to be making. I know that KQ1SCI uses text on view for it's startup menu because I'm using the same button views. If worse comes to worse I'll just put it on the buttons in the views.

[troflip]

KQ1 uses a later SCI interpreter... it has additional functionality (e.g. scrolling).  Just guessing here, but maybe the text on a view is some of that additional functionality.  It seems you'd need a priority parameter with the Display function... maybe that version of the interpreter provides such a thing.

[lskovlun]

Display strings inherently have no priority. I think what you need here is the Animate() trick I hinted at in the other thread. Try adding this line after initializing your button views and before you call Display().

Code: [Select]

Animate((send gCast:elements()) FALSE)
What you're running into here is basically that there are two kinds of graphical objects in SCI: Those that are added to some kind of list and "remembered" when the screen is redrawn on the next game cycle, and those that aren't. Display() strings are of the latter type, and they therefore disappear on the next game cycle if you add a new view to the screen that overlaps with them. By including the above line to your code, you're forcing the screen redraw to take place right away, thereby making sure your Display() strings aren't obliterated.

[troflip]

This is an example of one of their Display calls, from a function called during TitleButton::init (so only called once presumably?)

Code: [Select]

  055a:39 09            pushi 9 // $9 nsTop
  055c:39 57            pushi 57 // $57 printLang
  055e:78               push1
  055f:39 64            pushi 64 // $64 respondsTo
  0561:39 4c            pushi 4c // $4c claimed
  0563:38 0095          pushi 95 // $95 setMark
  0566:39 69            pushi 69 // $69 allTrue
  0568:39 04            pushi 4 // $4 x
  056a:39 66            pushi 66 // $66 add
  056c:39 0e            pushi e // $e lsLeft
  056e:43 1b 12         callk Display 12

Here we have, working backwards:
9 parameters:

Code: [Select]

87 1 // This is the text resource... looks like KQ1 interpreter supports them directly in kernel functions???
dsCOORD 76 149
dsFONT 4
dsCOLOR 14

So there are no suprising parameters (other than the text resources being able to specified directly, which I don't think is possible in 'pure' SCI0, at least not according to Brian's template game).

But like Lars suggested, it does call Animate at the beginning of TitleButton::init.

I don't really understand how calling Animate once at the beginning prevents a view from obliterating the text during the next game cycle....?

[MusicallyInspired]

Yeah, that animate line didn't work. I'll just make the words on the view itself. Must be an SCI01 thing.

[lskovlun]

I don't really understand how calling Animate once at the beginning prevents a view from obliterating the text during the next game cycle....?

It does that because Animate() tries to redraw as little as possible each time. So when you call Animate() explicitly, you force the necessary redraws to happen at a time where you can live with them. I used it in the opposite way, actually, in the DisplayKeypad class, to make sure the displayed text is really gone before handling the Enter button (because a user-defined script might get called and invoke Print or something).

[troflip]

But if, for example, a view were to move over the text, it would be gone again, correct?  So it only works if the view on top of which you're writing text doesn't move or change in anyway that would cause it to redraw (and nothing else causes that area of the screen to redraw) during the next game cycle.

For everyone's benefit, where is this DisplayKeypad code you're talking about?

[lskovlun]

Code: [Select]

[quote author=troflip link=topic=230.msg920#msg920 date=1181153377]
But if, for example, a view were to move over the text, it would be gone again, correct?
So it only works if the view on top of which you're writing text doesn't move or change in anyway that would cause it to redraw (and nothing else causes that area of the screen to redraw) during the next game cycle.
That is why you call Animate() in the first place. To prevent this from happening. (When you call init on your view, it is not displayed straight away)

For everyone's benefit, where is this DisplayKeypad code you're talking about?

In the thread 'A generic Keypad class' in the HowTo section. Attached as a .zip file.