Does anyone have a SL comment they are using that we might add to URC or the custom comments?

I think it did. I was having that problem yesterday. I haven't been editing today to see if it was a fluke.

ajcadoo wrote:The LA area averages about 50-60 new URs per day. We only have a couple editors here who actively assist in URs, so it's not uncommon to see untouched URs that are months old. We just don't have the ability to process in a timely manner. I'm trying to come up with some simple ideas to try and assist such a heavily trafficked area while maintaining the integrity of processing URs. This idea would by no means be a substitute to investigating. It would just aid in getting information for an otherwise unsolvable UR.

50-60? Let's round that number up a hundred or so.

That said, making it a rank based capability would help. Not sure if champs would support this ability for reasons already mentioned.

SuperDave1426 wrote:Given that UrComments doesn't have anything to do with place update requests, it might be more appropriate as a feature request for URO+, which does do things related to them. Just a thought.

If you're referring to the comments above re disabling auto-centre on URs, then this is something high on my list of things to include in URO+ if I can figure out a way of doing it, because this behaviour really pisses me off. But first I need to fix the newly discovered problem with backfilled URs (no way, another useful add-on feature broken by a WME update, I really can't believe it...) before trying to add in any new workarounds for stuff like this.

Twister-UK wrote:

SuperDave1426 wrote:Given that UrComments doesn't have anything to do with place update requests, it might be more appropriate as a feature request for URO+, which does do things related to them. Just a thought.

If you're referring to the comments above re disabling auto-centre on URs, then this is something high on my list of things to include in URO+ if I can figure out a way of doing it, because this behaviour really pisses me off. But first I need to fix the newly discovered problem with backfilled URs (no way, another useful add-on feature broken by a WME update, I really can't believe it...) before trying to add in any new workarounds for stuff like this.

Done and done You may want to update your URO+ installation if it hasn't already updated itself to 3.59...

HandOfMadness wrote:One problem I've been having, is that after I disable URO+ (or even uninstall the extension), URC keeps telling me that URO+ filters are active. I have to close and reopen the browser for URC to recognize that URO+ isn't filtering anymore. Not a huge deal, but something to look into.

This is just how it is. Originally URC worked out for itself when URO+ filtering was active, by testing the states of all the filtering checkboxes. This worked fine right up to the point where I added a new checkbox or did some other tweak to the code that caused the actual filtering active/inactive state to differ from the inferred state URC was using.

To avoid these problems moving forward, and to avoid URC needing to be updated every time URO+ gained a new filter option, I added a sessionStorage variable which would be constantly updated by URO+ to show its current filtering state, and which URC could then simply read back as and when required - no matter how many changes I made to the filtering capabilities, URC would only need to check that single variable.

The problem you're seeing is that, if you do something outside the scope of the script to stop URO+ from running, without also reloading the browser session, then this sessionStorage variable will stop being updated but will remain present in sessionStorage, where URC will then continue to read it out without realising that URO+ itself is no longer running.

If you just need to temporarily disable all of the URO+ filters, it's preferable to use the master enable checkbox at the top of the URO+ tab next to the script name/version, and if you're uninstalling a script - any of them, not just URO+ - then it's generally good practice to restart the browser session afterwards so that you know any residual effects (e.g. tweaks to the page layout, alteration of other code running on the page etc.) of the uninstalled script have also been removed.

rickzabel wrote:I think I will play around and see if it works with a setting or perhaps I can auto sense the browser size. Maybe a drop down with a bunch of sizes to choose from.

window.innerHeight is a good place to start, though depending on whether the UR edit UI is positioned relative to the whole window or to the map view area you may then need to grab the height of the menu/wazebar in order to work out what the effective window height is as far as the UI element is concerned. URO+ needs to be browser size aware to prevent its popups going off the edge of the screen, so if you're after a bit of inspiration then have a look in uroNewLookHighlightedItemsCheck() to see how it's handled in there.

If you're running that code when the UR marker is clicked (and therefore highlighted), it'll fail with URO+ active because the geometry.x attribute no longer points to the correct location...

To work around the problem where two or more markers are stacked at the same coordinates and WME always opens up the editing panel for the topmost marker even if you specifically request it opens up the panel for one of the underneath markers, URO started allocating unique geometry.x values to the UR markers - this allowed the unstacked markers to be selected correctly, because WME would no longer see multiple markers at the same coordinates.

After WME then started doing its annoying auto-centre thing, it became apparent that this workaround for stacked markers also acted as a way to block auto-centre too, and so I modified URO so that it would always apply this geometry.x adjustment whenever a UR marker was highlighted, even if it wasn't part of a marker stack.

In order to re-enable centering on the UR when the crosshairs icon was clicked in the edit panel, URO also saves a copy of the unadjusted geometry.x value into a temporary geometry.realX attribute, and restores this back into geometry.x whenever the marker is unhighlighted (e.g. when you've moused-over the edit panel). This also means that if you try to centre on the marker via any other means when it isn't highlighted (e.g. clicking on a feed entry for that UR), WME will also be able to centre on it correctly.


So to get your centering code working ok when URO+ is also enabled, what you should do is replace the var x = ... line above with:

rickzabel wrote:

russblau wrote:On the beta editor, I can't post any comments on URs when this script is active. (I changed the permissions manually to allow it to run on beta.waze.com.) All other functions seem to operate OK, but the "Send" button is inoperative. Not a problem on production editor.

[EDIT] Console log shows the following error (every tenth of a second from when I click the Send button until I "x" out of the UR entirely):

Code: Select all

Uncaught TypeError: Cannot read property 'getID' of undefined      VM241:6724 
  uroTSTCommentAddedHandler @ VM241:6724
  uroTenthSecondTick @ VM241:7014

I did not look in to why this error is happening but both of those are from URO not URC.

This is an unrelated bug caused by a change in where the ID for the UR being edited is stored within the edit panel properties, and has now been fixed in the next version of URO...

I have been slow in the process of making a custom list for Switzerland, mainly because I need to translate in 3 languages and had left it on the side a bit. But this AWESOME update just gave me a reason to start again !

Great update thank you !