From: richard@star.ic.ac.uk (Richard Syratt )
Subject: Gem programming
Organization: Imperial College, London University
Date: Mon, 23 Nov 1992 12:19:23 GMT
X-Posted-From: op.ph.ic.ac.uk
NNTP-Posting-Host: sol.ctr.columbia.edu


Some of these questions might have been floating around a couple of months
ago, but I've forgotten the solutions, so...

1)  NEWTOP message:  This can be used to disable scroll bars when sent to
    a window which is about to be deactivated.  Does it work?  I mean does
    multitos/gem send this message to an applications top window which isn't
    the desktops top window?  Also is there a simple command to disable
    scroll bars or should I just set the slider size to 1000 and ignore any
    scroll messages not sent to the top window.  Some people might think I
    should leave the bars active - but I learnt to program gui's on a mac,
    and scroll bars in the active window only is the convention used.  This
    makes sense since a click in a deactiveated window only has one operation...
    to bring it to the top... how can you scroll something you can't see??
    Obviously on large screens you can have windows next to each other - but
    most macs and st's don't have these.

2)  Bezier curves.  (I think):  I'd like to be able to produce cirlces
    ellipses, etc. using curves with dragable handles.  I've seen this done
    with four curves per circle etc. (a) is v_pline the
    best way to draw them (lots of points in array for definition) and (b)
    (not really gem but...) what's the equation/algorithm for these curves.

3)  Menus:  There was an argument going on about which key to use to cycle
    windows... (can some one mail me the standard key bindings for menu
    options??)  Something I've seen and like is a list of an applications
    open windows in a menu, selecting the item brings that window to the top.
    What's the best way to implement these "growing menus"?  I could have a load
    of blank entries and change the text as required - but that's ugly, or
    possibly a user defined object, but that'd highlight wrong.  The only other
    solution I can think of is to copy the menu tree, and change it on the fly,
    this would involve keeping track of the box which contains all the items
    as well as farting about with the object pointers to allow more space for the
    new line.  Is there an easy way to do this??

4)  Key bindings:  I was using ORCS and noticed a "key..." button in some of
    the editing windows.  Playing about with this (I've only ever had access to
    "mkrsc" before, so I don't know how standard this is), I've discovered that
    bits in the type and state fields of the object structure are set to represent
    the modifiers and key press (extra numbered bits at bottom of lists).
    A small routine can process a key press by
    comparing relevant bits in the key varaibles returned from event_multi
    and the fields in all the objects in the menu tree.  When a match is found
    you know you've got the right item... but is the item a child of the title???
    Of course not, so what's the best way of finding an items title...
    (another mac hang over - my menu handler requires title and item).  I've got
    one method, but it requires that the titles be in order.  Not very flexible.
    Obviously the same key bits could be used to add the short hand text to each
    menu item at the time the resource is loaded, is there a standard way of doing
    this and what is the normal character used to denote <ALT> in a menu item?
    This method will save any arguments on which key bindings are best since you
    can just change them if you don't like what you're given.

If you're still reading, thanks for your interest, now post/mail replies, even
if they're not code related but just your point of view on scroll bars etc.

Since I've spent the last three hours catching up with last weeks news, I'd better
get down to some work...  maybe a quick rescan first.

Richard
Newsgroups: comp.sys.atari.st.tech