Add Missing Z-ordering Functions

[ThatOneGuy]

LiveCode has always been missing a few options in the way of z-level ordering. The IDE can set a window to the front of all other windows and even force it to stay there, but is incapable of moving a window anywhere else without the addition of some external. There are already available functions for this in Linux and Windows from what I have heard, but, for reasons unknown to me, these are not being utilized by LiveCode. What I have been asking for over the last year or so is the addition of the missing option for setting a window to stay behind all other windows (both internal and external), or to simply ignore calls to advance in ordering. This would only require using the currently available window position functions that are available on each of the respective platforms that as yet cannot be accessed within the IDE.

Until this is added, my largest project will be eternally at a standstill as it requires this exact feature to work properly. All I can do for now is polish everything else in my program and wait for someone to spend the few hours it might take to include this functionality in the next release.

If this feature is included in one of the next few releases, I will be a very happy person.

[FourthWorld]

Why do you need this?

[shaosean]

Maybe he is making a desktop widget and does not need the "app" to move forward..

[ThatOneGuy]

Precisely. Do I need a particular reason to need something other than the fact that I need it?

[FourthWorld]

Precisely. Do I need a particular reason to need something other than the fact that I need it?

The goal defines the scope of possible solutions, and sometimes a goal can be addressed through non-obvious means.

While LiveCode is well suited for making applications, other less common uses like desktop widgets will currently require an external for Windows and OS X.

On Linux I've successfully used wmctrl to set the z-order of windows, including using an always-behind option. One of the reasons I'd asked about your use case was that if this was for a kiosk or other system where Linux could be a good solution I could point you to resources to get it done right now.

But since the goal is Windows-specific, until someone implements your feature request you'd need to write an external, or find some other Win component that can control window layering.

[shaosean]

The code to do it is simple, I wrote an external back for Rev v2 that did it, but with the externals standing still in time, I cannot re-build the external and even using the old external does not work in newer engines..

[ThatOneGuy]

If you must know. I have been working on a portable windows desktop environment that temporarily replaces explorer on any computer. If you ever tried using any of the portableApps stuff, you'd know why this has an appeal. It launches immediately, as opposed to the 10-15 seconds its closest counterpart takes, and includes a built-in file browser and other useful functions, like a terminal emulator. It also has completely portable settings that persist across computers it is used on. So it's basically a way of personalizing something like a library or school computer without actually using any of the computer's contents or changing local settings.

Right now, it looks fantastic and runs very smoothly. It looks almost like a Linux distro and runs pretty close to how Windows does, with a few minor differences.

The ONLY problem I currently have is the same problem that anyone faces when trying to make a Windows kiosk-esque app while still having full access to other programs. The desktop background I built does everything it is supposed to do, except for stay put.

I cannot use another Windows program to do this since it is strictly meant to be portable. Third-party solutions cannot be considered solutions in this context.

I have tried externals. It doesn't work correctly. It would be nice if there was an existing external that did what I need since I seem to be unable to create one myself.

Frankly, the feature I need should just already be an option.

[FourthWorld]

Explorer windows interleave with others. If your replacement is always behind, how do you access your files without minimizing or quitting all open apps?

[shaosean]

I think he is talking about the wallpaper window, not the file explorer windows..

[ThatOneGuy]

Well, one of the first commands run in my program is a "get shell(taskkill /im explorer.exe)"
There's no need to have explorer running if you're not going to be using it.
It's relaunched on a clean exit.

As I mentioned, the only thing I want to stay behind everything else is the background stack. Explorer also handles the desktop and wallpaper. With it killed, there's just a blank unclickable space that needed to be filled with something.

Since there seems to be a bit of confusion, here's some screenshots so you can see what I'm talking about. Sorry for the poor quality, but this site restricts file sizes quite a bit.

You may have noticed I changed the background in the middle of this.

explorer.exe is not running in these pics, so all you see is my program.

[shaosean]

You'd probably also need something to block out the CTRL-ALT-DELETE sequence..

[ThatOneGuy]

Agreed. I did it before on another program of mine, but now I can't remember how I got it to work.
That doesn't bother me too much though. The user might want access to the task manager and such.
Alt-tab also takes on the old XP look, and things minimize to the bottom of the screen in blocks... but I'm not complaining.

I am going to change it a bit more so it no longer does a forced registry edit to set the boundingRect where I want it.
I'm going to make it just take on the existing boundingRect when launched so it's faster and easier on the host computer,
at least until the "set windowBoundingRect" function actually sets the bounding rectangle. I don't see that coming for a
very long time though.

Strangely enough, the same code worked much smoother on an older version of LiveCode. Now with the newest update
it's running much worse and getting the oddest bugs that never existed before. Sad really.

Again, none of this matters if I can't get the background working correctly.

[shaosean]

Strangely enough, the same code worked much smoother on an older version of LiveCode. Now with the newest update
it's running much worse and getting the oddest bugs that never existed before. Sad really.

ahh.. good old open source

[ThatOneGuy]

Do you happen to be experiencing the odd behavior of the IDE thinking it's okay for us to edit it?

I constantly need to close and reopen the "edit script" stack because it gets locked in edit mode
and thinks the script window is a text field that can be selected and moved, and for some reason
it automatically selects that field and doesn't allow scrolling anymore.

The property inspector keeps re-sizing to odd heights that hide options, especially on the "regular
polygon" inspector that frequently turns into just the "regular" inspector and breaks down badly.

Occasionally, I get something in the script window that's actually some button or stack in the IDE
and it sometimes asks if I want to save the inspector stack before I close it.

All of the IDE windows should be one finished program, not "stacks" that can be modified with its own
edit tool and broken. Not only does this make absolutely no sense (no other IDE can change its own
code and contents accidentially), but this isn't all that complicated to fix... or wouldn't have been if
the original developers had made it correctly in the first place.

I imagine the developers have heard a bit about this already, but it hasn't been fixed in the last
few updates and has existed, though not nearly as bad as now, since I first started using LiveCode
years ago. It's also sad to think that LiveCode 6.1 IDE is identical in almost every way to the old
RunRev 3. It has been how many years since then? Earlier versions actually seem to look a bit
different at least, but probably only because that was almost ten years ago.

For some reason I thought that this going open source would be hugely beneficial to it's development,
but I guess there're not enough people working on it or who actually care if it is a quality product.

If you hadn't noticed, this is entirely unrelated to the topic of this particular page. I should've made
a new post about this before I started ranting on here... Oh well.

[FourthWorld]

Do you happen to be experiencing the odd behavior of the IDE thinking it's okay for us to edit it?

I constantly need to close and reopen the "edit script" stack because it gets locked in edit mode
and thinks the script window is a text field that can be selected and moved, and for some reason
it automatically selects that field and doesn't allow scrolling anymore.

I haven't seen that before. What's the recipe for reproducing it?