Palette substack blocks answer dialogs

[tomBTG]

Hi Livecoders,

I have a palette substack that often overlays and blocks the dialog windows created by calling the built-in answer command. When this happens, the answer dialog window cannot be brought forward and the palette window cannot be dragged out of the way. The only way out in many cases is to use the Enter key to blindly dismiss the dialog box with the default choice.

Here are two examples:
* A button on the palette substack calls the answer command. Since the calling script is in the substack, the dialog is center under the substack, making it entirely unreadable. Only the margins of the dialog box show. The casual user would not even know there is a dialog box open. And the palette stack cannot be dragged aside.
* In the main stack, a handler with no involvement with the substack calls the answer command. If the substack overlaps the area where the answer dialog will appear (centered in the main stack's rect), then it will overlay the answer cmd's modal dialog box. But because the answer dialog is modal, the palette stack cannot be moved to the side.

This happens in both standalone and IDE modes. Specs: Windows 10, Livecode 7.1.4.

Any workarounds or solutions?

Thanks,
Tom Bodine

[FourthWorld]

LC v7 is many years old. Many refinements have been made with window layering in the dozens of releases since then.

I would suggest trying the latest Stable version, currently v9.0.2:
https://downloads.livecode.com/livecode/

If you still see the problem please note the recipe here, or provide a sample stack illustrating the issue. We'll be able to confirm the issue, identify the scope of affected platforms, and help steward the bug report through the resolution process.

But hopefully you'll find the problem has already been addressed. Please let us know what you find with the current version.

[bogs]

Well, you could try something like

Code: Select all

on mouseDown
   modal stack "{your palette stack}"
   // doing this sometimes moves the stack location...
   put the topLeft of stack "{your palette stack}" into tmpPosition
end mouseDown

on mouseUp
   answer "Hello"
   palette stack "{your palette stack}"
   // make sure the stack is where it left off...
   set the topLeft of stack "{your palette stack}" to tmpPosition
end mouseUp

Other things that come to mind are making your own dialog and setting its topLeft to somewhere of your choosing, like to the right of the palette stack, hiding the palette stack then opening the answer dialog, etc.

*Edit - out of the choices above, myself, I tend to roll my own dialogs and make them modal for the most part.

[tomBTG]

Richards and Bogs,

Thanks for your suggestions.

Tom Bodine

[jacque]

You might tinker with the raisePalletes property. Who knows, it might work. But I agree you're pretty far behind on LC versions.

[richmond62]

you're pretty far behind

LiveCode did a wonderful thing a few years ago: it released an Open Source version.

Therefore the expression "try before you buy" really has become significant.

Heigh-ho over here: https://downloads.livecode.com/livecode/

and download the "latest and greatest" Community version and see if it does the trick;
then rob the bank.

[bogs]

I agree you're pretty far behind on LC versions.

I guess it really is a matter of POV, I think tom is pretty far ahead in versions

[tomBTG]

I'm not coding in the past entirely. I have an Indy license and do build in 8.x on the Mac side, so I can deliver 64-bit standalones. But I put a high value on stability and I've found LC 7.1.4 on Windows will run my codebase with very few issues.

One of these days, however, something is sure to come along and push me off my rock(er).

Thanks for the insights!

Tom

[richmond62]

I put a high value on stability and I've found LC 7.1.4

is, as far as I'm concerned the best version of LiveCode released.

[FourthWorld]

"Best" may be subjective. The v7 series was an experimental bridge on the road to Unicode support, and like many first Unicode implementations it's measurably, sometimes observably, the slowest of any version. And being so old it's missing more than 100 engine fixes and several dozen enhancements, including compatibility with newer OS versions.

[bogs]

"Best" may be subjective. The v7 series was an experimental bridge on the road to Unicode support, and like many first Unicode implementations it's measurably, sometimes observably, the slowest of any version.

When you make statements like this one, I can only guess that you are talking about the end product (standalone) produced, not working in the the actual IDE itself, because there is no way on any hardware you can use or any OS currently supported that the 8-9 IDE is faster to actually work in, more responsive, or more reliable than any IDE previously turned out. There have been improvements in the areas mentioned above, but in comparison visually there is no comparison.

I'd sure be curious if you really find that otherwise, and can explain how.

[FourthWorld]

I noted engine changes specifically.

For personal use it doesn't matter as much, but when delivering software to thousands of end users they don't care about my IDE experience, they care about the software they receive.

Besides, the IDE is scripted, so if I encounter something I don't like I can fix it or replace it, and often do.

Like I said, subjective.

One thing about not using the current version is you will not be able to help identify, report, or fix any issues in the IDE which might have been a reason to use an old version.

[bogs]

I noted engine changes specifically.

Sure doesn't read that way. Even re-reading your post, the 'engine fixes' are mentioned as an additive qualifier, not specifically in relation to speed.

And being so old it's missing more than 100 engine fixes and several dozen enhancements, including compatibility with newer OS versions.

The part of your post talking about speed looks solely devoted to the IDE, which is what prompted the question.

For personal use it doesn't matter as much, but when delivering software to thousands of end users they don't care about my IDE experience, they care about the software they receive.

Understood, again, part of why I asked the question.

Besides, the IDE is scripted, so if I encounter something I don't like I can fix it or replace it, and often do.
Like I said, subjective

I'm sorry, but this is where we start to part ways in the thought process. Users with many years of experience might indeed find and fix things in the IDE where it doesn't suit them, but most people coming to an IDE are not going to either:
be able to do this, or
likely wait around for it to happen.

Your second statement in the last post put it better than I ever could, so well in fact I am going to quote it again -

For personal use it doesn't matter as much, but when delivering software to thousands of end users they don't care about my IDE experience, they care about the software they receive.

I'll start off by saying I have no axe to grind with the company, on the whole I find they do an excellent job of responding to the needs of their end users (us), providing support when asked a question, etc. The following isn't directed at Lc ltd., the team, or personal members of such, it is more a series of observations of a general nature.

Having said that, though, it seems a dis-service to say things like "There were over 100 bug fixes" without alternately mentioning (or flat out ignoring) that other things have become broken, and there will be a trade off in your work flow as you sort the new IDE out. You might want to give up the bugs you know for new shiny bugs that may pop up, not everyone is in that situation.

While I don't develop for my livelihood *now*, there was a time when I did. If I had to fight with my development tools to get something done, I would sure switch over to something I didn't have to fight with. Of course, back then my "IDE" more times than not was a text editor, the fighting came later

Even developing for personal use mostly now, I came here from RB/Xojo specifically because their IDE had become almost completely un-usable in my work flow .

One thing about not using the current version is you will not be able to help identify, report, or fix any issues in the IDE which might have been a reason to use an old version.

That is quite true, and if I have time available I use that to test things out on supported OSes that I personally never run on real hardware, because the current IDE doesn't work very well on the OSes I use, BUT I don't (personally) test them out on my end users.

Just another POV.

[FourthWorld]

It seems we're on the same page. I'm not claiming LC is the only software in history to have become bug free. I'm saying that a "best" version is subjective, based on individual priorities and preferences. You and I do different work, so we prefer different things. It's not that deep.

I rarely touch much of the IDE beyond the Script Editor, using a mix of publicly-available tools. LC is flexible like that. Even without scripting we can replace the Inspector, Project Browser, even the Script Editor using a wide range of free options.

That may explain why the IDE issues others may have an issue with aren't salient for me. IDE users are LiveCode's customers; engine users are MY customers. So I tend to read every engine change log, and report and help triage a good many engine reports, but have little interest in IDE changes.

But for folks who want to use LC's IDE tools yet don't like them and don't want to replace any of them with alternatives they might prefer, even then it's worth noting that fixes outnumber regressions by a wide margin.

All that said, you and I and everyone else here shares the common goal of seeing all elements of the LC experience as close to bug-free as possible, so let's roll up our sleeves and make that happen:

What are the bug report IDs for the IDE issues preventing you from using the current version?

[FourthWorld]

Back on topic, if the OP will post an example stack illustrating the issue I'll happily run it in v9.0.3rc1, released this morning. If the issue persists I'll see if there's an existing bug report and determine what's needed to resolve it, and if there isn't I'll submit one.