Multiple Forms

[MLambert]

Hi,

Does Inform create/support multiple forms ?

Mike

[TempodiBasic]

Oh dear
read here
https://www.qb64.org/forum/index.php?topic=2519.0
and choose your way

[MLambert]

Thank you for the fast response.

The recipe form was the first i tried.

It does not give me multiple forms ... just a box that I can move around the single form... or maybe I am missing something.

I want Form1 .... Form2 ... Form3 .. with their own individual properties.

Thanks,

Mike

[RhoSigma]

GuiTools does support several forms, each form in its own independend desktop window but still able to allow realtime cross-form interconnections (src_MultiWinDemo).

[TempodiBasic]

@MLambert
Ok your request is impossible for now using Inform... it seems (as you can read in my CookBook about Inform) that the issue is about the QB64 structure and not about Inform developing. More can tell you the Developer of Inform Fellippe Heitoir.
(until QB64 emulates QB45 It can do programs with one window... or you can handle by your own a multiple window system into your program... but you must build it as I build the skeleton of Child Windows into the main window of the program...search into the forum to see something about it.)
PostScriptum:
the second way (that showed by NiktorTheNat) let you use different forms one at time.
And as you can see there is the alternative of GuiTools system.

[FellippeHeitor]

Yeah, multiple forms being controlled by the same application are not possible without some sort of "hack" like I've done with InForm itself. The main editor interface is one program and the form you edit is another program, both running simultaneously and exchanging data through a local tcp/ip connection to each other.

RhoSigma's alternative with GuiTools does a similar trick, running the same binary twice and locking processes.

All of this is, as Tempodi said above, to circumvent QB64's own limitation of a single-window approach.

[RhoSigma]

... All of this is, as Tempodi said above, to circumvent QB64's own limitation of a single-window approach.

True, I just wonder why it shouldn't easily possible to implement real multi window support. I mean we already have all we need, we can have multiple images using _NEWIMAGE, _LOADIMAGE etc. and we can designate where to read/write from/to using _SOURCE and _DEST. All we need is another "canvas" (window) to display our images in.

Expanding the SCREEN command with another optional parameter wouldn't even break compatiblity with legacy code, which simply doesn't use the optional argument:
eg. SCREEN {mode%|imagehandle&} [, , active_page, visual_page] [, windownum%]

Although I've no idea how complicated it would be to manage multiple OpenGL surfaces internally regarding _DISPLAY, _AUTODISPLAY etc..

[MLambert]

Thanks everyone..

Mike