bz2012 wrote:I am not really sure what is going on. Many things seem slow. Will advise when I can narrow down further. Thanks for a very useful tool.

WME itself has been very flaky the last couple of days.
This has impacted the loading of URs and PURs.
I haven't had any issues filtering URs in Los Angeles, but I have had to wait a while for them to load.

Twister-UK wrote:one of these days URO/WME will remain stable enough for long enough to give me the time to do stuff like this...

And that's the crux of the matter.
It is frustrating to spend many hours working through the code, and then a WME update loads the next day and breaks it.

It's "iffy" here in LA
For the most part, it works fine, but I had a few times where it would seem to "hang" (as while filters are applied + backfill). I would not be able to get a popup on the yellow URs immediately, but they would generally work after a bit.
There were a couple fo exceptions where they would not pop up until after moving and changing the zoom, funny thing was this was not happening in areas where backfill would have been used.

Ditto... this has been bugging me ever since the popup was moved away from the UR balloon.

james890526 wrote:Hmm, can this time delay be shortened? I seem to prefer the previous version. LOL

I hated it. I run zoom-0 and use the popups to open in a new window. I could somethimes open a UR after 4 or 5 tries, sometimes have to zoom in tighter.

Okay, I think there is a misunderstanding in what the original complaint is.

The problem that I am encountering is when the mouse moves over a UR that is very close to the one selected, URO+ opens the popup for the 2nd UR.
The time delay is not fixing this issue... it is still extremely hard to mouse over to "open in new window" in an area with a lot of URs close together.

A side effect of the increased delay AND the tendency to grab a new UR is that I can click a UR, then when I mouse to the popup to enter a comment, if I pass over another UR, it pops that UR's window up on top of the original information window, and I have to wait 3-4 seconds for it to clear.

I think a fix for this would be to cut the new delay time down by about 75%, but ALSO add a delay time for when the popup appears when mousing over a UR. A short enough delay would not be too noticeable, and it could help prevent the loss of the desired popup.

Moving the popup a bit closer to the UR would help a bit as well. I recall that it was moved away because it was causing problems with URs near the edges of the screen and the popup was overlaying the UR making it impossible to open.

They were doing something to WME yesterday.
I was getting odd things happening with saves all day (only part of an edit was saved, or saved operation would partially revert after the next save...)
Last night I was having issues with new or updated places alternately reverting (or going away) then coming back after a save or refresh, and any saves that involved adding a new junction wwere extremely flaky... Sometimes erroring out, then on resave "they have changed"... then back-arrow through all (40!) edits, hit refresh, and everything is there, so the edit actually did "take"

WME was also running extremely slowly.

+2

Started getting annoying last night.

+1... and the issue that triggered the initial complaint remains.
Preventing fast popup switching is the issue.
Example, two URs that are nearly on top of each other.
Scan to the one on the upper left, you can't get to "open in new window" without the one on the lower right "stealing" the popup.

What would fix this would be either a slight general delay in the popup appearing, or delay/inhibit the popup while another popup is open (not the actual UR comments screen).

Twister-UK wrote:Something isn't right with your setup here, because with the last adjustment I made to the popup positioning relative to its marker, on my test systems the only way for the mouse pointer to "fall out" of the capture region created by the marker and its popup is to take a circuitous route from one to the other - if you move in a straight line from marker to popup any adjacent marker shouldn't be able to capture the pointer and generate a fresh popup of its own.

Also, problem scenarios where same-type markers are this close to one another is exactly what marker unstacking was developed to resolve - if you're not using that then I'd be interested to know why.

I'm not seeing them unstack when the popup is open... but I'm not so much talking about URs that are on top of each other within the "unstack" area, but where one is very close to the original on the right. I'll double check and make sure my script updated, but I got the last two updates where the popup had the long "hang time" and then when it was rolled back.