I just got my Pronto from Mercata, and have started to play around with programming with ProntoEdit. After an initial pass at learning some of my remotes, it became clear to me that if I did a substantial redesign later, moving all the learned codes could prove to be a pain. But then last night I discovered IRDatabase in the Files section here on RemoteCentral.com.

IRDatabase is a Windows app that lets you extend the built-in ProntEdit database to include devices beyond the set Philips provided. You can take codes you've already stored in a CCF and copy them into new entries you are creating with IRDatabase. The GUI is clunky and needs optimization, but it does work.

What I've started to do is suck out all the codes I've learned so far and added new devices to the IR Database in ProntoEdit. It's slow work, but the thing is, once I'm done, I'M DONE! Even if I made a CCF with all my devices, then later decided to start from scratch, I still have all my IR codes in a safe, easy-to-access place. The redesign would then become a GUI design task rather than a nail-biting "Gee, do I still have that code somewhere?" exercise.

So my question is: am I missing something fundamental? Doesn't it make *sense* that you would want to separate form from function, the first task being to simply compile a raw database of learned codes from your device collection? It seems like once that's done, the GUI task is made much easier.

IRDatabase also lets you export single devices from the database into an external file that can be imported later. Once I'm done I plan on exporting each device I've created to its own file, so that others can simply import them into the ProntEdit IR database. Personally I would have found this to be more helpful than trying to snag IR codes from people's CCF files, as it eliminates the GUI baggage from the IR code content and is less awkward than trimming/merging CCF.

Again, what am I missing? Is there some fatal flaw here? Why aren't more people using this tool?

I tried this program (IRDatabase) thought that it was a great idea. After learning all of the codes for both of my Sony VCRs (VTR 2 & 3), saved, closed all that. When I reopened the program and they were gone. I has several bad experiences with the program GPFing.

Here is another suggestion. Create a panel with very small, non-icon buttons. Learn you codes to this panel and the alias you actual layout to these panels. If you later want to redesign your remote strip out the code panels into a new ccf and off you go!

Doug

Doug,

Yeah, I've read about the "use aliases to hidden panels" approach, which is basically akin to manually setting up your own IRDB in the CCF. The downside is (a) it clutters the CCF and (b) it wastes memory. I would argue that what you really want is to be able to extend the built-in IRDB, as there's a nice interface to it and it lives outside the CCF.

I hear you on treading lightly with IRDatabase. I set up fifteen learned buttons on my first go, only to have it corrupt the database. I had to grab the original from my notebook (where I also have ProntoEdit) and I lost all the work I had done. At this point I'm being very careful to make frequent backups of the rcir.mdb file, and to not use spaces in the button labels (that's my theory on why the first pass crashed-and-burned). So far so good.

I just wish Philips had made the damnned IRDB extensible in the first place. As it stands now it's pretty useless without IRDatabase.

The IR database does not save memory.

Doug: Actually your way probably waists more memory. The IR database was created for professional installers, they could create a basic interface and add the IR codes on the spot easily without having to relearn them. It holds the whole IR code, so if two buttons access the same code, you end up with it twice instead of an alias. An IR database code is equal in length to a learnt code.
Using a CCF you get the IR and the design (that you can change if you don't like it), it is better then the IR code by itself.

Anthony: while I don't want to quibble too much on the memory issue and CCF design philosophy, your point has a minor flaw. Certainly the CCF has to store the full code at least once, right? If one is concerned with memory constraints it is certainly feasible to ensure that the full IR code pulled from the extended IRDB is stored in a single place (probably one of the generic device pages) then aliased when it is used elsewhere.

Seems to me like the IRDB method is therefore as efficient as aliasing, and more so since you are less likely to be tempted into using hidden panels that are used solely as sources for aliases in the visible panels.

David:
Obviously you noticed I was talking to you, sorry for getting the names wrong.

I was referring to your following statement : "The downside is (a) it clutters the CCF and (b) it wastes memory. I would argue that what you really want is to be able to extend the built-in IRDB, as there's a nice interface to it and it lives outside the CCF"

If you do as part 1 of your last post then memory usage and clutter is the same as Doug's hidden panels. All you have done is added an extra step in the programming.
If you use the nice IR database button instead Aliases then you do end up using more memory.

If you change a component - or design there is less of a chance of making a mistake using hidden panels.

So to rephrase what I had said above
If you are a professional installer, then the DB could be useful. If you are not then there is no use. Since once you use the DB to put the IR code on the CCF to the Pronto it is just as if you just learnt it.

"If you do as part 1 of your last post then memory usage and clutter is the same as Doug's hidden panels"

Well no, not at all. What I was talking about was making sure that if you are going to be using the same IR code twice, then the second time you should alias the first place you used it. The difference is that I would have no hidden panels that are used solely for aliasing purposes. Rather, any aliases would refer to buttons that reside on other visible panels.

Again, the idea would be that you design your CCF to have basic device layouts (visible! and something you do actually go to use), then have other task-oriented pages which then alias buttons used on the device pages.

Granted, you can do the exact same thing without the IRDB or hidden panels by simply learning the codes and storing them directly in the visible device buttons. But then managing your IR code database gets complicated. Which of course is why people set up hidden panels as makeshift databases in the first place... :-)