I have a feature suggestion, and I'd be willing to code it if people like the idea.
What I would like to do is take the contents of devices4.xls and any advanced code information (from Rob's site and others) and put it into a database. This database could be accessed when trying to add a new key move (non-special protocol) to give you a list of known functions for that setup code as a drop down where the "EFC/Hex cmd" is entered. You could either choose a function from the drop down or enter an EFC or Hex cmd into the box. If you didn't have the database it would fail gracefully and you would have an empty drop down. It could also populate the drop down from a device upgrade loaded into IR, listing the buttons in the upgrade as options. Does this idea sound reasonable? I know updating the database would be a problem, and there are some problems with different devices reacting differently to some codes. There's also the issue of the user seeing functions that will do nothing for their device. Do you think this would aid the user more than it would confuse them? Is it worth the trouble of trying to build such a database? I can see the data from the database being used in other ways such as to create new KM upgrades as well.
Opinions?
IR Feature suggestion: EFC/Hex cmd Database
Moderator: Moderators
-
The Robman
- Site Owner
- Posts: 21886
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
I'm interested, tell me what sort of database you would use. Is this something that could be loaded into a MySQL database on my site? Do you know how to write applications to read and write to such a database?
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Simplest would be an Microsoft Access database as most PCs have the components needed to read an Access database. I know I could write something to interact with an online database, just not sure if I could write it in Delphi 
The other problem with that would be that you'd need to have in internet connection for the feature to work, and I often use my laptop disconnected at other peoples houses. I'd suspect such a database would be small enough that it could be easily downloaded, versioned much like DecodeIR and the RDFs as it was changed. This of course means that someone would have to go and update the database, but it shouldn't be too big a task (I say that now). Another advantage of Access is I could add functions for a custom setup code I created in KM to my database, and those functions would be shown in IR for me even though they wouldn't apply to other users. I can definitely see some two way interaction with KM/RM here where they could update the local database with new functions or read from it to create a new upgrade. If you had custom functions in your database, upgrading could be tricky, you wouldn't want to loose them. I'm sure we could create an upgrade feature for those who have access (or maybe just write a small upgrade tool that downloaded the latest database and updated the local copy). I know that Access isn't really a development platform (much like Excel), and I could use MSDE, but there are enough people with Access experience that it should be more "accessable." You could read the database even without Access installed. you'd need to install MDAC (Microsoft Data Access Components) which most PCs have installed already, so that shouldn't deter people.
I know the initial compilation of the database would take some work, as would structuring the database to allow for future uses (the ability to include what protocol a setup code uses or what devices use that setup code). Luckily, your site has much of the data we need to get started. What worries me is the fact that such a feature could be confusing when a chosen function doesn't operate the device. I hope that would be offset by the ease of finding discrete codes and obscure functions for many setup codes.
The other problem with that would be that you'd need to have in internet connection for the feature to work, and I often use my laptop disconnected at other peoples houses. I'd suspect such a database would be small enough that it could be easily downloaded, versioned much like DecodeIR and the RDFs as it was changed. This of course means that someone would have to go and update the database, but it shouldn't be too big a task (I say that now). Another advantage of Access is I could add functions for a custom setup code I created in KM to my database, and those functions would be shown in IR for me even though they wouldn't apply to other users. I can definitely see some two way interaction with KM/RM here where they could update the local database with new functions or read from it to create a new upgrade. If you had custom functions in your database, upgrading could be tricky, you wouldn't want to loose them. I'm sure we could create an upgrade feature for those who have access (or maybe just write a small upgrade tool that downloaded the latest database and updated the local copy). I know that Access isn't really a development platform (much like Excel), and I could use MSDE, but there are enough people with Access experience that it should be more "accessable." You could read the database even without Access installed. you'd need to install MDAC (Microsoft Data Access Components) which most PCs have installed already, so that shouldn't deter people.I know the initial compilation of the database would take some work, as would structuring the database to allow for future uses (the ability to include what protocol a setup code uses or what devices use that setup code). Luckily, your site has much of the data we need to get started. What worries me is the fact that such a feature could be confusing when a chosen function doesn't operate the device. I hope that would be offset by the ease of finding discrete codes and obscure functions for many setup codes.
Dabith:
The easiest way to do this and interact with IR is using the Borland Database Engine.
Delphi is already set up to see these tables. Adding a view to the database would be very simple.
If all we need is the content of devices4.xls that's not very hard to do. I can also create a separate Delphi applet to let the owner of the data edit this.
Then it's just a matter of havnig people download the updates to the tables. This wouldn't be a big deal since we are already used to downloading lot's of stuff for IR.
If you guys want I an make this my next IR priority.
We can divide and conquer...if you guys compile the data...I can then normalize it, create the tables and make the IR changes.
BTW, Delphi with databases is actually my bread and butter...IR is the first Delphi app in a long time for me that did not have any tables behind it.
One more thing the tables would always be downloaded in a zip file so they actually compress quite nicely..
This sounds like fun...
The easiest way to do this and interact with IR is using the Borland Database Engine.
Delphi is already set up to see these tables. Adding a view to the database would be very simple.
If all we need is the content of devices4.xls that's not very hard to do. I can also create a separate Delphi applet to let the owner of the data edit this.
Then it's just a matter of havnig people download the updates to the tables. This wouldn't be a big deal since we are already used to downloading lot's of stuff for IR.
If you guys want I an make this my next IR priority.
We can divide and conquer...if you guys compile the data...I can then normalize it, create the tables and make the IR changes.
BTW, Delphi with databases is actually my bread and butter...IR is the first Delphi app in a long time for me that did not have any tables behind it.
One more thing the tables would always be downloaded in a zip file so they actually compress quite nicely..
This sounds like fun...