Re: jiri's widgets
tacitus wrote:
>i've been looking into this too - haven't got far yet.
>i had a theory, which i hadn't had a chance to test, that if you want
>the bmp to be a child of the window, and inherit charcterisitics like
>moving when the window moves and closing when the window closes, you
>should create a widget bmp with pic.e for example and then add that
>widget to the window as a component. is this correct?
Yes, and no, or maybe... (I shall explain later, in response to your
second note :))
>i came up with this when i tried to get the exit flag (exitf = true)
>to work in response to a wait_key routine. nothing happened - but
>when i splice it to a widget, it works. i got some widget things to
>work in response to wait_key, such as show(), but my theory is that
>loop() will only recognise tracked widget events, not ordinary DOS
>events.
The loop() looks at *all* rat and keyboard events, but only
selectively. It simply rejects events not associated with a *tracked*
widget, because the loop() does not know what to do with these events,
how to respond to them. This information (methods) is imbedded within
individual widgets.
Btw, wait_key() is a tricky, weird customer, I do not like it very
much. With NT machines it's no end of trouble, especially in
combination with tick_rate(). If it does not lock your machine up
immediately, do not worry, if you let it run long enough, eventually
it will...
Later tacitus wrote:
>I'm wrong
Are you crazy? NEVER admit any thing like this in public, the bastards
will use it against you...
>so long as the image is displayed over (and after) the window, either
>display_image() or show(pic) will create image as child of window
>without any further coding required. here's my example:
>
>include screen.e
>include pic.e
>include window.e
>
>integer win
>integer picture
>sequence bmp
>
>bmp = read_bitmap("circles.bmp")
>bmp = bmp[2] -- ROBERT, we should be able to subscript a function.
>
>win = window("Window for Pic Test", 150, 100, 400, 300)
>picture = pic(200, 175, bmp, -1)
>--affix(win, "par", picture)
>--bind(win, "ima", bmp)
>
>set_screen("Pic Test", 18, WHITE)
>
>show(win)
>show(picture)
>--display_image({200, 175}, bmp)
>
>
>loop()
>set_text_mode()
>
>----------------
>i thought either the affix or bind lines were required, but not so.
>the display_image line works instead of show(picture).
>
>have i got it now jiri?
How can I tell? :)
All three methods above are valid, it really depends on what you want
to do. Sure, you can blast it onto the screen using just
display_image(). But once you enter the loop(), you basically lose
control over it, unless you manipulate it with some additional methods
imbedded in a widget or widgets.
If the image is encapsulated (gosh, I hate this OOP speak, methods,
inheritance, children and parents, polymorphism...), you can,
generally, show it, hide it or shift it or what ever.
The only advantage of affix(ing) it to a window is that it really
becomes part of that window. If you close the window, for instance,
and later open it again, perhaps somewhere else on the screen (or you
shift it at some stage), the image is already there where you want it.
Now I shall return, just briefly, to two consecutive lines commented
out in the code fragment above.
>--affix(win, "par", picture)
"par" is now a key for a 'part' (subwidget, if you like) with
'picture' index. That's wrong. There are only four 'standardized'
(with special meaning) keys in widgets, and "par" is one of them. It
is short for 'parts' (but not in the new, just lost version...), and
the system looks for it when it manipulates compound widgets. The
other 'prohibited' keys are 'box', 'x' and 'y'. 'box' is used to
define rectangular area for tracking of rat events. It also contains,
together with 'x' and 'y', the width and height as well as the
*absolute* coordinates for each widget.
>--bind(win, "ima", bmp)
Wrong again (isn't that really off-putting?). "ima" (short for image,
I know, pretty crummy), is a label (key) for a container inside a
window widget in which the underlying part of the screen is stored. So
what ever you put in there will be overwritten (and lost for ever) the
moment you display the window. You can, of course, do it this way as
well, but you have to create a new, suitably named item:
make(win, "my pic", bmp)
would be a good start. Note, 'make', not just 'bind'! 'make' will
create a new "my pic" item if it does not already exist, while 'bind'
will bind a new value to an already existing item. If "my pic"
labelled item does not exist, the 'bind' will fail.
I said 'a good start', because the line alone is not enough to display
the new, enhanced window correctly. Its "show" method has to be
extended as well to include the new property. So, on the whole,
affix(ing) a new (sub)widget is probably the easiest way...
I hope I have not contributed too much to the steadily rising level of
befuddlement.
jiri
|
Not Categorized, Please Help
|
|
