Tooltips don't work if the stack is not active?

[Monox18]

Hello all,

When I open a substack in my mainstack, as palette for example, it becomes the active window. If I place the mouse cursor over any object where I have set a Tooltip it no longer works. I have to click back into the main window (stack), so that it becomes the active window, then the tooltip works again. I have noticed that this doesn't happen with the LiveCode built-in Tools palette, each icon tooltip is working regardless of the active window. The tools palette is also a stack with mode "palette". Is this normal or any idea how to ensure the Tooltip keeps working even when there are other stacks around?

Thanks!

[bogs]

I believe this is normal behavior, and although I have no direct proof of this I think in the IDE they work around it. However, you can use the 'mouseEnter' message to create your own work around (I think, mind you I haven't tested that specifically for this situation, but have used it to get other information from a non active window).

[Monox18]

I was also thinking that is the normal behavior. The mouseEnter for sure works because I have some Hover effects and they still work even in non-active windows. The tooltip thing bothers me just a little, so will probably let it be for now. I was hoping it was just an IDE property. I will figure a mouseEnter workaround later on. Thanks!

[dunbarx]

I made a substack into a palette stack, and the toolTip works fine in a button there.

Interestingly, I could not paste a button I had copied from the mainStack onto a new subStack while it was a palette. I had to change it to a mainStack first. But once the button was resident on the card, I could change the subStack back to a palette, and the toolTip I made for it showed up normally.

So there are things about palettes that one must know about. I think this makes sense, because palettes are not first class citizens compared to mainStacks. They are intended to be adjuncts. The pointer tool does not even stick when the cursor is over a palette.

So what kind of control did you add the tooltip? When did you add it?

Craig

[FourthWorld]

Interestingly, I could not paste a button I had copied from the mainStack onto a new subStack while it was a palette.

The pointer tool only acts on toplevel stacks. Since LC's tool mode is global, this makes it possible to have toolbars, tool palettes, and other auxiliary windows that are common in apps that provide layout tools, like a drawing app or the IDE.

[FourthWorld]

Monox18, i believe what you're seeing is normal, or at least the most common convention at the time tooltips were added to LC.

If you find that a majority of apps that offer tooltips have them active in inactive windows, we can consider changing that.

The implications of window focus can be tricky to apply to uncommon circumstances. Normally tooltips are provided to describe an action button, so the user can have additional information to decide if they want to click.

If the button is in an inactive window, is rare that the user's attention would be focused on it.

Can you tell us a bit more about the context, and what information your tooltips provide? I'm sure we can find a good solution once we have a class clear understanding of the design.

[bogs]

Interestingly, I could not paste a button I had copied from the mainStack onto a new subStack while it was a palette.

The pointer tool only acts on toplevel stacks. Since LC's tool mode is global, this makes it possible to have toolbars, tool palettes, and other auxiliary windows that are common in apps that provide layout tools, like a drawing app or the IDE.

I found it more interesting that you can right click on a mainstack, and change it to any other type, but you can't do the same in reverse if it is a palette heh. Richard's explanation certainly covers that, however, and you can reverse it from the project browser (or message box, if in an older version).

[dunbarx]

Richard. I mentioned earlier:

The pointer tool does not even stick when the cursor is over a palette.

Anyway, I find it odd that I can neither create nor even paste a control into an existing palette stack. I would imagine that a significant use of palette stacks is to present the user with a "toolbox", always on top of other windows, with properties or whatever to be selected so that the maniStack(s) can continue forward.

But one must build such a stack at topLevel, and once ready, palettize it. The OP could not assign a toolTip to an existing palette, though I am still not sure of the circumstances. But I would think that palette stack gadgetry might most benefit from toolTips, assuming my "toolbox" description makes sense.

I never use palettes. All my projects, apart from a single large one that I make into standalones for my Windows machines, run in the IDE. This is just for reasons of easy accessibility to manage them. What is the rationale, in the IDE, ostensibly a development environment, of limiting the tools available to author such a stack?

This is a purely academic question.

Craig

[FourthWorld]

I found it more interesting that you can right click on a mainstack, and change it to any other type, but you can't do the same in reverse if it is a palette heh.

Or you can use the DeskView utility included with devolution, where just double-clicking the window proxy will toggle any stack between whatever style it's set to and toplevel.

devolution can be downloaded for free here:
http://fourthworld.com/products/devolution/

[bogs]

Well yes, but of course I was speaking to the IDE as delivered which is how most beginners would use it

As to the actual question that the OP posted, I found you can use a stack to simulate a tool tip in a mouseEnter handler.

I set the stack that will replace the tooltip background to the appropriate yellow, put a field (no border / no opaque / locked text etc) on the card, and entered the following:

Code: Select all

-- in a buttons script where you want to see the tooltip...
on mouseEnter
   popup stack "tipper" at the loc of the me
end mouseEnter

No matter which window / palette / etc had the focus, the tip displayed. I'll leave making it go away up to you.

One way to fake it...

[FourthWorld]

Well yes, but of course I was speaking to the IDE as delivered which is how most beginners would use it

Of course. Yours was the right answer.

I was just dropping a reminder of the breadth of things others in our community have typed, so if they find themselves typing the same thing over and over and they think "I'd really like a tool for that", their next thought can be "and I know where to find it."

[Monox18]

About context: I am designing a kind of GUI "tutorial". basically a Help stack and an Arrow stack pointing at different controls and giving information. As the user clicks around, those two stacks move to different controls of the mainstack. Similar when you open an app for the 1st time and you have a quick run tutorial to get started. Just explaining few components by steps. As components are clicked, the help and arrow disappear and reappear with close/open stack commands. So the active windows is changing back and forth between every step. I suppose this focus change happens because I open and close the stacks with each confirmed step. Maybe using show/hide stack commands would keep the focus on the mainstack instead.

I normally use tooltips to put the name or title in an Icon only button. So if the user hovers the mouse over an icon, the tooltip shows the name, same as the LC Tools palette where all icons only have tooltips and not labels.

Thanks for the answers guys.

[FourthWorld]

What is the rationale, in the IDE, ostensibly a development environment, of limiting the tools available to author such a stack?

All tools are available to all stacks. Indeed, if that weren't the case it wouldn't be possible to make the tool palettes we're discussing.

The question is WHEN those tools are available.

Tools other than the Browse Tool are only available when a stack is toplevel. This is appropriate because it allows us to deliver apps that provide drawing environments, and toplevel is effectively a document mode.

Set the stack's style to toplevel to work on it, set it to anything else to use what you've produced. If it's a tool palette, set its style to palette; if it's a Prefs window, set it to modeless; if its a dialog, set it to modal.

Modes are not just a key part of LC, nor even xTalks in general, but of GUIs.

Consider a button: when you click it, how do you want it to respond? Do you want to press it to trigger its script, or do you want to select it to resize it?

Both are possible, but not at the same time. We change the tool global property to change how we interact with controls.

Similarly, we change a stack's style to change how we interact with it.

Have you ever seen a drawing program that let you draw inside its tool palettes? Or in dialogs? Or in its Prefs window?

LC offers several tool modes and several window modes. We can switch between them to deliver apps that look and feel like those we use from other vendors, per the guidelines established by the OS.

[richmond62]

We can switch between them to deliver apps

Well, Duh, Yes; and only very very "virginal prawns" are unaware of what you stated: almost a truism.

However, those hard-and-fast divisions may not always be relevant, and a really top-notch IDE/GUI/What-Have-Ye
should allow developers to be able to tweak and/or completely trash those divisions if needs be.

When I went to school we called all our school masters 'Sir', and as that was a 'cork-up-your-bum' sort of school
it may have served some purpose (mainly to keep up fellahin down the bottom), but now, in my EFL school,
in a different century, a different country, and an entirely different educational environment, I have
my pupils call me by my first name.

Now, while I am 58, and fairly fossilised in my ways
-

-
I do recognise both a need to move with the spirit of the age,
and a need to trim one's gas wick to the lighting requirements that are relevant
to a given situation.

[FourthWorld]

All you wrote is true and worth pondering. The pioneers of GUIs struggled with the concept of modality, and still debate it to this day.

Is it limitation or focus? Is it restricting or guiding? Is it simpler to switch modes or ask the user to memorize whatever incantations may be needed to do very different things with one object?

These are important questions, not easily answered.

I like to believe a GUI toolkit like LC is flexible enough to lend itself very well to the types of research that can refine those answers.

And there's almost always a way to get what you want with a little scripting.

Out of the box, LC's design aims for supporting common multiplatform conventions.

But it can be tweaked to do a lot more, as this thread shows.