BaseCamp Issue with dividing trails that I have copied

You need to duplicate the track before you make changes. (Right click on the track and select Duplicate)

My collection is a database and when you copy and paste anything from one folder to another you're not actually making a copy - you're only making a new tag that is pointing to the original item.

It's a normal 'database' thing so once you understand databases it makes sense. No big deal really.

I'm an IT professional of over 40 years and I can assure you it's not a "database thing". It has everything to do with the design of how the app functions and the design of the user interface.

If they had actually used a standard database design there wouldn't be any need for all the kludges and workarounds.

It's wonderful that folks like you who have spent hours learning the intricacies of Basecamp are willing to share your knowledge but it shouldn't be necessary for basics like this.

...ken...

You need to duplicate the track before you make changes. (Right click on the track and select Duplicate)

My collection is a database and when you copy and paste anything from one folder to another you're not actually making a copy - you're only making a new tag that is pointing to the original item.

Breezly .... you rock .... thanks so much .... that was a quick fix, greatly appreciated

I'm an IT professional of over 40 years and I can assure you it's not a "database thing". It has everything to do with the design of how the app functions and the design of the user interface.

If they had actually used a standard database design there wouldn't be any need for all the kludges and workarounds.

It's wonderful that folks like you who have spent hours learning the intricacies of Basecamp are willing to share your knowledge but it shouldn't be necessary for basics like this.

...ken...

kganshirt .... Am I understanding you when you say this was a basic question, and everyone should know it ... just asking, not trying to start anything

kganshirt .... Am I understanding you when you say this was a basic question, and everyone should know it ... just asking, not trying to start anything

I understand. My point is that the function you were trying to perform is a basic sort of function. So it shouldn't be necessary to have intimate knowledge about how the application stores its data to be able to do it without messing up your data. You were acting as a normal person would act when trying to do this.

Normal people expect when they select a data item and then use a "Copy" command to place a copy somewhere else, the selected data item will actually be copied there. They then expect that they are now working on a copy of the item, not on the original item. That is the entire point of making and then working with the copy. We want to mess with the copy and not be concerned about ruining the original.

Notice that I never once used the word "duplicate" in the preceding paragraph.

This illustrates two fundamental problems with the Basecamp design.

1. We have to learn unusual terminology for a function we thought we already understood from a lifetime of normal conversational usage and at least a few years of common computer usage.

2. The design of the application forces us to understand the intricacies of the underlying data storage so we can make the distinction between when we should Copy something and when we should Duplicate it.

The need to make this distinction shows up in a variety of operations like what you were trying to do.

And the reverse is also true. For similar reasons, Delete may not delete what you think it will.

...ken...

I understand. My point is that the function you were trying to perform is a basic sort of function. So it shouldn't be necessary to have intimate knowledge about how the application stores its data to be able to do it without messing up your data.

I get that you're very anti BaseCamp but it's hardly 'intimate knowledge', simply a matter of right clicking and using the 'duplicate' command instead of 'copy' :)

I suppose the options under right click could be 'create a duplicate of this data pointer so that I can change it without affecting the original' and 'please make a copy of this data pointer so that any changes I make apply to both it and the original' ... but that would be daft, wouldn't it?

I get that you're very anti BaseCamp but it's hardly 'intimate knowledge', simply a matter of right clicking and using the 'duplicate' command instead of 'copy' :)

That post was not anti-Basecamp. I'm not anti-Basecamp. It was illustrating bad software design, and I am anti bad software design. It happens that Basecamp is a stellar example of bad design. The two examples I gave, using Copy as a command that doesn't copy what we expect and Delete as a command that doesn't delete what we expect, are perfect examples of how not to do a user interface.

If it's not intimate knowledge please describe to me how a normal computer user is supposed to know it without research? Research that usually consists of trying to use the command in the normal way and discovering it doesn't work, followed by either experimentation or looking for support or both.

A command as common as Copy should never fail when used in the normal manner. In Basecamp it does. The Delete command is similar.

I suppose the options under right click could be 'create a duplicate of this data pointer so that I can change it without affecting the original' and 'please make a copy of this data pointer so that any changes I make apply to both it and the original' ... but that would be daft, wouldn't it?

It's not as daft as the present situation. They've done something similar with Delete over the years. Why not do something similar for Copy/Duplicate. At least provide some hint that Copy is not going to do what you have come to expect all your life.

As an aside to illustrate how confusing it can be without stopping and thinking about it, the second part of your prompt example is in error, as I'm sure you know ... if you stop and think about it for a minute. Changes do not "apply to it and[/b] the original". Changes only ever happen to the original. Changes can't happen to the data pointer because it's just a label, as you have already explained quite well.

The following is a bit of history for those who get frustrated over Basecamp's unusual approach to many things. And a bit of defense for the current developers who have inherited a situation not of their making.

When Garmin made the decision to get heavily into outdoor/fitness products (hiking, geocaching, biking, exercise, etc) they needed a PC app to help manage those devices. That's what Basecamp started as. Around that same time the development tools used to create and enhance Mapsource were going out of fashion. Basecamp was started using a new generation of development tools.

A decision was needed about the future direction for the functions provided by Mapsource. Specifically, convert Mapsource code to the new tools and continue its development as a separate product or add those functions to Basecamp?

It was decided to stop further development of Mapsource and add those features to Basecamp.

It is clear in hindsight that the original design of Basecamp was never intended to support automotive routing features nor extensive complex trip planning. Adding those capabilities has not been without its moments. Witness the evolution of waypoint categories, as just one example.

One point of great confusion arising from this evolution is the "database" myth. Basecamp does not use a standard sort of database that any IT professional would recognise as a proper DBMS.

You will recall a discussion we had with Falagar a few years back about when is a GDB file not a GDB file. Mapsource and Basecamp both use the .GDB file type. That left many of us wondering why we couldn't simply load Mapsource .GDB files straight into Basecamp. Falagar was kind enough to explain that it was because the Basecamp GDB file was sort of a Mapsource GDB file on steroids. The two are quite incompatible.

It was made clear that the developers had always *wanted* to build Basecamp on top of a proper database. And back in those days there was still some *hope* that they would be able to do so. But it has never happened. Basecamp is built on a super-GDB file.

To work around the limitations the developers are trying to use the user interface to give the appearance of a database. We have watched this evolution as they have grafted on Lists and then Folders of lists, and expanded their functionality. And adding commands to mitigate the fact that basic commands like Copy and Delete don't work the way they do in the rest of the universe.

And so it becomes necessary for users to learn that Copy doesn't copy what they think it will and Delete doesn't delete what they think it will. And for those of us who have enough data to want multiple MyCollections having to jump through hoops rather than just having File/Save and File/Open functions to save and open different MyCollections. And be able to easily store them anywhere we want.

Basecamp was never designed to do what it does. The fact it does all the things it does at all, never mind as well as it does, is quite amazing and a tribute to the abilities of the developers. But it's still a great example of bad design.

...ken...

@RustynMtnHome

What you tried was Basic and the assumptions you made were natural, but unfortunately wrong. I made the same assumptions and saw the same result. I looked at the interface and concluded that a “Library”, a “My Collection” and “Lists” were things that were somewhat new to me.

So I went to Help and found that an explanation of the applications interface was grossly inadequate. I still do not know what “Library” is, its function or why it even exits. I still do not know exactly what “My Collection” represents.

But a little play was helpful to gain a handle on Lists even though it too was not explained in Help. I do not know if Garmin has addressed this very fundamental issue that leads to so much unnecessary confusion, but it really should be at the top of their list.

The behavior of BaseCamp suggests that Lists only contain shortcuts/links/pointers/references (whatever you feel comfortable with) to objects. This is a guess, but a reasonable one that has nothing to do with an intricate knowledge of how BaseCamp actually works. So what should I expect?

If I copy and paste a Windows shortcut, only the shortcut gets pasted. The object it links to is never duplicated during the paste command. If I copy and paste a website link, only the link gets pasted. The contents of the website are never pasted. This is exactly what BaseCamp does.

A Windows shortcut or a website link does not contain the contents of what they link to. If I access a website via a link or say a document via a Windows shortcut and make changes to said website or document I have not altered the link or created a new website or a new document; I have only altered and existing website/document. From my experience, I would expect that all copies of the link/shortcut will lead to the same changed website or changed document. Exactly as happens in BaseCamp.