If you're using the DrivesTabEnhancer option, please try disabling it and reloading the WME session - I'm seeing random problems with the data returned from the server when DTE is initialising, which is causing the DTE code to get stuck and thus preventing the rest of URO from initialising correctly...

3.43 introduces the following changes:

• Popup now hides itself when the UR/MP/PUR edit panel is opened
• Popup closure timeout is now user-definable (within reasonable limits...)
• Popup is now tucked closer into the UR/MP/PUR marker to aid mouse entry
• Drives data is now retrieved more reliably from server on startup, preventing DTE from stalling
• Segment popup now shows closure data if the Road Closure layer is enabled

I haven't been able to replicate any of the issues noted with the popups sticking, following the mouse around the screen, or any other such oddity, and so no deliberate fixes for these are included - if they're still present please let me know including as much information as possible to help me try and replicate the issue.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

3.44 resolves an issue in the way temporary users were handled by the popup code - instead of them being listed as "undefined" users, you'll now see their numerical user ID.


Slightly more interesting (at least for area managers with more than one managed area) is the arrival of friendly names for managed areas... If you're growing tired of seeing your Areas tab containing "Managed area", "Managed area" etc. leaving you trying to remember each time if you ought to be clicking on "Managed area", "Managed area" or possibly even "Managed area" to get to the area you're interested in, this is for you.

To give a managed area a friendly name (or even an unfriendly one if that's what you'd prefer ), simply hover your mouse pointer over the "Managed Area" text for a short period until a text edit box appears. Click in the box and then, keeping your pointer over the box, type in the name you want to give the area. Once you've finished, move your pointer away to close the text box and store the new name - you should now see the area named as whatever you've just entered, along with a "(Managed area)" suffix as a reminder.

If you want to edit the name, just repeat the process - on areas which already have a friendly name, the text edit box will open up with that name already copied into it. If, for some bizarre reason, you'd prefer to go back to just plain old "Managed Area" again, simply clear the friendly name.


Just a couple of points to note about this feature...

1. Friendly names CANNOT contain commas or colons - if you try to enter either of these characters, they'll be removed prior to using the name.
2. WME doesn't provide any unique ID for managed areas, so URO+ uses the combination of geometric area and server as an identifier for each area. If you happen to have more than one managed area on a server with the exact same geometric area, they'll be treated as the same area for friendly naming purposes. Also, if the geometric area of a managed area changes after it's been renamed, the area will revert to "Managed area" and require renaming.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

Timbones wrote:Can you not just pull the existing friendly names out of Waze.model.managedAreas?

Yes, except that would require some data-wrangling up front in order to fully populate the areas tab with the existing names for each of the users areas - unless all of the users managed areas happen to be located within a fairly small area, it's unlikely that .managedAreas will contain entries for more than one of them at a time.

There's also the point that these names appear to have been allocated semi-randomly by whoever set up the areas, and may not necessarily reflect what the user themselves would like that area to be called - my original area centred on west London has the rather non-descriptive name "United Kingdom", for example... This does however explain why in your car park checking site there seem to be rather a lot of car parks listed under cities/areas which make no sense whatsoever - whenever I click on one of those areas it feels like a lucky dip, never quite sure what you're going to get

Olestas wrote:Hmm, could you please highlight currently selected drive from drives list? It is frustrating to remember, which drive you are currently looking at. Thank you.

Yes, that would be useful. I'll see what I can do...

Thortok2000 wrote:Some PUR's are flagged as awaiting staff review or something. Can those be hidden by the 'ones I cannot edit' filter?

Also, some PURs are like a dark blue while most are pink. What does the color difference mean?

If I can find some examples of such PURs, so that I know what properties are set when they're in this state, then certainly I can add them to the "ones I cannot edit" filter.

The PUR marker colours behave similarly to the UR marker colours - the older and more in need of attention a PUR gets, the darker its marker becomes.

Thanks, that's a big help

Thortok, are the ones you've seen also flagged for staff approval due to ad campaigns, or are they flagged for some other reason? If the latter, some PL's for those would also be most useful.

taco909 wrote:+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).

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.

crayzee wrote:

Twister-UK wrote:3.43 introduces the following changes:

• Popup now hides itself when the UR/MP/PUR edit panel is opened

First of all, IMHO, this feature is unneeded. Even worst, It really annoys me when I need to check consecutive UR from the same user.

Once you've opened the edit panel, you've got native access to the information that the popup contained, so leaving it visible for that marker is somewhat redundant. Also, as was pointed out to me by someone (and the reason I made this change in the first place), if the edit panel opens up over the marker, the popup is then likely to obscure part of the edit panel.

At the time this was notified to me, the only way to get rid of the popup was to then move the mouse pointer well away from the popup, until which time the edit panel and potentially the area of map you needed to edit would be obscured. However it appears that a recent oh so subtle tweak to how WME behaves now prevents this trick from working as well (and may also cause other problems which I'll have to investigate...), so taking out auto-close again would now mean the edit panel being left partially obscured until you close the edit panel, pan the map so the marker is no longer under where the panel opens up, then open the edit panel again... The risk of this happening and preventing the UR from being dealt with at all seems to outweigh the inconvenience of having to close the edit panel before being able to see other popups.


Ultimately, the one thing that needs to be remembered here is that I don't make changes to the way my scripts behave just because I feel like making changes - I'm a firm believer in the "if it ain't broke, don't fix it" school of thought. So when I do make changes like this which affect how the script behaves, potentially to the detriment of how some editors use it, it's because there's a good reason for wanting/needing to make that change. It might not be obvious what that reason is, but I guarantee you that there will be a reason for it.

Also, since we script-writers are working within the confines of an environment we have no control over, trying to hook our functionality, UI enhancements etc. into code that we didn't write, which has the annoying habit of changing without warning (even for those of us who have access to WME beta and therefore ought to know what changes are heading our way...), and which doesn't always lend itself to cleanly enabling what we want to do, then sometimes the only way to implement something in a way which worked in a way acceptable to everyone would be to not implement it at all.

crayzee wrote:Second, I've noticed that on beta it just blocks any popups, even layers menu. Also restrictions popup.
Did someone else also observe this strange behavior?

Not here, everything seems to be working as expected.

3.45 introduces the following changes:

• Popup now hides itself only when the edit panel opens, not whilst the panel remains open...
• Selected drive is highlighted in the Drives tab when DTE is enabled
• Place/PUR popup formatting improved when multiple categories are defined for the place
• Places locked due to advertising are now included in the "Ones I can't edit" filter

Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi