two forms in one window

I know this sounds like a dumb thing to do, but I tried anyway. 
(Thinking along the lines of "frames".)

It compiles fine.  Execute results sometimes in freeze but with open 
window, or sometimes in shut down depending upon what form you load in 
first.

So a couple of thoughts from my childlike behavior:

1.  A form always has to "load" in the window in the upper right
corner. 
Why?

2.  If you can only put A form in A window, what is the advantage of 
even having two separate objects. If all the window is "the border"
and 
a place to hang menus/icon bars on why not just allow all of those 
"form" controls to be loaded directly into "a window".

3.  What really is "A FORM".  By that I mean, if no attributes are set

and nothing is IN IT. Does it really exist?

4.  Can you put [a] window[s] within a window?

JDK

Kromkowski wrote:
> I know this sounds like a dumb thing to do, but I tried anyway.
> (Thinking along the lines of "frames".)

Not really a dumb thing to do. Some of the preparatory work has been
done to allow more than one form to inhabit the same window.

> It compiles fine.  Execute results sometimes in freeze but with open
> window, or sometimes in shut down depending upon what form you load in
> first.

How did you try and make this happen? Currently you should just get an
error if the window is already occupied. To replace a form in a window
by another form, the first form must be removed by it setting its
container to .nul. Then the second form can be moved into the window.

> So a couple of thoughts from my childlike behavior:
> 
> 1.  A form always has to "load" in the window in the upper right
corner.
> Why?

Just the way it is currently.

> 2.  If you can only put A form in A window, what is the advantage of
> even having two separate objects. If all the window is "the
border" and
> a place to hang menus/icon bars on why not just allow all of those
> "form" controls to be loaded directly into "a window".

A form is a concept independent of the actual controls in the window.
Unlike in Superbase, or most other languages that use a GUI, the form
exists independently of its representation in a window. That has a
number of advantages, like being able to swap forms in the same window
but still have all the data on the form that was swapped out.

Also, a form can be placed in a window, a child window, a dialog, a tool
bar, and other things we haven't made available yet.

> 3.  What really is "A FORM".  By that I mean, if no attributes
are set
> and nothing is IN IT. Does it really exist?

Absolutely! Like I said before, forms in SIMPOL exist independently of
their physical representation.

> 4.  Can you put [a] window[s] within a window?

Sure, have a look at the child window capability.

Neil Robinson wrote:
> Kromkowski wrote:
>> I know this sounds like a dumb thing to do, but I tried anyway. 
>> (Thinking along the lines of "frames".)
> 
> Not really a dumb thing to do. Some of the preparatory work has been 
> done to allow more than one form to inhabit the same window.
> 
>> It compiles fine.  Execute results sometimes in freeze but with
>> open window, or sometimes in shut down depending upon what form you
>> load in first.
> 
> How did you try and make this happen? Currently you should just get
> an error if the window is already occupied. To replace a form in a
> window by another form, the first form must be removed by it setting
> its container to .nul. Then the second form can be moved into the
> window.

Well I didn't really the error, I actually got the window with both 
forms looking as anticipated and only then did things get squirrelly. 
But with the new IDE, I now get Error 15: Object is in use.

Here was code:

function main()
   string sResult
   wxform f, f2
   integer iErrnum
   wxwindow w

   iErrnum = 0

   // Create our initial forms
   f =@ wxform.new(640, 400, error=iErrnum)
   f2 =@ wxform.new(140, 140, error=iErrnum)
   if f =@= .nul
     sResult = "Error " + .tostr(iErrnum, 10) + " creating
form"
   else

   f.setbackgroundrgb(red=0xa0, green=0, blue=0xa0)
   f2.setbackgroundrgb(red=0xb0, green=0, blue=0)

   w =@ wxwindow.new(0, 0, 640, 640, captiontext="Test form window", 
error=iErrnum)
     if w =@= .nul
       sResult = "Error " + .tostr(iErrnum, 10) + " creating
window"
     else
       w.onvisibilitychange.function =@ quit
       w.setbackgroundrgb(f.backgroundrgb)
       f2.setcontainer(w)
       f.setcontainer(w)
       wxprocess(.inf)
       sResult = "Success"
     end if
   end if
end function sResult

function quit(wxwindow w)
   wxbreak()
end function

>> So a couple of thoughts from my childlike behavior:
>> 
>> 1.  A form always has to "load" in the window in the upper
right
>> corner. Why?
> 
> Just the way it is currently.
> 
>> 2.  If you can only put A form in A window, what is the advantage
>> of even having two separate objects. If all the window is "the
>> border" and a place to hang menus/icon bars on why not just allow
>> all of those "form" controls to be loaded directly into
"a window".
>> 
> 
> A form is a concept independent of the actual controls in the window.
>  Unlike in Superbase, or most other languages that use a GUI, the
> form exists independently of its representation in a window. That has
> a number of advantages, like being able to swap forms in the same
> window but still have all the data on the form that was swapped out.

But if forms were windows (and you could hangs formcontrols including 
data onto a window, then you just swap out "child" windows.

I'm not sure what you mean "unlike Superbase", in SB a form exists 
independently of its representation in a window, it is an .sbv.
But no sense in worrying about that now.

> Also, a form can be placed in a window, a child window, a dialog, a
> tool bar, and other things we haven't made available yet.

But a window, a child window and a dialog ARE just windows, aren't they?
There is really no distinction other than name.  Is my understanding 
incorrect?  As to a form in a tool bar.  I thought a tool bar, an icon 
bar and a menu bar where really all the same kind of thing:  namely, a 
menu bar.

>> 3.  What really is "A FORM".  By that I mean, if no
attributes are
>> set and nothing is IN IT. Does it really exist?
> 
> Absolutely! Like I said before, forms in SIMPOL exist independently
> of their physical representation.
> 
>> 4.  Can you put [a] window[s] within a window?
> 
> Sure, have a look at the child window capability.

Are tool bars, icon bars, and menu bars really a form of a "child"
window?

Kromkowski wrote:
> Well I didn't really the error, I actually got the window with both
> forms looking as anticipated and only then did things get squirrelly.
> But with the new IDE, I now get Error 15: Object is in use.

That is probably what you should get, and the fact that anything else
worked was a bug that we fixed in the interim.

>> A form is a concept independent of the actual controls in the window.
>>  Unlike in Superbase, or most other languages that use a GUI, the
>> form exists independently of its representation in a window. That has
>> a number of advantages, like being able to swap forms in the same
>> window but still have all the data on the form that was swapped out.
> 
> But if forms were windows (and you could hangs formcontrols including
> data onto a window, then you just swap out "child" windows.

That assumes that you have a child window in every window. In which
case, you have not gained anything.

> I'm not sure what you mean "unlike Superbase", in SB a form
exists
> independently of its representation in a window, it is an .sbv.
> But no sense in worrying about that now.

I am not talking about storage, I am saying that programmatically even
while the code is running and the form is open, it exists and can be
interacted with programmatically even if it cannot be viewed physically,
which is not really possible in Superbase.

>> Also, a form can be placed in a window, a child window, a dialog, a
>> tool bar, and other things we haven't made available yet.
> 
> But a window, a child window and a dialog ARE just windows, aren't they?
> There is really no distinction other than name.  Is my understanding
> incorrect?  As to a form in a tool bar.  I thought a tool bar, an icon
> bar and a menu bar where really all the same kind of thing:  namely, a
> menu bar.

A window, child window, and dialog are just windows, but then, from the
MS Windows perspective, so are all the controls. If we wanted the
customers to have to understand all of that, then we wouldn't have
bothered making things work differently, but then they would eventually
all need to be C programmers. As for a tool bar and an icon bar, they
are the same thing. A menu bar is not, although in some modern
user-interfaces, it is hard to tell the difference.

>>> 3.  What really is "A FORM".  By that I mean, if no
attributes are
>>> set and nothing is IN IT. Does it really exist?
>>
>> Absolutely! Like I said before, forms in SIMPOL exist independently
>> of their physical representation.
>>
>>> 4.  Can you put [a] window[s] within a window?
>>
>> Sure, have a look at the child window capability.
> 
> Are tool bars, icon bars, and menu bars really a form of a
"child" window?

From an OS perspective, these are all child windows, but they have a
considerable amount of attributes and pre-programmed behavior that is
specific to what they do.