Perspective Popup on Mouse Location (tool tip)

I have some visual elements that visually represent values. The customer asked me to add tool tips to pop up the raw values which I was able to do with a pop up view. The problem is that I can’t find a way to have the pop up appear at my mouse. I can plug in static coordinates but that doesn’t work because those are based on the screen so they don’t correlate to the actual location of the box being hovered.

Is there a way to dynamically bind the popup location relative to mouse location in perspective module?

They’re running 8.03.

Hi Steve,

Unfortunately, there is no straight forward path do doing this in 8.0.3. It is a feature that will be available in 8.0.6, and is currently available in the 8.0.6-RC1.

image

2 Likes

Excellent. Thanks for the prompt response.

I figured there wasn’t a way to do it with the version we are currently running. It’s good to see that it’s coming in a soon version.

Alternatively, using scripting it’s possible with a mouse event like the onMouseOver or onMouseEnter. The event object in those script actions contain a few X/Y coordinate positional variables that you can use for the position parameter in a system.perspective.openPopup() call.
For example,

id = 'a'
view = 'SamplePopup'
position = {'top':event.pageY,'left':event.pageX}
system.perspective.openPopup(id=id,view=view,position=position)

As a note the event object contains clientX/clientY for local coordinates, pageX/pageY for coordinates relative to the document, and screenX/screenY coordinates for global screen coordinates.

3 Likes

This is a great example.

I found encountered a couple of fixable problems that I thought I’d mention in case anyone finds this thread and is having problems.

Sometimes the mouse enter event doesn’t get captured if the mouse is moving fast so you don’t always get a popup in that situation. Of the 2 events you outlined; I found the mouseOver event to be a lot more reliable for getting the popup to appear consistently.

If your mouse cursor overlaps with the edge of the popup and you’re using a mouseOver event it can cause the popup to flicker. This was easily fixed by offsetting the x/y coords passed to the position parameter.

If there are other popups on the page they will sometimes close randomly even though they are indexed under a different ID. I’m not sure why this is happening but I thought you’d want to know about it. I’m using 8.05.

Thanks for your help. The people that asked me to implement tool tips on their app are very happy with this.

1 Like

Were you also using relative positioning of the popup and mouseLeave to close the popup? If so, mouseEnter would open the popup relative to your mouse, but if the mouse is moving slowly or in the direction the popup would open, then the popup would open under the mouse, which means the mouse is now in the popup, which implies it is not in the triggering component, and so mouseLeave would close the popup.

As for closePopup closing popups which don’t match the supplied ID, we’re aware and have an open ticket for this (it’s been around for over a year). The current logic is to look for a match, and if no match is found then close the Popup with the highest z-index.

Yes I was using relative positioning and you are describing the exact behavior I’m seeing on popups so it’s good to see that you’re aware of all of these things.

My only concern with the popup issue is that you’re aware of it. It’s not killing me on any projects.

I’m checking out the 8.06 functionality for relative positioning. It’s great.

I’m still having a problem where pops with rounded corners have a white background behind the rounded corners (like a square popup with a rounded popup on top of it). I’m still looking into that to see if I’m missing a parameter or something.

You’re not missing anything. Popups do not allow for rounded corners.

What you’re seeing is the rounded corners on your View, overlayed against the white background of the Popup <div>. I opened a feature request for this exact design scenario a long while ago but it was closed as something that we would not implement, so don’t plan on rounded corners in Popups in Perspective.

Thank you for the prompt response. It impacts how I design things.

I’m being asked to implement functionality based on a perspective project someone else did but they appear to not have done a fully responsive layout because their “popup” doesn’t have the white borders and it overlays with other things. I think they used a coordinate container to position their “popup” and then embedded a view.

Embedded views do not have the white corner overlay problem.

One problem I’ve discovered with doing this with an embedded view is that they want it to expand/collapse the popup when the user clicks on a hitbox on the container. I can get the expand/collapse functionality by making the popup a breakpoint container with a hitbox that resizes it (triggering expand/collapse) but the hitbox doesn’t work when the popup view is embedded. The hitbox works if it is a popup but I have the white corner problem.

So basically I have to create an invisible hitbox on the screen and have a script on it that changes the width of the embedded view to trigger the breakpoint container. It’s a bit of a kludge but I think it’s what the other people did.

This is hard to explain but I think you’ll understand. I don’t know that any of this is a bug per-se but it certainly is situation-based inconsistency.

That’s not completely true :wink:: I think what cmallonee wants to say is that rounded corners are not officially supported and forcing them is possibly a bad idea and may break in future versions.
But as this is Ignition, a lot of unsupported things are possible. Put the following lines in the perspective css themes (light.css, dark.css):

.client-root .popup {
  border-radius: 25px;
}
2 Likes

Heh, you revolutionary, breaking the rules. (: