LiveCode Forums.

The ability to edit the script editor was a bug that was fixed in 6.1. Are you using the latest version?

I'm still waiting on this very important, yet missing, feature. It only requires a call to the windows setwindowpos function (or its mac or linux equivalent) that is currently unreachable within livecode, but is available in almost every other programming language.

As well as this, the ability to create an app bar in windows should also not require an external. It would be incredibly simple to add this function since the Microsoft website explains in great detail how to do it and even has c++, c#, and vb sample code that does it for you. All that needs to be done is to modify that code slightly, compile it, and add it as a window mode. Why is that taking so long to happen?!

Though I do have some experience with c++, I do not have the capability to create any externals

It's been years since there's been any real changes to window functionality. When will we finally see something new in this IDE?

This lack of new material is borderline laziness and is, in my humble opinion, inexcusable. It is about time for a major update if you ask me.

ThatOneGuy wrote:I'm still waiting on this very important, yet missing, feature. It only requires a call to the windows setwindowpos function (or its mac or linux equivalent) that is currently unreachable within livecode, but is available in almost every other programming language.

I've added a reference to this discussion to the feature request submitted for this in the issues database:
http://quality.runrev.com/show_bug.cgi?id=704

Yes, you'll find that it's been outstanding for a long time, but please understand that OSes provide thousands of APIs for all sorts of things, so RunRev has to prioritize adding hooks to them according to a variety of factors, including the number of people who need a given feature. Thus far, for this request that number appears to be two. This is not surprising given that the behavior being requested only ensures that your window will be obscured by any other window that opens - perhaps useful in some very specific circumstances, but not something most developers or their users find desirable, which is why we see so very few applications that use it.

No scripting language can attempt to provide hooks for everything in every OS API, so the good ones provide a means of allowing developers to add any additional functionality they like through an API designed for such extensibility. RunRev provides this in LiveCode with the externals API.

The person who made that request is an experienced developer; in fact his team originally authored the RevBrowser external and others. Perhaps you could contact him to find out if he has an external for this.

As well as this, the ability to create an app bar in windows should also not require an external. It would be incredibly simple to add this function since the Microsoft website explains in great detail how to do it and even has c++, c#, and vb sample code that does it for you. All that needs to be done is to modify that code slightly, compile it, and add it as a window mode. Why is that taking so long to happen?!

What do you mean by "app bar"? Do you mean Ribbon, or something else?

Though I do have some experience with c++, I do not have the capability to create any externals

I though you felt addressing those APIs from C++ was easy, no?

It's been years since there's been any real changes to window functionality. When will we finally see something new in this IDE?

Perhaps you've missed the release notes that are included with every build. You can review them here:
http://livecodejournal.com/features/release-notes.html

Some of the work done since you first started this thread in June includes having rewritten a majority of the 700,000-line code base to become both Unicode- and 64-bit compatible, completely replacing the 2D graphics subsystem, significant progress on the Cocoa transition, reworking the entire rendering subsystem to provide resolution independence, greatly expanding the capabilities of the filter command, expanding the level of control offered by secure mode, revamping text rendering for a 300% performance boost, adding "before" and "after" messages for more robust custom controls - and those are just a few of the highlights, along with many other enhancements and improvements.

As helpful as the release notes are, they only describe changes to the shipping version. RunRev maintains multiple development tracks for the code base, with team members also working on longer-range features of a much more significant scope simultaneous with the builds we see. To get a feel for the full range of work being done, see the Road Map:
http://livecode.com/community/roadmap/

This lack of new material is borderline laziness and is, in my humble opinion, inexcusable. It is about time for a major update if you ask me.

Up to that last line I was trying to be patient in replying to your post. There's no need for such an unprofessional tone; insults are unlikely to deliver whatever productive outcome you may imagine them to.

I've been in the software biz long enough to have seen complaints like that many times, with many products, over many years, and they often have one thing in common: they're most frequently and most loudly voiced by those with the least experience producing anything on the order of complexity of the product they feel so confident insulting.

If managing a project like LiveCode were as trivially simple as you suggest, surely you could prove your point easily by writing just the one external for the specific uncommon window layering behavior you find so lacking.

Please consider taking a moment to review your posts before hitting "Submit". We all have times when we lose our cool, and taking a moment to consider the outcomes of our words can help keep the conversation productive.

LiveCode is far from perfect, and I think even Kevin Miller himself would agree with that. But it's not a simple project to manage, so when we have specialized needs (and as a Linux user I have many myself), we stand a better chance of seeing the changes we're looking for implemented when we apply our energies toward achieving the desired outcome.

In the case of always-on-bottom window layering (please note that always-on-top is already supported), the original submitter of the report has already provided example code. So while that's often a good step to pursue when submitting a request to the database, in this case that's been done for you.

Another option, which may be especially helpful for less popular features like this, is to see if you can either write the functionality yourself, or enlist the help of others who may be able to do that. LiveCode is open source, and indeed many of the enhancements we've seen in recent versions have come from members of the community.

And that's where maintaining a professional quality in our communications here can be most useful: as with most things in life, LiveCode is ultimately about people, the community that makes it happen. While the project is managed by a single company, we all contribute to making it what we want it to be. Some contributions are financial, through license fees or Kickstarter funds, while others contribute code to the project, and still others contribute their time providing support, like the many helpful members of this forum.

You never know when someone reading your posts may be the person most able to help you accomplish whatever you want to achieve.

I meant no insult to anyone by what I wrote, and I apologize if you were offended in any way. I suppose I need to think twice before posting something after having a particularly unpleasant day. If I say something that seems offensive, just try to ignore it.

I was only stating that there has been no changes specifically to window functions (such as "toplevel", "systemwindow", "palette", and so on) that I have seen even since the LiveCode IDE was called RunRev and the IDE I originally obtained from Apple on a RunRev CD when it was only a few years old had almost all of the same functionality with regard to window functions that the current IDE has. Sure many things have changed, but this one aspect has not changed all that much since I have started using this nearly ten years ago. I could be mistaken, but that is how it seems to me.

Something that particularly attests to the long outstanding nature of this feature is that the bug report you linked is from September 2003 -- over ten years ago. The needed OS functions have existed for years before then even, but I haven't seen any attempts to utilize them in all this time.

Sadly, this bug report does not have a link to the DLL mentioned in the report and only contains one entry before the recent edit points back to this forum page. If you know where the original cited post can be found, it would be much appreciated.

My statement that I cannot create externals was not that I do not understand the code required, but that I do not have the proper software installed to handle the needed code (I usually handle c++ using g++ on my linux machine) and that the current external creation process is confusing (in my experience) and files created thereby typically don't function as desired. I will try yet again to see if there is any possibility of making it work as an external. If it works, then I'm definitely posting it on here for anyone to use.

Also, an App Bar is a windows-specific window mode in which a window can be "docked" to an edge of the screen after its rect is established. It effectively modifies the available working space of the screen, acting much like a taskbar or menubar so that windows and icons will be adjusted so as to not cover that space. There is a detailed walkthrough and sample code on the microsoft website explaining how it can be done. This one feature would likely prove much more useful to the average user than the one I have been heretofore requesting. If you still don't know what I am saying, you can look up one example that uses this function called DesktopCoral. I strongly dislike DonationCoder's supposed "freeware" policies, but their program is very effective.

ThatOneGuy wrote:My statement that I cannot create externals was not that I do not understand the code required, but that I do not have the proper software installed to handle the needed code (I usually handle c++ using g++ on my linux machine) and that the current external creation process is confusing (in my experience) and files created thereby typically don't function as desired. I will try yet again to see if there is any possibility of making it work as an external. If it works, then I'm definitely posting it on here for anyone to use.

That would be very cool. You'll see a fella here in the forums named Monte - he's a good resource for any questions you may have about the externals API.

Also, an App Bar is a windows-specific window mode in which a window can be "docked" to an edge of the screen after its rect is established. It effectively modifies the available working space of the screen, acting much like a taskbar or menubar so that windows and icons will be adjusted so as to not cover that space. There is a detailed walkthrough and sample code on the microsoft website explaining how it can be done.

Thanks. That's Win8-specific, yes? I was able to turn up this document about, and I'm sure there are others:
http://msdn.microsoft.com/en-us/library ... 65302.aspx

When you submit the request to the bug database (see the URL above) it may be helpful to include a link or two to some of the more useful resources for implementing it.

I finally broke down and installed Visual Studio so I can work on this. I'm well on my way to creating the desired external.

I already have made a small windows console app that sends a specified window to the bottom using the command line given the desired window's id. It might just work for what I need and when added to the "mousedown" handler it causes the window to be locked to the desktop. If only I can figure out the external creation process I might have something worthwhile to share.

Now I just need to find a way to get rid of the flickering that occurs sometimes.

It seems the "AppBar" window mode has existed even since XP. It isn't all that new.

Well... I tried to build an external again. I followed all of the instructions on the tutorial as closely as I could. It didn't work in the least.

I ended up creating a dll that contained the needed function. No matter what I tried it wouldn't work and nothing ever shows up in the externalFunctions of the stack after setting the external to the newly created dll.

I don't know why making an external is this difficult. I thought that if I actually created the dll and loaded it for use by the program it would operate faster than calling another executable using the command line and would reduce -- or preferably remove -- the odd screen flicker that occurs.

I know that the screen flicker is partly caused by the delay between the system call to advance the window to the foreground and the mousedown message registering that the stack has been clicked. Even using the resumestack message shares the same delay as mousedown.

It would be nice if there were a way to lock the screen in the external executable during the reordering so that it has no visible effect until after it exits. I've looked into it, but there doesn't seem to be much that can help there.

Running another program every time the stack is clicked is also not a very effective method of achieving this goal.

The tutorial might also need some updating since some formatting marks are beginning to destroy the text on that page. Just a heads-up for anyone who hasn't noticed yet.

I finally have a working "external" of sorts.

I now have an better executable that contains only the function I needed. It holds one window to the desktop and remains open until the window is closed or changed so that the window won't advance.

At least there's no more odd flickering, so what I have should be enough for the meantime.

I tried to work on the App Bar as well, but there is very little information about it (mostly just some old, insufficiently explained project from back in Windows' pre-Vista days) and the only good sample code is for the new Windows 8 version, which is not at all what I was looking for.

If anyone is interested, here's what I came up with.

To use it, place the attached file, after extracting it, in the same directory as your livecode file or executable (or change the code below to point to the correct location) and add the following to your code after you get your stack set up the way you want it:
Yes. All of those quotes are necessary if you want it to work every time.

You can test it using the command line (as in Windows' cmd.exe) by passing the number obtained from the message box code "get the windowid of this stack" as a parameter to the attached executable. That way you can at least see the error messages that come up, if any. If everything works correctly, you will only get one message at the end (when you close your stack) to say that it lost track of the process it was watching, after which it will close.

Don't worry. It's not a virus. Avast has locked up my IDE to scan this thing pretty much every time I've tried to use it and it always says there's no problem. I just need to know if it works on more than just my machine and if there are any problems that need to be addressed. As far as I know, it works fine on Windows 7 and takes very little memory (usually 1024 K) and 0% CPU resources.

Enjoy.

Hi,

Later, today, I will test you program under Windows XP.
Right now, I am on Lubuntu Linux.
Did you have used this open source program: SendToBack?

http://www.lx.it.pt/~lbalmeida/sendtoback.htm

SendToBack is a small, unobtrusive Windows 9x / Windows 2000 / Windows XP utility that allows you to control the position of windows on your screen.

With SendToBack you can

Send a window to the back, behind other windows, to uncover them.
Bring a window to the front.
Toggle a window's always-on-top state.
Sending a window to the back can be done by means of the right-hand or the middle mouse button, at the user's choice, as well as by means of a hotkey. The other two actions are performed by means of hotkeys.

All hotkeys can be defined by the user, and can be individually enabled/disabled. Mouse actions can also be enabled/disabled.

Have a nice day!

Al

It might have been useful to know about that, were I not to have an aversion to packaging external utilities built by others along with anything I create -- even if it is open source. If it isn't native, I won't bother with it.

I enjoy using open source programs, but I wouldn't want to need to add credits to another coder's work or use something that likely has much more functionality than I am looking for, including bits I don't know about.

This program sounds interesting, but I wouldn't want it to be possible for the user to disable it (accidentally or intentionally) or need to manually enable it, nor do I want them to even notice that it is running. It should start and work properly without any user input or visual cue, close without any sort of fanfare, and they should only see the effect.

That's just my preference. Thanks for the heads-up though.

I have no idea how my utility will work on anything before Vista. It had a very slight chance of getting caught in an infinite loop, but I believe I fixed that a while ago. It might take quite a bit more resources on XP than on 7, or it could be exactly the same. It all depends on how much window functions have changed since then.