Mouse Position Troubles, Again

[DaveLClarkI]

I had a previous thread where I was having trouble positioning a pop-up menu based on the current mouse position:

http://www.profoundlogic.com/forum/view ... =53&t=1599

That issue was resolved by combining information from the getMouseX() and getMouseY() API's with some pui.runtimeContainer properties. However, keeping the same code, I'm finding that though it continues to work for the main page, it doesn't work for a pop-up window which is displayed over that page.

I have this function for extracting everything I would want to know about the dimensions and position offsets of the browser page, the browser client area, the PUI runtime container, and the mouse position.

Code: Select all

/*	================================================================================
	getContainerOffsets()	dynamically removes the designated grid column and adjusts
						the width of a remaining displayed grid column to include
						the width of the column that was removed.  This is so that
						the overall width of the grid remains the same.  Conversely,
						if you do NOT want the width of the removed column added
						back in to the overall grid width, then just specify -1 for
						the adjustment column.
*/
wob.getContainerOffsets = function(event)
{
	var offsets = wob.browserPageOffsets();		// get scrolled offset of page
	offsets.client = wob.browserClientArea();	// get client area of page

	if (event)
	{
		offsets.mouseLeft = offsets.left + getMouseX(event);	// set mouse coordinates
		offsets.mouseTop = offsets.top + getMouseY(event);

		offsets.mouseLeft -= pui.runtimeContainer.offsetLeft;	// adjust for Profound's outer container
		offsets.mouseTop -= pui.runtimeContainer.offsetTop;
	}

	offsets.left += pui.runtimeContainer.offsetLeft;	// adjust for Profound's outer container
	offsets.top += pui.runtimeContainer.offsetTop;
	offsets.width = pui.runtimeContainer.clientWidth;
	if (pui.runtimeContainer.clientHeight > 0)
	{
		offsets.height = pui.runtimeContainer.clientHeight - pui.runtimeContainer.offsetTop;
	}
	else
	{
		offsets.height -= pui.runtimeContainer.offsetTop;
	}
	
	return offsets;								// return offsets to caller
}

I've included two snapshots -- where the first shows the pop-up menu on the main page:

main page

snap1.png (36.32 KiB) Viewed 1520 times

...and the second shows the pop-up menu on the pop-up window over that page.

pop-up window

snap2.png (45.25 KiB) Viewed 1520 times

In both cases, I left-clicked on the icon shown in the first grid row and I call the following function from the onclick event of that icon.

wob.showOptionsMenu("mnuSelect", event);

Code: Select all

/*	================================================================================
	showOptionsMenu()	positions an invisible menu widget at the current mouse
						position and then makes the menu visible.
*/
wob.showOptionsMenu = function(menuId, event)
{
	var offsets = wob.getContainerOffsets(event);	// get page and mouse offsets

	applyProperty(menuId, "left", (offsets.mouseLeft - 5) + "px"); // position the menu
	applyProperty(menuId, "top", (offsets.mouseTop - 5) + "px");
	applyProperty(menuId, "z index", 200);			// put menu on top of everything
	applyProperty(menuId, "visibility", "visible");	// make menu visible
}

Now, as I said, this is all working perfectly when operating from just the main PUI page. How do I have to adjust any of this code to make it also work when operating from a PUI pop-up window which is displayed over that main PUI page?

[David]

The problem here is very similar to your original question on this.

Before, the menu was appended into the 'pui.runtimeContainer' (the main 'pui' div), so you needed to adjust the mouse coords (which are relative to the whole screen) when positioning your elements, as the element positioning is relative to the 'pui.runtimeContainer'. But, window record formats have their own containing <div> element (which is itself absolute positioned) where all the widgets are rendered into. This is what allows you to pick it up, drag it around, etc.

You should be able to get a reference to the window <div> by looking at the menu dom element's parent node. Like this:

Code: Select all

  var prt = getObj("myMenu").parentNode;

You could determine if the menu widget is in a window like this:

Code: Select all

  var menu = getObj("myMenu");
  if (menu.parentNode != pui.runtimeContainer) {

    // Must be in a window...

  }

Using 'parentNode' like this will break down, unfortunately, if you put the menu widget into a layout/container, as this will change the parent node. Some containers have multiple nested elements, you'd have to loop through them to calculate positions, it gets a bit tricky. You could avoid all that by simply not placing the menu widget in a layout container. Since you are showing it at the mouse cursor position, I don't think you would really want/need to put it into a container, anyhow.

Once you know that the menu widget is rendered into a window, I think you'd just need to subtract the 'offsetTop' / 'offsetLeft' of the window div to get the right position from the mouse coords.

[DaveLClarkI]

Got it. I'll try it out.

[DaveLClarkI]

Well, turned out it was not quite as simple as just that. What I ended up having to do was to chase the offsetParent tree and add up all the offsets in order to finally come up with the correct value for the mouse's offset position. That looks like this:

Code: Select all

	var ele = container;   						// starting from the container
	do					   						// calculate container's offsets
	{
		offsets.left += ele.offsetLeft;				// include left offset
		offsets.top += ele.offsetTop;				// include top offset
	}
	while (ele = ele.offsetParent);				// which includes all offset parents

Then, calculating the correct mouse offset was as follows:

Code: Select all

	if (event)									// if an event object was included
	{											// then set offset for mouse coordinates
		offsets.mouseLeft = getMouseX(event) - offsets.left;
		offsets.mouseTop = getMouseY(event) - offsets.top;
	}

So, my function changed as follows in order to pass the container object:

Code: Select all

/*	================================================================================
	showOptionsMenu()	positions an invisible menu widget at the current mouse
						position and then makes the menu visible.
*/
wob.showOptionsMenu = function(menuId, event)
{
	var parent = getObj(menuId).parentNode;			// point to container for menu
	var offsets = wob.getContainerOffsets(parent, event);	// get page and mouse offsets

	applyProperty(menuId, "left", (offsets.mouseLeft - 5) + "px"); // position the menu
	applyProperty(menuId, "top", (offsets.mouseTop - 5) + "px");
	applyProperty(menuId, "z index", 200);			// put menu on top of everything
	applyProperty(menuId, "visibility", "visible");	// make menu visible
}

Thanks.

[DaveLClarkI]

Hmmm... Ran into a problem with the container that Profound UI creates for the pop-up window. Although the menu positioning is working fine, I'm having problems trying to display my dynamic informational message box within that container. The reason is because the container for the pop-up window has the following dimensions:

clientHeight: 2
clientWidth: 2

offsetHeight: 2
offsetWidth: 2

scrollHeight: 402
scrollWidth: 731

When adding a new HTML element to this container and then going through the calculations to position it, what I am ending up with are negative top and left offsets because the container's offsetHeight and offsetWidth are so small.

Why are the client and offset dimensions incorrect for this container?

[David]

They are not incorrect, the measurements you have there are accurate. :-)

When Profound UI renders the window, it appends this <div> into the DOM and does not give it a fixed size. So it's basically zero tall/wide to start with. If the content that is rendered within were using normal HTML flow positioning, the window <div> would increase in size to accommodate the content within. Since Profound UI widgets are using absolute positioning, the window <div> does not expand. That is has any reported size at all is due to padding, I think, that is assigned to all <div>'s in the 'profoundui.css'. The browser does not clip overflowing content by default, so your widgets are still visible, even though they are technically overflowing from the <div>.

So the window <div> is really just serving as a container to put the elements into, so that the window be rendered into different positions (there are properties to control it), picked up by the user, dragged around, etc., and all the widgets rendered into it move along with it. We don't size the window <div> simply because it's not necessary for our purposes -- it's invisible, and it doesn't usually matter how it's sized at all.

Why is the width of the window coming into play here? I guess you trying to make sure that your info box doesn't extend beyond the edge of the window, or maybe you are trying to center it in the window?

I think you may want to look at the width of the panel in the window, instead, as this is really what visually delineates a window.

Does that help?

[DaveLClarkI]

No, it doesn't. But, I figured that was going to be the answer and I knew I wasn't going to like it when I heard it. Yes, the problem has to do with centering and "right" positioning. No, I can't look at a panel in the container -- for two reasons: there doesn't have to be a panel in the container and generic code to get the dimensions of the container isn't going to and shouldn't have to know anything about the content of that container, anyway. I was already fudging the runtime container's height: which was coming back as zero. So, I'll figure something out in this case, too. Zero would have been easier in this case.

[David]

Sorry.

The runtime container is probably not given a set height in your skin, this is why it comes back as zero. Probably the styling in the skin takes the padding off that you are seeing on the PUI window divs. Again, the reason that might not be given a set height is that there is not a general need to do that in Profound UI, due to absolute positioning and default overflow behavior of the browser.

I do understand about not wanting to look at a panel for this type of coding, but I think in a window you would typically have one? This is what provides the visual of a window in Profound UI, without a panel, you'd have the record format just kind of floating on top of the main screen with background bleeding through and all that.

Profound UI was just not designed to give the area of the record format itself any visual 'substance', this comes from the widgets.

I know that we do have internally some functions which calculate the effective 'visible box' of a record format. Or maybe this works on the entire screen. I could check to see if this is available for your use, it might help you to do what you want.

But, in the end this effective 'visible box' is really going to be the size of your window panel, anyhow...

[DaveLClarkI]

An API to return the effective size of the container would be great. In the meantime, I just have to figure out how to coordinate using the offset area or the client area. Like I said, seeing a zero would have made this easier; but, I'll figure out something.

[Alex]

It looks like we do have an API for this already. See here: http://www.profoundlogic.com/docs/displ ... tainer+%29.