one window app

[Greg O.]

I would like to create an app that has multiple stacks open inside a main stack. The sub-windows will be completely contained inside the main window. Something like the attached picture. I am afraid I am stumped as to where to even start.

Thank you,
Greg

[Mark]

Hi Greg,

You can't do this with LiveCode, unless you want to emulate the entire interface using one stack and many groups. You would have to emulate the windows, tool bar, everything.

Kind regards,

Mark

[dunbarx]

Hi

You can certainly place any number of stacks inside a "main" stack, and each will have ordinary stack attributes. The problem will come in, as Mark intimated, when you try to use any element of the main stack. It will become the topStack, and hide all the subs. Now you can fix this by setting the style of all the substacks to palette. You will have to manage the locs of those substacks when you move the main stack, and likely have to manage a host of other issues as well to create for the user what seems to be a single integrated window assembly. But it can surely be done.

For example, you have to completely build your substacks before making them palettes, because you have little control over them in that style. They always are in "browse" mode, so you cannot, say, add a field to them. You can always reset them to topLevel down the road, and have full control again, but this is just an instance of the extra effort you will need to do to build your app like I think you want to.

Write back with your progress on this, it should be interesting and instructive.

Craig Newman

[FourthWorld]

Microsoft deprecated MDI years ago; I'm not sure users are ready to go back. There are probably options that are both simpler to code and simpler for users to work with. What does the app do?

[Greg O.]

I wish I could say I was surprised that it turns out to be an outdated, and hideously complex way to go about things. The software in the picture is over 6 years old and has not been updated since. I think I will go with a tab panel rather than all the heavy lifting it would take to do the stack within a stack dance.

The software will be used to manage an inventory of two way radios. I wanted the ability to have all the maintenance records, where the radio is supposed to be placed, as well as serial numbers, in service dates and so on. I am now thinking a tabbed interface like a web browser with each tab containing the results of a search for the radio in the backing database. This might be an easier way to go. Then again I may need to once again simplify things and go to a siple tabbed panel and only have the information for one radio at a time visible.

While looking into doing something similar to the picture in the first post, I did some experimenting with having an invisible group that would be essentially a pseudo stack and cloning it every time a record is requested. Then having that new group copied into a larger group in which the pseudo stack could shown and moved around. I couldn't figure out how to keep the pseudo stack from being dragged out of the visual area of the larger group. I essentially need to stop the mouse from leaving the larger group if it is grabbing something.

I clearly need to learn a great deal more about constructing stacks as palettes. From the sound of it it can be a powerful setting.


Thank you all for confirming there wasn't a blatantly obvious and simple solution I just walked past.

Greg

[Mark]

Hi Greg,

This sounds like a relatively simple database. I'd just start playing with SQLite and a stack with a few fields and the necessary buttons. Once you get that to work, you can start worrying about the interface.

Actually, if you're looking for a web browser-like option, you could also do everything in PHP (or OnRev/LiveCode Server) and just run it as a website in the browser. Whenever I need a simple front-end for a database, thats what I do.

Kind regards,

Mark

[Greg O.]

Sorry for the delay, life went pear-shaped for a few days.

I have already developed most of the underlying SQLite database and have written a few small programs that utilize them. I have not used php, though this might be a great time to learn.
Thank you all for your great ideas. This discussion didn't go the way I thought it would, but did lead to some great experiments.

[FourthWorld]

This discussion didn't go the way I thought it would, but did lead to some great experiments.

LiveCode's flexible enough that you can usually get what you want, it's just a question of how hard you want to work to get it.

With MDI deprecated, LiveCode offers no direct support for that windowing model, with the team focusing instead on windowing behaviors OS makers prefer us to work with. But there are at least two possibilities for approximating an MDI:

- You could make window-like objects in groups; draggable, resizable, and even overlapping, with controls for close, zoom, and minimize
- You could have the windows as shown in your screen shot, using a backdrop behind them to keep them visually isolated from other apps.

That said, Microsoft's reasoning behind deprecating MDI may be worth heeding: at its peak it was used only by a slender minority of apps, and behaves so differently from other apps that in their user testing they found it more confusing than it was beneficial.

The evolution of GUIs is a lot like the evolution of digital typography: once Macintosh introduced multiple fonts, people were producing documents that had so many different fonts they looked like ransom letters <g>; with GUIs, once we had multiple overlapping windows then having lots of them became almost a badge of honor.

But over time people learned to simplify their documents by using fewer fonts, and GUIs designers have migrated to ever-fewer windows.

For example, back in the '90s it was common for video editing software to have at least three windows: clips, timeline, and a preview window to play it back.

Since the turn of the century most video editing software has migrated to a single window, in which those three views are present as panes with adjustable dividers between them.

Providing various views into data in separate windows delivers a certain flexibility for the user, but at a cost: they'll have to click on them to bring them forward, manually adjust them to be next to one another, etc. Putting those views into panes (or in LiveCode, in groups), still provides the ability to have multiple views into data but with much less interactive overhead.

Whether your client is delivered in LiveCode, or in HTML as Mark suggested, providing a single window for all of your data views will likely make for simpler user interactions. Extra bonus points that it'll be simpler to code as well.

[Greg O.]

But there are at least two possibilities for approximating an MDI:

- You could make window-like objects in groups; draggable, resizable, and even overlapping, with controls for close, zoom, and minimize
- You could have the windows as shown in your screen shot, using a backdrop behind them to keep them visually isolated from other apps.

I did some experimentation with that. I have a great deal to learn, but it seemed worth exploring a little more. The issue i ran into was groups could be dragged off of the visible part of the stack and lost forever. I have yet to figure out how to stop that.

Since the turn of the century most video editing software has migrated to a single window, in which those three views are present as panes with adjustable dividers between them.

I will see if I can figure out how to set up those dividers, that actually sounds like a great idea.

The evolution of GUIs is a lot like the evolution of digital typography: once Macintosh introduced multiple fonts, people were producing documents that had so many different fonts they looked like ransom letters <g>; with GUIs, once we had multiple overlapping windows then having lots of them became almost a badge of honor.

I can't begin to tell you how often I see that still being abused.

Whether your client is delivered in LiveCode, or in HTML as Mark suggested, providing a single window for all of your data views will likely make for simpler user interactions. Extra bonus points that it'll be simpler to code as well.

I do strive for an interface that doesn't need any instructions or explanation. With that in mind, the MDI is out on the curb.

Thank you again for the wise insight and guidance.