BaseCamp 4.2.4 is now available

SapeGe opposite

This may or may not help you but BaseCamp doesn't store track points in the AllData.gdb file (MapSource stored everything in GDB files).

BaseCamp database and Track/Trip Log details

What this means is that if these files are lost/corrupted you lose track data.

Now my solution is to save, manually (i.e. copy them in Windows Explorer), GPX files from my devices. If BC ever messes up I can re-import the GPX(s) to restore the track data.

That sort of helps, but the real problem is: Even though you may see a start date (map and data views swapped), unless you look at the detailed properties of each track, you'll never know if the data has been stripped/lost until it's "too late." (Much of this data has been renamed in Basecamp, and once the dates are gone, it's virtually impossible to know the objects origin.) ~ I'm almost certain this has something to do with multiple listing of data in lists, when more than one lists contains "shortcuts" back to the same original data.

Somehow I suspect that when these shortcuts are renamed, they tend to loose their link back to all the extra data. I have found (on several occasions) the identical items (in different lists) show start dates, while others do not! ~ Sadly enough, I do all my editing (renaming) in BaseCamp, as the onscreen keypad on my Montana does not contain an insert/overwrite toggle. ~ What a PITA!

On a related note: I'm still seeing instances where data (waypoints /tracks etc.) are copied (drag & dropped) from one list to another, and then they don't show up in the lists afterwards. Even stranger, if you go to a parent folder they may show up there, even if they originated in another folder "further down and outside that same folder tree."

If I am correct in the source of this bug, the only workaround is to do all the name changes on the unit (from within BaseCamp) before importing the data. I don't think that is really a good idea, because until the data is imported, you're editing the only instance of the data you have......

Trip Planner - Bugs....

Whatever "Flat View" versus "Hub View" means I have no idea. Basecamp crashes whenver I try to change the view.

Also, the "contacting server" (to report bugs) doesn't seem to work either. After the crash, this window pops up and never seems to successfully transfer the crash data. ~ UPDATE: Crash reporting does work if you wait long enough.... It just takes several minutes to connect to the garmin servers. I suspect many don't bother to wait that long so crash reports go un-noticed.

Track Data Loss - Basecamp 4.2.4

Could it be the clipboard that is causing all the problems with tracks loosing data?

I frequently use Control-A and Control-C (with to Control-V) to replicate "instances" of tracks and waypoints to different lists in different folders... It just may be this replication (via the keyboard / windows clipboard shortcuts) that is stripping track data (removing times/dates/altitude data etc. from the tracks.) I've also lost some waypoint altitude data too.

The other possibilities are:

• Using "duplicate" in the basecamp right click (alt menu.)
  
• Renaming items. (I don't right click to use rename in the Basecamp menu.) ~ Instead I slowly double-click to edit the name field.
  
• Sending archived tracks (on unit) back to Basecamp for editing and then returning them to the unit. (When they are returned, they are no longer archived, they are "favorites."
  

Very frustrated trying to keep data organized without duplication everywhere....

Transferring points causes an absurd amount of redundancy and frustration due to the way Basecamp determines unique data.....
(I realize this is an attempt to avoid unintentionally overwriting data, but without a sync, data management is becoming a nightmare.

To help users deal with this problem, why doesn't Basecamp:

• Show the archived (track) folders (of the GPS unit when connected) separately. (FYI: The Montana GPS units don't correctly archive and restore tracks back to the correct location when tracks are stored on the extra microSD. This is firmware issue.)
  
• Append the original name of the object to the notes field (without the added 001, or 1 etc. whenever an object is duplicated due to a preexisting name conflict (during transfers).
  
• Standardize the renaming of all data when duplicates are encountered. (Tracks get a space+001, points just get a 1 added. IMO, everything should receive a hyphen001 sequence.)
  

Also, it sure would be nice to find some sort of "batch renaming tool" that could:

• Bulk append the names of the data. (after matching a search criteria)
  
• Bulk prepend names of the data. (after matching a search criteria)
  
• Bulk rename data (using placeholders & wildcard searches)
  

If anyone has a suggestion on how to go about "batch renaming", I'd appreciate replies.....
That being said, Basecamp is an extremely flexible tool, almost too flexible! The only thing it's really missing in terms of flexibility is the ability to display multiple maps simultaneously. (And a good Sync to the GPS.)

PS: In an attempt to "manage & facilitate data transfers" I have resorted to transferring (adding) all my track & waypoint data to the microSD (after capturing it and editing the new data in Basecamp.) That way, the internal memory only contains new (unedited & un-transferred data aka. recently recorded data.) With this method, I don't get duplicate tracks and waypoints during import (because I'm never rereading data from the microSD and I'm never sending the same data back to the same locadtion on the GPS.) ~ Unfortunately, the downside is some things don't work correctly on the unit as a result of this. Archiving & restoring tracks doesn't work because they end up back on the internal memory. You also cannot transfer Adventures etc. to the microSD. (Well, you can but the unit doesn't see them properly when using the "Adventures" application. And the track components do show up on the track lists. ~ Also, if you archive the track, you "break the adventure.")

On the Montana series (current firmware): The archiving is "hard-coded" to specify using the unit's built-in memory. So when the tracks are archived, they appear as "new tracks" on Basecamp because they end up back on the built-in memory on the GPS, and Basecamp doesn't/can't (unfortunately) differentiate between favorite and archived tracks.

Suggestion:Directory display of connected GPS. Differentiate favorites from archives

If Basecamp could somehow differentiate between archived tracks and "favorites" on the GPS unit, that would help organize and avoid data duplication... (A simple solution in Basecamp would be to: Display the folder directory structure of the GPS unit when connected to Basecamp.) ~ At present Basecamp shows all the data (with the exception of Adventures) combined without any directory info.

Just discovered another issue but unsure whether it's with Basecamp or on the GPS, more detail in this thread from another forum http://forums.gpsreview.net/viewtopic.php?p=191643#191643

Seems when you transfer a route to a 2013 model nuvi and it's converted to a trip the nuvi won't display any junction views, whereas it will with the same trip created on the nuvi itself. Forcing a recalculation on the nuvi of routes sent by Basecamp restores junction views.

There's a bug somewhere :confused:

Toolbar Issues Redux

Once the BaseCamp toolbars are layed out as desired, and the BaseCamp window is resized smaller (not minimized), then restore to original (maximized) size, the toolbars are placed randomly on several levels, and do not retain original positions.

I think you guys have been working on the toolbar issues for more than two years now.....

Once the BaseCamp toolbars are layed out as desired, and the BaseCamp window is resized smaller (not minimized), then restore to original (maximized) size, the toolbars are placed randomly on several levels, and do not retain original positions.

I think you guys have been working on the toolbar issues for more than two years now.....

Ironically, I just encountered this exact same anomaly last evening for the first time in ages. (I usually keep Basecamp maximized, so I don't normally encounter this issue.)
FYI: The software engineers are presently resolving date related issues..... I suspect we will be installing a v4.2.x update very soon!

Ironically, I just encountered this exact same anomaly last evening for the first time in ages. (I usually keep Basecamp maximized, so I don't normally encounter this issue.)
FYI: The software engineers are presently resolving date related issues..... I suspect we will be installing a v4.2.x update very soon!

I use BaseCamp maximized >90% of the time also, but occasionally I need to reduce the window size to drag-n-drop files from my desktop (or other folders) to the BaseCamp interface. I understand this is not a 'critical' error, and I hope the BaseCamp engineers can understand how incredibly frustrating it is to have to restructure the display interface every time the window size is changed, especially as this has been a recurring issue going back for more than two years of development.

If I had a nickle for every time I had to re-position my toolbars in BaseCamp......