.
                      WINDOWING_PLANS
                      ===============
.
Okay. Multiple forms automatically brings up the subject of
 how to handle windowing.
.
I already worked out a simple strategy for using what I think of
 as "support forms". (MessageBox, InputBox, etc).
. 
These little support forms have a short life cycle when used.
 I simply pcopy 0,1... this screenshots whatever is up.
 MessageBox or InputBox... can doodle away all it wants to.
 When I am done with MessBox or InpBox?
 Simply pcopy 1,0
 whatever was on the screen? is now instantly back.
 the 1 buffer strategy.
.
This would work fine with a "one main form" approach.
 You paint and have "the form"... and you use a support box
 and buffer back. You're back at "the form".
.
You could switch out "the form" with other(s), and continue
 doing the buffered support form approach.
.
If the end user followed this... "guideline" and was content
 working within that framework (One "big" form at a time,
 support forms buffered), it would be simple, solid, done.
.
This is ONE possible approach. Another possible approach?
 "Every form gets its own page".
 This strategy is fairly straightforward.
 during startup (I figure during OpenProject) and between
 _display's, we would then all without _display-ing:
.
--- cls
--- paint form 1
--- pcopy 0,1
--- cls
--- paint form 2
--- pcopy 0,2
--- cls
--- paint form x 
--- pcopy 0,x
--- cls
.
This would be invisible to the user, as it would happen between
 _display's.
 Under this system, every form has its own page.
 Swappin pages (forms...) in and out would be F-A-S-T
 (screen buffering tests? were instantaneous on LINUX)
 We could still use "support forms" and buffer them, but,
 there would be no multiple project forms at once.
 A .visible=1 on any one form would necessarily trigger a
 .visible=0 on *all* other forms.
.
since the way things stand now is that .visible=1 is also a
 de-facto ".clickable=1" property, this system though
 somewhat primitive would automatically take care of the
 focus issue.
.
The third option? "real windowing".
.
What would "real windowing" even be like as a strategy?
.
Right now, .visible allows things to be painted, which allows
 them to be clicked on. Real windowing, I remember had several
 components. LAYER was one important one, another was FOCUS.
.
When I would paint a "box" of DIY "labels" (before this project),
 I would highlight one of the label-menu-options, then the 
 spacebar and the arrow keys allowed you to move and select by
 pressing enter.
.
That "highlighting" is just a primitive focus.
.
Under real windowing, one can (theoretically, anyways) paint
 literally any NUMBER of forms one after another; they just
 "stack up" in that classic loose-deck-of-cards pile they
 always seem to make.
.
Okay, for this, simply tracking and enforcing some ORDER of
 the forms being painted would I think paint them in that
 loose pile format. The last one painted? would be the one you
 "see" all of it, as it was painted last. Like the "last
 grafitti" is the one you see the best.
.
Okay, this *component* seems do-able. I can already paint
 forms at will and on demand. Whatever is visible gets painted.
 KINDA the way it works now. The big difference would just be
 making sure the "paint order" was correct.
.
I can now see the .layer property I remember from my VB days
 and what it's for.
.
I suppose for this component, layering, I would:
1) add a .layer property
2) as each form gets picked up out the def'n file...
   it gets an incremented .layer property number
3) then, if the end user wants to adjust the order,
   they can. I smell "a couple FUNCtions".
.
That's only half the battle though. There's still the matter
 of FOCUSing. How about a .focus property? I mean, why not.
 we can at least plan this, see if it seems do-able.
.
.focus property. Rules? We need rules. Let's make some up!
.
 focus=0 is "out of focus"; IE, dont check clicks.
 (focus=0 is a lot like .visible=0, except it still gets
  "painted" in the "deck pile")
.
focus=1 is "in focus"; IE, check clicks...
                       *and* make sure its painted LAST.
.
We need a "cant click on it" no-focus-allowed state, some
 forms are just for looking at, not for adjusting anything.
 focus=-1; is "no focus allowed"
.
I suppose someone, somewhere... will request a "always in focus"
 setting. All right then, focus=2 (or greater) would then be
 always in focus. Things like opening a listbox or sending out
 a MessageBox would be the only way to suspend checking for
 clicks, and even then it goes right back.
.
Okay then.
 2 new properties.
 finagle how to apply these rules.
 I am leaning towards clicking on taskbars and topbars
  will grip focus.
.
 (This just has to be harder than
 it seems on paper at design time)
.
UPDATE: I am starting to try to finalize windowing.
 One big form, I already know I can buffer in and out for
 smaller support forms, and even swap out the main form and
 keep going. So I always have a fallback position.
.
UPDATE: Painting one and two forms is fine and all for a demo,
 but to really demonstrate windowing? Four. First impressions
 painting 4 forms, with backgrounds, overlapping and letting
 parts "show"... *pretty cool* and thats doing 'nothing'.
.
The forms stack up; the last form naturally is perfect.
Everything *looks* fine. I already KNOW, that since all 4 forms
 are .visible=1; that all are clickable. I know there are
 overlapping forms, clicks are being checked form by form, so,
 the *first* form gone thru that hits a click, will capture it.
 Since they are all visible, the state created is unique;
The FIRST form painted, catches the click.
The FIRST form painted? Is unfortunately the LAST to be seen.
(its buried)
.
NOTE: While this is the almost exact opposite condition we
 *want*, we have achieved this state-condition by doing:
                       *nothing*.
So, I consider it worthwhile to observe this
 'natural condition' and see if I can work with it.
 I mean, I simply need 'a focus' system. BeFORE I charge in
 and hard code an .order property, and a .focus property,
 and FORK the whole project on hold to try it out, to try
 to code in the rules and test it.
BeFORE I go through all that, I want to carefully observe
 the *natural* state condition. WIthout yet implementing any
 true focus or layer... what if I simply paint the forms in
 reverse order from what I do now? What would happen?
Nearly as I can figure... the LAST form painted would then
 be the FIRST form checked for clicks. I just want to point
 out, that by doing *nothing* except painting in reverse
 order, we get to *almost* where we want to be windowing-wise.
That would be too easy, wouldn't it? Reversing the order
 of painting also reverses the order of picking up clicks.
.
Still, the natural state doing nothing, is workable.
.
Always in search of anything remotely elegant, I tried a
 simple focus rule out. The last form painted? Has focus.
 When clicking and trapping a click, I check to see if
 the clicked on object is in focus, no different than when
 I check to see if the X or Y is in bounds.
.
Wow, actually worked. All the .visible forms got painted,
 and the last form (#4) retained "focus". Clicks on all other
 (.visible) forms were ignored.
.
Switching focus? would be easy, simply call PaintOneForm()... the
 last form painted gets "focus". So, if you paint ONE form,
 you *know* that one painted form got, and more importantly
 retained... focus.
Now... this is *really* close to what we want.
 The only thing missing, would be the user's ability to change
 focus, just by clicking "off form" so to speak; IE, clicking
 on a form other than the focus-form.
.
UPDATE: the focus works fine, clicking off-form to grip focus
 does not. Locking out "not focused" is what allows focus to
 work, allowing off-form clicks re-introduces overap-clicks
 being an issue. Simply switching focus, with no overlaps or
 behind-form clickable items, works quite well in fact.
.
But, because of the overlap issue, you are prone to grip focus
 on a form behind the one you are looking/clicking at.
.
I am giving serious consideration to simply going with the 
 "last painted focus" approach, but, removing the off-form
 gripping. It seems rock solid for locking in clicks to the
 focus-ed form. Its easy to re-set focus, simly paint the 
 form you are interested in; it gets focus automatically.
.
I'm not overly concerned with the user not able to flip thru
 forms like pages in a phone book; and if the programmer
 *wants* the user to be able to grip focus? The programmer
 will provide a button to click on; that will paint THAT form,
 that will switch the focus to the one you now want focus-ed.
.
