Jump to content

Update: Release Notes 1/12/10


OpinioNate

Recommended Posts

At a guess I'd say you're running the query, checking for the number of caches, and only then applying the filter.

 

This is not a bug introduced by this latest release, but a request for a change in the way this feature was implemented. Please keep this thread focused on issues with the latest release. Thanks!

The site is reporting finding more than 500 caches, when in fact there are only a few or, in one case, none at all. I'd class that as a bug; whether it was introduced in this release I can't say as I'd never noticed it before.

Of course if it's working as designed then it's a feature and not a bug.

I don't want to see this turn into a debate on this "bug" in this thread, because it has nothing to do with this release. But just to clarify... rightly or wrongly, the query that finds the 500 caches is apparently done first, and that result set is then filtered by what you have checked, not the other way around.
Link to comment

I'm very surprised that nobody has mentioned this yet. Many times, a cache listing page fails to display any more than just the header box until I refresh the page one or more times.

 

 

Using IE8 on XP, experienced on two computers. The browser shows this error:

 

 

Webpage error details

 

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)

Timestamp: Thu, 21 Jan 2010 15:50:47 UTC

 

Message: HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917)

Line: 0

Char: 0

Code: 0

URI: http://www.geocaching.com/seek/nearest.asp...;lng=-78.909850

 

Link to comment
In the software universe there comes a point where each developer/publisher must make the hard choice to stop supporting a particular version of a particular program. It would appear that GS has made the decision to stop supporting IE6 after neary 10 years. ...
Have TPTB actually stated this or is it being assumed? This thread is about bugs, after all. It is fair to ask whether the loss of IE6 functionality is a bug.

OpinioNate has stated in another thread that Groundspeak is not discontinuing support for IE6.

 

--Larry

Thanks
Link to comment

The site is reporting finding more than 500 caches, when in fact there are only a few or, in one case, none at all. I'd class that as a bug; whether it was introduced in this release I can't say as I'd never noticed it before.

 

Of course if it's working as designed then it's a feature and not a bug.

 

 

The feature was designed this way from the outset for performance reasons, although I agree that in practice it is less than ideal.

Edited by Moun10Bike
Link to comment
I'm very surprised that nobody has mentioned this yet. Many times, a cache listing page fails to display any more than just the header box until I refresh the page one or more times.

 

This is a known issue that I've added to the initial post in this thread and that I believe might be responsible for the issues being discussed in this thread.

Link to comment

Hi

 

When I printed the map page BEFORE the update it would print the map and the "Premium Members Filters:" tick boxes would print to the right of the map. :P:angry::)

Since the update the map prints as before but NOW I get the "Premium Members Filters:" tick boxes over top the of the map. B):):smile:

 

FYI At least I managed to print out both the Map and the Satellite.

 

Using IE8

Link to comment
I'm very surprised that nobody has mentioned this yet. Many times, a cache listing page fails to display any more than just the header box until I refresh the page one or more times.

 

This is a known issue that I've added to the initial post in this thread and that I believe might be responsible for the issues being discussed in this thread.

OK, thanks. Didn't sound like the same thing to me. For what its worth, both Firefox and Chrome seem to work just fine in that regard. You asked in the other thread about Anti-virus. At home I'm using AVG and Malwarebytes, at work they run Symantec, so I'm guessing AV has no bearing on it.
Link to comment

Another bug, again apologies if this has been reported before.

 

Zooming out on the Geocaching Maps page I get the message "Your search exceeded 500 caches". That's fine if the search did return that many, but at the time I was filtering by Earthcache and there are only about 2 or 3 in the area.

 

In fact if I remove all cache types from the filter, and would therefore not expect to get any caches back, I still get the "exceeded 500 caches" message.

 

At a guess I'd say you're running the query, checking for the number of caches, and only then applying the filter.

I'm not sure if that's a Bug, it has always happened. It is annoying though, and I hope they can change that at some point. It really gets me whan I'm in an area, and zoom out looking for Events, I ususlly can't zoom out that far before I hit the block. I guess I'm supposed to use PQs when I want that info.

Link to comment
This 'Ignore logs before 1/1/0001 6:00:00 AM' problem persists. I've uploaded Field Notes on several different days and it stays the same. My cache is dumped after each session!

 

The checkbox will reset whenever you delete field notes (as opposed to "converting" them into logs). Is there any chance this is what is happening in your situation?

I suspect my reply will help answer your quesion.

 

For me, I can't convert them all into logs because they are already logged without using the field notes option (before I knew what field notes were).

I did, once, delete them one at a time (there were about 300 of them to delete) through the website and the next time I went to upload field notes they ALL imported again because I wasn't able to set the ignore date.

 

But, yes, this was not something that occurred in the latest release. It's always been this way

Link to comment
For me, I can't convert them all into logs because they are already logged without using the field notes option (before I knew what field notes were).

I did, once, delete them one at a time (there were about 300 of them to delete) through the website and the next time I went to upload field notes they ALL imported again because I wasn't able to set the ignore date.

You should delete the geocaches_found.txt from your Colorado - or rename it to something else - after you've uploaded your field notes.

Link to comment
For me, I can't convert them all into logs because they are already logged without using the field notes option (before I knew what field notes were).

I did, once, delete them one at a time (there were about 300 of them to delete) through the website and the next time I went to upload field notes they ALL imported again because I wasn't able to set the ignore date.

You should delete the geocaches_found.txt from your Colorado - or rename it to something else - after you've uploaded your field notes.

Yes but if I name it something else then I can't see the open treasure chests when I'm out with someone who hasn't found caches that I've found. I would either see the closed chests or I won't see an icon at all. Pretty hard when I'm playing navigator if I don't have the chests, and a pain if I have them closed.

 

There is a method to my madness.

 

(I know this isn't the place to say this but... why not just make it eidtable from the get-go with a default to the beginning of time?)

Link to comment
Yes but if I name it something else then I can't see the open treasure chests when I'm out with someone who hasn't found caches that I've found. I would either see the closed chests or I won't see an icon at all. Pretty hard when I'm playing navigator if I don't have the chests, and a pain if I have them closed.

Interesting. The Oregon still shows open treasure chests when the file is deleted, the found state is stored elsewhere. geocache_visits.txt is write only on the Oregon.

Link to comment
Yes but if I name it something else then I can't see the open treasure chests when I'm out with someone who hasn't found caches that I've found. I would either see the closed chests or I won't see an icon at all. Pretty hard when I'm playing navigator if I don't have the chests, and a pain if I have them closed.

Interesting. The Oregon still shows open treasure chests when the file is deleted, the found state is stored elsewhere. geocache_visits.txt is write only on the Oregon.

 

Well, I'm using my Colorado IN Oregon. Even that doesn't seem to help.

 

Try overwriting the file the caches are in.

There is a file called "current.gpx" (I think) that temporarily stores the found it/not found state of caches in addition to the geocaches_visits.txt

Once you load a new GPX PQ file and reset the unit, you should see that the open treasure chests are gone.

Edited by bittsen
Link to comment

I have not had an opportunity to read all of the bug posts since the update but when I update cache attributes, the attribute images in the first column on the page do not change based on the radio button chosen.

 

For instance, when I select "Allowed" for dogs, the image does not show it's allowed. It stays grayed on the page. For an attribute that was already selected for a cache, changing it to N/R does not make the image gray out. Changing it to not allowed doesn't make it appear not allowed.

 

I thought the attributes used to work in this way. Perhaps I just dreamed this? (if so, consider this a feature request ;) )

 

Using Firefox 3.5.7 on Vista.

Link to comment

I had posted this note as a new topic, and then my husband noticed this thread to report problems, so I'm copying my first post here:

 

I may be old-fashioned, but I like to print out the Google map, with the caches numbered on it, and a list of the caches so we can drive more efficiently from one to the next when we're on a geocaching run. Now the Google map will only print as a full page map, and the list of caches, shown to the side with the ID numbers on the webpage, leaves out the top part of the list when printed. This is frustrating, and I hope it can be fixed to print out the page as you see it on the website, as it used to print. I have tried on two browsers, so I don't think it's a browser problem.

Link to comment

Just wanted to post this again...still not fixed, and I think it might have been missed in the bickering that's not supposed to happen in this thread.

Oops, started another trhread for this, but it probably belongs here???

 

afced375-5194-4b44-84ec-62cf0d43f88a.jpg

 

Didn't happen until after the adoption.

I also see same problem on these Bugs...

 

http://www.geocaching.com/track/details.aspx?id=2462234

 

http://www.geocaching.com/track/details.aspx?id=2169078

 

 

 

is the problem throughout the site???? Logs are showing in a layer OVER the TB image.

 

 

It doesn't seem to occur when the text is enough to allign with the image, only when the text is less that the size of the picture.

 

http://www.geocaching.com/track/details.aspx?id=1235076

 

 

OK, so looking at several of my TBs that have images uploaded for the description, it appears that there is no consistancy in the placement of the image on the Bugs page?? What's up with that, shouldn't the image be in the same place every time?

Link to comment

Just wanted to post this again...still not fixed, and I think it might have been missed in the bickering that's not supposed to happen in this thread.

 

Your issue wasn't missed - I had added it to the known issues in the first post. However, you won't see it fixed until thde next release of the site.

Link to comment

When I try to edit cache descriptions with scandinavian letters it is almost impossible as letters have became cryptic.. Can't explain more just look at the image. Everything with ä etc. are wrong. I have tried this in IE 8.0.6... and FF 3.5.6. Very annoying problem.

 

I'm using Safari 4.0.3 and have the same problem, I don't think this problem is browser-related. It really makes editing listings quite impossible wihout a separate HTML-editor. This bug also destroyed my short description, as short descriptions are limited to 500 characters and now as every single ä, ö and å are replalced by this auml-stuff it makes the description much longer and the text just doesn't fit.

 

Please fix this.

Edited by tamasochi
Link to comment

I apologize if this issue has been reported and acknowledged already but I'd still like to see a reply even if it has; 8 pages of posts to scroll through you know.

 

I noticed on a cache that I just published (GC22XHD) that the "See the History" link is not present in the inventory window. Is this an intentional design change, if so, why? It was a nice feature that is useful if you are trying to track down a missing bug or coin, among other things.

 

I posted this problem in the TB forums as well as a seperate thread in this forum and a couple of people noted that the see the history link is present with no bugs in the inventory or one but for two or more it is not. sorry for the triple post but I wasn't sure where I should put it.

 

Thanks

FM

Link to comment

Regarding the image captions for the attribute symbols - I think I figured out why the caption not longer pops up for me when my cursor is over the image (I use Firefox for my browser).

I just found that it does still work in IE, but not in Firefox, and it's because of the HTML coding for the images. alt="xxxx" only works in IE and not in Firefox. In the pages I write I also use title="xxxx" so it will also pop up in Firefox.

 

So, each tag needs to be revised from

<img src="/images/attributes/scenic-yes.gif" alt="scenic view" width="30" height="30" />

to say

<img src="/images/attributes/scenic-yes.gif" alt="scenic view" title="scenic view" width="30" height="30" />

 

I find the attributes of a cache to be very helpful, and hope this small correction to the new version can be implemented.

Link to comment

A minor note for the GC crew.....

 

On event pages when you go to the drop down box on the logging page and it's default setting is "ATTENDED" instead of "SELECT ONE" which now appears TWICE in this box.

 

Before an event all of the entries are usually a simple WILL ATTEND or WRITE NOTE in regards to TB drops, RSVPs, etc.

 

ATTENDED notes are a "once only" type of note and shouldn't be placed so high in priority on the drop down box list.

 

The original order worked well and I believe it was:

WRITE NOTE

NEEDS ARCHIVED

WILL ATTEND

ATTENDED

 

Thanks for reading and I know you guys are working HARD to fix all the little things.

 

Regards,

n6uzs

 

Which is the very reason that I stopped by the forums today!

Never have I seen people 'attend' an event before it has even been had and yet twice now, in my one event that I expect 20 people to show up, they have chosen 'Attended'. I let one person know about it and just realized that another has done the same thing.

http://www.geocaching.com/seek/cache_detai...1c-8d8c6ac298db

Now I see why. What I came to suggest today was that the 'Attended' not be available until the day of the event but maybe it could be fixed with what n6uzs is suggesting.

On another note, and I'm afraid to say after reading about 'Trolls-r-us'...it stinks. I'm not a computer junkie but when I use my mouse to scroll down the 'Hide & Seek' a cache page, the screen messes with my eyes. The width of the text and/or page size fluctuates as if its on a diet then off a diet. When logging a cache, I scroll down to the 'Submit' button using the wheel on my mouse and I have to navigate around the 'Trackables' box because there is a dead spot there and it quits scrolling (Can't wait to drop that trackable in a cache somewhere).

 

XP Pro

IE8

Plain Jane, two button mouse with a scroller between them

Link to comment
Apparently I have another bug to report. Amazing since Im not uber tech savvy like you all are.

 

I went to log a cache we found on Wed Jan 20th. It is after midnight and officially Jan 21. All previous times Ive logged caches after midnight, the date shows the next day's date and I have to manually change the date. Tonight it didnt do that. The default date when I went to log my cache showed up as yesterday's date even thought it was after midnight. This is not something the site has ever done before. I did not post any other logs so that isnt why the default date was the 20th.

 

If it matters, I have WinXP and Firefox.

 

This is a known issue and we hope to have it corrected for the next release.

Please don't do that. I believe this behavior have changed back and forth in other releases ending with the way it is now. Moun10Bike, could you look into the history of the way this works before changing it again.

 

The logic behind it being if you log your caches from a multi-day trip then you only have to change the date once for each day of the trip that you found caches on. Otherwise you would have to change the date for each and every cache that you log.

 

I prefer the way it is sticky now, it's probably handled by a cookie that times out in a mater of hours or only works in the current session.

 

ProsperoDK/René

Link to comment
Apparently I have another bug to report. Amazing since Im not uber tech savvy like you all are.

 

I went to log a cache we found on Wed Jan 20th. It is after midnight and officially Jan 21. All previous times Ive logged caches after midnight, the date shows the next day's date and I have to manually change the date. Tonight it didnt do that. The default date when I went to log my cache showed up as yesterday's date even thought it was after midnight. This is not something the site has ever done before. I did not post any other logs so that isnt why the default date was the 20th.

 

If it matters, I have WinXP and Firefox.

 

This is a known issue and we hope to have it corrected for the next release.

Please don't do that. I believe this behavior have changed back and forth in other releases ending with the way it is now. Moun10Bike, could you look into the history of the way this works before changing it again.

 

The logic behind it being if you log your caches from a multi-day trip then you only have to change the date once for each day of the trip that you found caches on. Otherwise you would have to change the date for each and every cache that you log.

 

I prefer the way it is sticky now, it's probably handled by a cookie that times out in a mater of hours or only works in the current session.

 

ProsperoDK/René

 

Yes don't do anyting! you don't realize the benefit of it keeping the last date. You just have to pay attention. When logging large numbers of caches, and logging them late like I have a bad habbit of doing, this is a real life saver! yes, it is session based in the current browser. Why not try closing your broswer each time you log a cache, that will fix your problem, but will induce a lot more clicks and key strokes than it takes to just change the date. "Freeze, Step away from the keyboard" :( MR

Link to comment

I have some links like this:

http://www.geocaching.com/seek/cache_detai...0&decrypt=y

(hover over the link to see the full URL in the status bar). The map on the page now is overwritten with logs when using Firefox 3.0.14. I am aware that this is not the case with the links to the new print-friendly pages and I can switch to that. But I do like this version and would prefer to stay with it, if it is still supposed to be in the web page. I have the sense that this defect did not exist prior to the current release.

Link to comment
The default date when I went to log my cache showed up as yesterday's date even thought it was after midnight. This is not something the site has ever done before. I did not post any other logs so that isnt why the default date was the 20th.
This is a known issue and we hope to have it corrected for the next release.

The logic behind it being if you log your caches from a multi-day trip then you only have to change the date once for each day of the trip that you found caches on.

you don't realize the benefit of it keeping the last date.

Emphasis added. I'm guessing it's timezone-related instead.

Link to comment

I have some links like this:

http://www.geocaching.com/seek/cache_detai...0&decrypt=y

(hover over the link to see the full URL in the status bar). The map on the page now is overwritten with logs when using Firefox 3.0.14. I am aware that this is not the case with the links to the new print-friendly pages and I can switch to that. But I do like this version and would prefer to stay with it, if it is still supposed to be in the web page. I have the sense that this defect did not exist prior to the current release.

 

I have the same issue, Windows Vista with Firefox. This looks like something that was changed since the update.

Link to comment
The default date when I went to log my cache showed up as yesterday's date even thought it was after midnight. This is not something the site has ever done before. I did not post any other logs so that isnt why the default date was the 20th.
This is a known issue and we hope to have it corrected for the next release.

The logic behind it being if you log your caches from a multi-day trip then you only have to change the date once for each day of the trip that you found caches on.

you don't realize the benefit of it keeping the last date.

Emphasis added. I'm guessing it's timezone-related instead.

I wonder if this discussion isn't mixing two separate items. I read Tsegi Mike's post to identify an issue with the default log date when he first went in to log a cache in his session - it should default to the current date, not a different date.

 

The other posts are expressing a desire to make sure that fixing that issue does not impact the different feature that defaults the log date for subsequent logs to the most recent log date in the current session. I agree - That's a very valuable feature if one is not using field notes.

Link to comment
Apparently I have another bug to report. Amazing since Im not uber tech savvy like you all are.

 

I went to log a cache we found on Wed Jan 20th. It is after midnight and officially Jan 21. All previous times Ive logged caches after midnight, the date shows the next day's date and I have to manually change the date. Tonight it didnt do that. The default date when I went to log my cache showed up as yesterday's date even thought it was after midnight. This is not something the site has ever done before. I did not post any other logs so that isnt why the default date was the 20th.

 

If it matters, I have WinXP and Firefox.

 

This is a known issue and we hope to have it corrected for the next release.

Please don't do that. I believe this behavior have changed back and forth in other releases ending with the way it is now. Moun10Bike, could you look into the history of the way this works before changing it again.

 

The logic behind it being if you log your caches from a multi-day trip then you only have to change the date once for each day of the trip that you found caches on. Otherwise you would have to change the date for each and every cache that you log.

 

I prefer the way it is sticky now, it's probably handled by a cookie that times out in a mater of hours or only works in the current session.

 

ProsperoDK/René

 

Yes don't do anyting! you don't realize the benefit of it keeping the last date. You just have to pay attention. When logging large numbers of caches, and logging them late like I have a bad habbit of doing, this is a real life saver! yes, it is session based in the current browser. Why not try closing your broswer each time you log a cache, that will fix your problem, but will induce a lot more clicks and key strokes than it takes to just change the date. "Freeze, Step away from the keyboard" :( MR

 

Guys, I had not logged any other caches that day. This was on the first cache I logged, and it gave me an incorrect default date. I pulled up the gc site, pulled up the cache page and got the previous day's date as the default date for the first cache I was logging. Please do not misunderstand what happened. Like you, I like it when it stays with whatever date I logged my first cache of the logging session on, but that isnt what happened in the case I reported.

Link to comment

I wonder if this discussion isn't mixing two separate items. I read Tsegi Mike's post to identify an issue with the default log date when he first went in to log a cache in his session - it should default to the current date, not a different date.

 

The other posts are expressing a desire to make sure that fixing that issue does not impact the different feature that defaults the log date for subsequent logs to the most recent log date in the current session. I agree - That's a very valuable feature if one is not using field notes.

And if you are using field-notes this shouldn't be a concern as the date and time is taken from the field-notes file.

Guys, I had not logged any other caches that day. This was on the first cache I logged, and it gave me an incorrect default date. I pulled up the gc site, pulled up the cache page and got the previous day's date as the default date for the first cache I was logging. Please do not misunderstand what happened. Like you, I like it when it stays with whatever date I logged my first cache of the logging session on, but that isnt what happened in the case I reported.

It appears that I misread you post, I was just concerned that the second part of ZSteve's clarification would be impacted by this fix.

 

ProsperoDK/René

Link to comment

Can't view one of my own bookmark lists. It says "You do not have permissions to view this list."

 

Has this been reported already and I missed it?

Yes. This appears to be a problem only with Firefox and deleting cookies and clearing the cache seems to fix it.

Thanks, Toz. That fixed it.

Link to comment

The new format looks great on my IMac, but terrible on my PC laptops, with the wrap around like others have mentioned copiously. I hope will soon be fixed. My biggest problem is that I can no longer get into Geocaching on my Treo phone because the caching log in box is maybe an 1/8 of an inch wide and I cannot enter my caching name and password. While I was out caching, I got email notification of three new caches which I figured was right about where I was, but couldn't log on to figure out where. Turns out I was within 1/4 mile of one of them where I parked to try to log in, so it probably cost me one or more FTFs. Any fix for for mobile phone logging in? It does give me a good excuse to buy a new phone however... Change isn't always good. Like when you stopped Locationless and Virtuals and put them on some Waywanking site, but that's another (sore) subject.

Link to comment

I started reading over this thread but gave up after the first page. This may not have anything to do with the new version, and may have been covered. I've been trying to run a pocket query for ALL caches (owned, found, unfound) in the area and it is leaving out some caches that i know are in place and still active. This is without checking any boxes on the submit form.

 

p.s. I haven't checked this out but for some reason, i have a feeling it may be because they are on my ignore list. But i've run queries like this before and never had any problems getting all the caches requested. Is this a bug or was this somehow implemented on purpose?

Link to comment

I started reading over this thread but gave up after the first page. This may not have anything to do with the new version, and may have been covered. I've been trying to run a pocket query for ALL caches (owned, found, unfound) in the area and it is leaving out some caches that i know are in place and still active. This is without checking any boxes on the submit form.

 

p.s. I haven't checked this out but for some reason, i have a feeling it may be because they are on my ignore list. But i've run queries like this before and never had any problems getting all the caches requested. Is this a bug or was this somehow implemented on purpose?

 

I seem to recall reading that after the changes, ignore list packs a .44 magnum and punches like a drunk gorilla. I think that may be why you're not seeing them. I'll run off and test it in a sec.

Link to comment

Interesting. Yes, indeed. Caches on my ignore list do not appear in Pocket Queries- even if the box to filter them is not clicked.

 

I guess that's odd, but not really something that I'd ever notice without looking for it.

I personally think the ignore list goes to far as it is. I depend on seeing caches on my ignore list to see where there is room to place a cache so from time to time I would like to see the caches on my ignore list show up on the list of nearest caches or on the map. Up to now I new I could use GSAK to make sure that I saw all the caches in the area because I didn't check "AND is not on my ignore list " in the pocket query. Changing the PQ so that caches on my ignore list are not included irregardless of what I checked is, IMO, a bug. Just because some people whine that the the see caches on their ignore list because they didn't check a box in the PQ is no reason to break the system for the rest of us. Now it will cost me another pocket query to get all caches on my ignore list from time to time. (FWIW I have all of two caches on my ignore list so it doesn't really effect me that much, I'll probably get rid of the ignore list altogether but it served a purpose of hiding the few caches nearby that I new I would never find).

Link to comment

Interesting. Yes, indeed. Caches on my ignore list do not appear in Pocket Queries- even if the box to filter them is not clicked.

 

I guess that's odd, but not really something that I'd ever notice without looking for it.

...Now it will cost me another pocket query to get all caches on my ignore list from time to time.

 

I just tried to turn my ignore bookmarks into a PQ- returned 0 results; an empty file. There is no check-box on PQs to show "Caches that ARE on my Ignore List".

 

They don't show up on a zip code search. They don't show up on the "Search for nearest geocaches from your home coordinates (filter out finds)" links from http://www.geocaching.com/my/ (AKA My/Your Profile).

 

So as it stands right now, there isn't any convenient way to spot those ignored caches unless you manually look at the coords.

Link to comment

Interesting. Yes, indeed. Caches on my ignore list do not appear in Pocket Queries- even if the box to filter them is not clicked.

 

I guess that's odd, but not really something that I'd ever notice without looking for it.

...Now it will cost me another pocket query to get all caches on my ignore list from time to time.

 

I just tried to turn my ignore bookmarks into a PQ- returned 0 results; an empty file. There is no check-box on PQs to show "Caches that ARE on my Ignore List".

 

They don't show up on a zip code search. They don't show up on the "Search for nearest geocaches from your home coordinates (filter out finds)" links from http://www.geocaching.com/my/ (AKA My/Your Profile).

 

So as it stands right now, there isn't any convenient way to spot those ignored caches unless you manually look at the coords.

 

This is what i have found also. It's definitely too much trouble to "un-ignore", run the query, then put those caches back on ignore. I'm sure it's a bug and hopefully it will be fixed soon.

Link to comment

... While editing a new cache and working with the waypoints I've just discovered that ALL the waypoints have reverted to the main coordinates, in other words, when you edit a waypoint it does not remember the coordinates for that waypoint and automatically substitutes the main coordinates entered in the cache edit page.

 

I see a change has been made to this issue, but it still does not remember the waypoint coordinates when editing an existing waypoint, but leaves the fields blank and it has to be entered again. So its still not a suitable solution as you have to remember to make a note of the coordinates before editing, else you loose them.

Link to comment

The new format looks great on my IMac

 

I have no trouble viewing on my MacBook 10.5.8 with FF 3.5.7 but Safari 4.0.4 is now useless with GC. It has gotten a little better. I can now log on and go to my profile page but if I try to navigate to any other page it will not completely load and the page is blank. The same thing happens if I try to return to any page including my profile page. There is always a little note at the bottom.... something like loading 5 of 6 or 52 of 53. I emptied the cache. I much prefer safari to FF. Internet downloaded browsers are not as full featured. At least I can still view and use the site.......EXCEPT... I have not been able to use any PQ's since the changes. The zips unzip but the files are not useable. I use MacGPSPro to upload new caches during the week and this is no longer possible. I can still run GSAK and do my POI's (even though it takes many tries to run the all finds).

Link to comment

Ok, so I attached this to my previous post about logs covering the images in some TB pages, and I see that that is on the list to be addressed, but this seems to be a seperate issue. Identical images display differently on Identical Coin pages, not sure if it's a glitch, or if I'm missing something?? Here are two of my Geocoins with Identical text and Identical Default images, but the image shows in two different spots on the page. They should all be assigned the same place in the page, unless the user wrote in some HTML to make it different??

 

This one looks like it's part of the text in the description...

http://www.geocaching.com/track/details.as...45-efa0ba4e3bc9

 

while this one looks to be outside that text, under the block with the logging options...

http://www.geocaching.com/track/details.as...2f-aa23fd997d9c

 

I'm going to poke around on a few more identical pages, and see if the pages are displaying differently depending on the length of the line that indicates the current location?? If that's causing the difference, then I guess it's not a bug, but just a design issue? I think the page should display the same way every time a user views it, regardless of the length of the location line?? Ideally I'd like to see the image displayed in the exact same spot on every trackable page(unless the owner has designed the page)?? If it's not a bug then I guess I'm off to make it a feature request.

Edited by WRITE SHOP ROBERT
Link to comment

Ok, so I attached this to my previous post about logs covering the images in some TB pages, and I see that that is on the list to be addressed, but this seems to be a seperate issue. Identical images display differently on Identical Coin pages, not sure if it's a glitch, or if I'm missing something?? Here are two of my Geocoins with Identical text and Identical Default images, but the image shows in two different spots on the page. They should all be assigned the same place in the page, unless the user wrote in some HTML to make it different??

 

This one looks like it's part of the text in the description...

http://www.geocaching.com/track/details.as...45-efa0ba4e3bc9

 

while this one looks to be outside that text, under the block with the logging options...

http://www.geocaching.com/track/details.as...2f-aa23fd997d9c

 

I'm going to poke around on a few more identical pages, and see if the pages are displaying differently depending on the length of the line that indicates the current location?? If that's causing the difference, then I guess it's not a bug, but just a design issue? I think the page should display the same way every time a user views it, regardless of the length of the location line?? Ideally I'd like to see the image displayed in the exact same spot on every trackable page(unless the owner has designed the page)?? If it's not a bug then I guess I'm off to make it a feature request.

OK, Nevermind I guess?? I poked around a little and determined that the difference in the pages was that there was a watcher on the coin that has the image bumped to the left, and I'm the only one able to see the difference?? So...with more options and notes in the "Trackable Item Options" Table, the owners page looks different that what other users see? I'm not sure whether to call that a Bug, or just a poorly designed feature? Either way, I'd like to see things displayed the same each time, regardless of who's looking at the Bug page.

 

To test, I looked at a Coin page with no watchers(image was displayed below the table) then I had someone add the coin to their watchlist, refreshed the page, and it bumped the image to the left of the table (for me, but not for them). So, the extra height of the table is forcing the image into a different place on the page.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...