Once I figured out that copying a button from one device page to another in the MXOP causes a program crash if there is more than one line of text on the button, I experienced no more problems with the inherent stability of the program, i.e. no more crashes. I just delete one the text lines and it them seems to work like a champ. Got all my screens designed, downloaded to the remote and everything looked perfect. I then re-programed all the devices (since the preprogramed functions are lost in a download) and have come against the most vexing problem yet: cloned buttons! I have them all over, sometimes just a pair, sometimes 5 or 6. Teaching one button a command or macro teaches them all the same command.

This problem has been addressed before in these forum threads, but never comprehensively. Has anyone, including Mike Gifford, been able to figure out exactly why this happens and how to avoid it? I think that if you copy a button from one page to another, it will keep it's learned function, right? So, I tried copying buttons that had no function previously assigned and figured I could create as many buttons as I needed on a page that way, then change their style if needed, download the configuration to the remote and reprogram. (I was careful to not let any buttons touch any other, even just a corner.) The result was clones galore. So, then I tried adding buttons, same problem. If you add a button, you're essentially hitting the "select" command on the button utility and then dragging it onto the work space. Do you have to aviod touching even a corner of any existing button already in the work space with the "add" function as well? That's really hard to do since you "drag" each button (or it's dotted line "facsimile") from the right edge of the screen to where you need it. It's tough to avoid other buttons while doing this; perhaps you just have to build your screen "from left to right"....

Uploads are a real problem for me. It seems that the uploaded version always has bugs in it. I keep getting error windows with "Invalid font" or "No more input text!", text disappears all together, etc. So, I've decided to avoid uploads entirely and just create the perfect configuration on the computer, download, and reprogram to eventually get the remote configured. But these cloned buttons are driving me nuts! Any help out there?

1. I completely gave up on coping buttons, finding that going to the trouble of creating and teaching new ones was much more reliable.
2. When LCD buttons cloned I deleted both of them and created new ones - seemed to eliminate the problem.
3. On two occasions the buttons cloned were the rubber ones on the face on the unit. I never could get rid of them. Tried erasing both the button on the LCD and the rubber, tried erasing the entire device - no joy. In my experience, when a rubber button becomes cloned there is no option but to wipe out everything and start over. On both occasions it was "favorite channel" buttons that jumped over. So the last time I deleted all favorite channel buttons in the unit before starting anything. All worked fine. I can upload and download - only lose machros on download. Strange.

This worked for me using ms-access:
1. Open the MDL file using ms-access. (Other threads talk about this and the password).
2. Open the BUTTONTB data base.
3. There is a column that has an id for each key. You will find that duplicate keys have the SAME ID!! It is a number usually between 7 and 35 and usually numbered from left to right and top to bottom of the screen (i.e. 7,9,11,13 on 1st row, 15,17,19,21 on second row, etc.).
4. I don't know how to sort by 2 columns in access so I exported to an excel spreadsheet then sorted by device page and then this "id" column. This instantly shows up all the duplicate keys.
5. In access, you can change this number (Try to keep it odd between 7 and 35, else don't know what would happen). Also open the other databases, and be sure they don't reference this same ID (I don't think they do, but if so you would have to change them too, especially BUTTONTEXTTB).
6. Save the file in access and reopen using the normal software to make sure nothing got corrupted. Download and try relearning to two of the keys. They should now each be able to learn independently.

The physical placement of the keys doesn't seem to necessarily be related to what causes them to be assigned the same id. They can be spread apart and this still happens.

to John G...
John, thanks for what I'm sure is excellent advice, but MS Access is all "greek" to me. I don't have the program, and wouldn't know how to use it if I did have it, I suppose. What I need to know is what causes cloned buttons during the "normal" operation of the MXOP, and how to avoid creating them.

My guess is it's due to placing a button physically over another sometime during editing. I've had all sorts of weird things happen by doing that -- such the inability to move or delete button text (keeps returning moving back).

When I created and downloaded my original mdl file, I only had 6 "clones" out of 360 custom buttons, but in general I would start out with the Default.MDL screen for each device, and then on each screen just changed the button style then moved it a few pixels as needed to line up correctly, but rarely if ever moved buttons across each other. And I rarely inserted a button from scratch. (Only if the default screen had fewer buttons than I needed) I deleted the old text and added new as the last step. For the 6 clones, on the remote itself I deleted and reinserted each key. Then relearned it. They all worked fine after that.

I had an unrelated problem learning macros. If the macro included keys from another device, it cloned the macro to a key in the same physical position on the other device. But you can erase the macro from that key and it returns to its original learned function.

Well, I'm at my wit's end. I thought that by deleting the cloned buttons (in the remote and in my MXOP file)and adding them back, being very careful not to let them touch any other buttons in the process, I would thus be able to vanquish my clones and return to individual programmability for each and every button. Alas, after spending an entire evening doing just that, and downloading the revised program to the reomote, I've discovered that nothing's changed. The exact same clones are in the exact same positions. I thought I might try the MS-Access approach that John G. recommended but found that the program costs more than the remote did! Short of wiping everything out and starting from scratch (the default configuration in the MXOP and on the remote), I don't know what else to do. I spent countless hours coming up with the ideal configuration and the thought of starting over is rather unappealing. And I'm not sure even that would work! Any suggestions out there?? My sanity is at stake!!!

Mike Gifford suggested I return the remote to the company, but I'm fairly sure that it's not a hardware problem. The remote itself works like a champ, at least for the non-cloned buttons. It seems to be a MXOP problem and they don't seem to be in any rush to get it solved and a revised version posted on their web site. Is this any way to run a company?

Try deleting them in the remote and then creating new ones in the remote - that's what has worked for me. After getting everything right in the remote then you can upload and save the configuration for future use.