How can you copy and paste a route without it being connected to the original.

You can't actually copy anything within a single instance of Mapsource. But if you open a second instance of Mapsource and do a copy in one and paste in the other you get a duplicate, not a link.

...ken...

But that is exactly what the original poster is tried to do.

I’m not a programmer so I won’t claim to know what makes an application a database application, but both MapSource and BaseCamp imitate what I would consider to be a database. My definition of a database as is a file composed of records with records composed of fields. Each file is therefore an independent database.

I suspect there are different classes of databases. I would describe MapSource and BaseCamp as belonging to a class that requires each record to have a unique identifier. Both BaseCamp and MapSource behave as if the identifier is composed of two fields; object type (route, track, waypoint etc.) and object name.

When you opened a new instance of MapSource you created a new database, so copying the object is allowed as its identifier did not already exist in the database. Try and copy a second time from one instance to the other and it will not work. So I will call a penalty on you just as you did on JAVAWA.

After shooting your leg off the first time (I only suffered a minor scratch) you should have wondered what a list actually is – clearly it is not a MapSource file/independent database. I don’t know if Garmin provides a clear explanation of what a list is, but I will tell you that it behaves as if it only contains a link/pointer/reference to database objects and not the objects themselves.

Lists and folders behave as if they are a means of indexing and cross indexing objects, similar to a card catalog in a library. I do not expect my public library to have a copy of a book for each way that it is indexed, so why should I expect BaseCamp to make a new record for each way I choose to index an object?

Both BaseCamp and MapSource behave as if the identifier is composed of two fields; object type (route, track, waypoint etc.) and object name.

I'd say that the identifier is the complete object itself; when something is different (name, color, whatever) pasting (and thus creating a new instance of the object) is allowed.
The file AllData.gdb contains the actual waypoints, routes and tracks (note though that certain trackpoint data is stored separately); the file FolderData.gfi contains references to the objects.

The choice for a database with a separate index (and how Garmin implemented it) has its pro's: storing your routes in a central place without the need to bother where to save your stuff (and finding it back later!), the ability to decide which items you want to see on the map and which not without deleting them and the ability to create a backup easy (backups are highly underrated, but imho very important). The cons: the concept of working with references instead of the items itself isn't always clear for new users (maybe using a different icon like the arrow on shortcuts in Windows Explorer would be an improvement), and how copy/paste works; mainly because of the chosen terminology ("paste" should be called "paste as shortcut" or something like that; maybe also using another key combination).

...
After shooting your leg off the first time (I only suffered a minor scratch) you should have wondered what a list actually is – ...

I understand completely what a list is. And equally importantly, what it is not. As I said in my original post, I occasionally shoot myself in the foot or even blow my leg off because I forget that in Basecamp "copy" doesn't actually copy. It's so unintuitive that I simply forget sometimes if I haven't been using Basecamp much.

Regarding the difference between Basecamp and Mapsource, it's this: If you try to copy something in Basecamp it will look like it worked when it really didn't make a copy at all. If you don't understand this aspect of Basecamp -- and many users do not -- you are now potentially vulnerable.

Whereas in Mapsource if you try to copy something it simply does nothing (well, it copies it to the clipboard but it makes no change to the currently opened file), the same behaviour as the "duplicate" command in Basecamp.

I still maintain that when you use the "copy" function in Basecamp, Basecamp should automatically ask if you want to create a link in the target list/folder or if you want to duplicate the selected object(s). If nothing else, this would alert the user to ask "What's the difference?"

And now I'll answer my own challenge regarding a current example of when a copy function produces a link to the original instead of an actual physical copy.

If you install the Microsoft SkyDrive app on your PC AND you allow SkyDrive to create a "folder" on your PC to sync with folders on your SkyDrive cloud account, you will end up with a similar issue to the "copy" function in Basecamp. If you try to copy one of the files in the local SkyDrive folder to another local folder on your PC, it looks like SkyDrive is creating a symlink (symbolic link) in the target folder instead of placing an actual physical copy of the file there.

Mostly this doesn't matter a lot as long as you don't want to change them, eg. music files. But if you try to edit those "files" you copied into the target folder you will get some really hair-pulling results. Specifically, if you try to edit some of the files in the target folder, say change the "title" in the ID-tag of a music file, some of the edits will take on the first try; some will take after a couple or three tries; and some won't take at all, no matter how many times you make the change. What you won't get is a warning that you can't edit the files from the symlinks with any predictability.

If you edit those same files in the SkyDrive folder on the PC, they change exactly as you would expect.

I dislike symlinks even more than I dislike Basecamp's "copy" function.

...ken...

@JAVAWA

Yes that would be another way. I’m not trying to figure out the exact programming, just a simple working model of the application – at all times accepting that my model is likely wrong, but good enough to keep all limbs attached. I chose two fields, object type and object name, simply because all records would have these two fields and I suspected that I would want different fields for different object types. So if both object types and names aren’t an exact match I make a new record. If they do match I can do additional checking of fields based on object type. And at some point I have to decide what to do – ignore, replace or create a new record.

It really doesn’t matter which idea is correct – both could be wrong. Your idea can be tested by adding a comment to a route, changing symbols on waypoints, placing something in various waypoint fields etc. I don’t remember if BaseCamp use a default color or a last color, but either way you could test your idea by trying to create a new route from the same 2 waypoints with the same name but a different route color and see if it works. Of course, doing something this weird could crash things.

@KGANSHIRT

I did not mean to imply that you don’t understand what a list is, or that it was silly of you or the original poster to do what you did. I did it also and expect that most users did (at least those coming from MapSource). My wound was minor only because I was playing with the interface and not doing anything I was planning on keeping. Nor am I saying the help file does a good job of explaining the concepts behind BaseCamp (I haven’t checked) or that the interface doesn’t need tweaking (I personally think it does, but this would not change the how the application behaves).

Simple commands like Copy and Paste can be more complex then we think. For example, in Excel I use the A1 reference style. If I enter 1 in cell A1, 2 in cell B1 and enter the formula =A1+B1 in cell C1 I see 3 in cell C1 and =A1+B1 in the formula bar. If I copy cell C1 and paste it into cell C2 and also into Word or Notepad I will get 3 in Word/Notepad, 0 in cell C2 and =A2+B2 in the formula bar for cell A2. All from that one copy.

The expectation of what a command should or should not do is to some degree dependent upon our understanding of the concepts of the application. From my likely incorrect ideas of these concepts Copy, Paste and Duplicate behave just as they should in both applications.

Whose right? We both answer “I am” and the software engineer shakes his head and goes out for a drink of two.