Twister-UK wrote:Still not able to replicate the problem. If you're using Chrome, or Firefox with the Firebug addon installed, please can you try the following:
In the URO+ tab, click on the script version number - you should see (dbg) appear to the right of this.
Move the mouse pointer over a UR marker which isn't displaying a pop-up
Check the console window for any output starting "URO+:"
For a working UR popup you should see something like this
URO+: UR image type 1
URO+: hover over UR ID 4501693
URO+: checking for marker stack, type 1...
URO+: building popup for UR 4501693
URO+: Livemap link in header menu, locating...
URO+: found link in menu entry 0
URO+: https://www.waze.com/livemap?lon=-0.423 ... 29&zoom=12
URO+: FID mismatch, show popup: 4501693/-1
URO+: display popup at 884,588
PesachZ wrote:Olestas wrote:Do we now name roundabouts?
Not unless they have house numbers attached to them and its necessary for address search results. In most cases we use a round place area with the junction category to provide the name.
Sent using Tapatalk for Android 4.4.2
Twister-UK wrote:Thanks both of you for the PMs, plus the additional info about the use of Toolbox. Unfortunately I still can't see anything wrong - both of your settings files are OK, and I don't have any issues saving Places tab settings regardless of whether or not Toolbox is also running...
Kadyus, so that I'm clear on this - are you saying the problem only occurs for you when Toolbox is running, and that disabling Toolbox allows Places tab settings to be saved OK?
Randyboy, are you also running Toolbox? If so, does the problem go away when TB is disabled?
Both please also confirm which browsers you're using, and which other WME scripts you're running.
Twister-UK wrote:Issue now resolved in dev build... it's another problem with WMETB calling the uroWazeBits() function after URO+ itself has finished with it. Unlike the complete mess this caused previously in 3.20 however, this time around calling the function again merely results in the Places tab being deleted and redrawn, however the saved settings don't then get applied again to this new copy of the tab and so it appears that they were never applied at all.
To avoid any further problems with this, uroWazeBits() in the dev build now contains only those bits of code that WMETB actually does need to run a second time, with all the stuff it really shouldn't have been messing with now moved into a new function called only from within URO+ itself.
SuperDave1426 wrote:PesachZ wrote:You guys should look into [url=j.mp/UrComments]UrComments script[/url] which has presets and works with URO+ to hide certain URs, (once they are both repaired from the latest wme release)
Thanks for the mention of that. I've actually looked into the URO+ presets section of of UrComments. Unfortunately, that still doesn't do what I (and I suspect several others ) am looking for here. There is a preset option there which says, "URO+ New requests / UR replies", which has a tool-tip of that says that that it shows only new URs or ones that have replies from the requestor (which I assume is the driver/reporter using the app). Problem is, that doesn't provide for a restriction of the reporter being the last/most recent comment.
Editor comments, reporter replies, editor replies with further request, no further replies from reporter - that scenario will still trigger it as being visible using that particular UrComment URO+ preset. And in that situation, I don't want the UR reappearing until the time limit has run out and I now need to take whatever further action is warranted at that point.
Thortok2000 wrote:The comments script messed with my URO filters in a very confusing way and I didn't like it. I also couldn't figure out how to create custom comments as I didn't like the defaults. I ended up disabling it.
Twister-UK wrote:Whilst trying to provoke my dev system into showing me the UR conversation bug that seems to have affected just about everyone *except* me,
Users browsing this forum: randyboy