Announcement

**paugusto** · March 10, 2002, 12:28 AM

This is where INITool originally came from - The ASP Emporium - INITool Object. You can get a basic understanding of what you can do with it there.

Michael has added some additional functions to it for use with an install script. These will let an install script modify configuration information in your script/asp. I think a good example of how that works is in his mod to the International Space Station script here.

Paul

**DSteiNeuro** · March 12, 2002, 04:59 PM

This is the second time I have posted asking for help with the .ini setup without any response (thanks Paul for the info you posted).

I am surprised by the lack or response to the poll. Unfortunately some of my favorite scripts have been converted to the .ini format and I haven’t kept up with the changes. Only three poll responses (including) myself all indicating that we don’t understand the system.

I was under the impression the purpose of the .ini format was to make installation and updating of new scripts easier. A great concept but I haven’t found that to be so. In that past when a new script was posted, I could open the script, dissect it and learn how it worked and make changes for my personal setup. With the .ini format, it takes several scripts and an installer to get the main script to work. It is hard to follow which script does what.

I understand that some of this is absolutely necessary for the more complex scripts to work, but If possible I would really prefer to Keep It Simple (s).

I have been trying to install the newest version of the movies script (which IMHO, is probably one of the greatest HS scripts). Unfortunately, to install it, I have to install the .ini system into my HS.HDV.

The Movies readme has grown but is difficult to follow and doesn’t have clear instructions. This is particullary so if you have followed the development of the scripts from the beginning.

According to the instructions, you have to install Ini-Tools. I found these but didn’t really see any instructions for them. I assume that the various code and scripts just go into the corresponding directories. Database tools is said to be optional but the install script stalls without them. Again, not sure on the instruction. The install script also asks for HomeSeer.ini. Where does this come from? I assume that I just make a blank text file and save in HS root as HomeSeer.ini.

The concept of install scripts is a good one, but I am nervous about running scripts that make changes to my .HDV without my control. I am also nervous about using system file extensions e.g. .ini and .mdv when they really aren’t system files. This might cause confusion and system corruption in the future. Rich is hoping to integrate a true Homeseer.ini into the HS architecture at some point in the future.

I am a fairly experienced HS user, if I am having this much difficulty- I am certain that a new users would also have problems.

That said, I am sure that once I get everything installed, I will use the .ini format and associated scripts. Thanks to everyone on the board for working as a team and making HS great. Part of the fun is working together and communicating on the HS board.

Ok some specific questions:
<UL TYPE=SQUARE>
<LI>1) HomeSeer.ini. What is this, where does it go and do I simply create a blank text file?
<LI>2) Ini-Tools- Do I simply install the various scripts/code into the correct HS directories.
<LI>3) Database tools- Do I simply install the various scripts/code into the correct HS directories.
<LI>4) HS.mdb? What is this? Do I have to MS MS-Access installed on my HS computer. Does a .mdb ODBC data source have to be present?
<LI>5) Installer scripts. Do these have controls provided to prevent overwriting events and devices already present?
<LI>6) What else do I need to get the .ini format scripts to run?[/list]
Thanks in advance for any help. This isn’t meant in any way to criticize in any way. In fact the coding is really impressive, but just way over my head and I am frustrated.

Oh, BTW- please vote on the poll so we can get an idea if I am the only frustrated person here!!

**ameridan** · March 12, 2002, 05:24 PM

Although the concept is probably well intentioned, I like each script to stand on it's own. I've got quite an assortment of scripts including Perl, that have been tweaked, run reliably and don't get touched as long as this continues. Ultrajones has contributed many great scripts, but it takes me about 2 hours to tweak Ultraview for my needs each time I upgrade for instance, and that's for a standalone set of scripts. If I also had to configure ini's and headers, etc.... well I'm simply not going to try-out or upgrade until I need to.

I think many of us will simply be avoiding newer scripts if they can't be tried-out in standalone mode, tweaked for improvements / fit our needs, and retained if we like how they perform. That is unless Rich builds in the newer add-ons [ hs.ini function that is added to the beginning of scripts that require this to run, for instance]. As Dsteineuro, found out, the feedback will dwindle when only a few users have kept up with all the add-ons necessary to be able to try out a script. If my vote counts for anything, I say keep scripts such that they run in standalone fashion.

Please don't fire back, it's just me thinking out loud. I also concede that how will Rich know what to build into a hs.ini fuction, if someone doesn't run with the concept and try it out.

[This message was edited by Ameridan on Wednesday, 13 March 2002 at 06:37 AM.]

**Rupp** · March 12, 2002, 07:13 PM

I agree it is very nice and DESIRABLE to have scripts in one file if possible and using the KISS principle. I have avoided the use of any scripts that use the ini and database ideas.

-Rupp

**Michael McSharry** · March 12, 2002, 07:38 PM

I usually view the board on a regular basis, but often have the problem of my New Since Last Visit gets reset so I do not see the posts, or there are more than 200 so I only see the first 200. This is my first view of DSNs frustration.

The scripts that I develop all use the .ini format because it provides me a way of maintaining a user-customizable configuration that spans multiple files. I also tend to build upon prior developments so my scripts/ASP will typically not be standalone. I find it more productive to build upon what I and others have done rather than starting from scratch for each new development. I agree that this makes it more difficult for the general user, but I also know that I have no chance of maintaining a configuraiton if I replicate everyting in every library post and try to keep all posts current with every change made to the supporting files. When I do upgrade the supporting file I do make every attempt at backward compatibility.

1) The homeseer.ini file is a text file that contains a set of Headers, Keys, and values with syntax compatible with early Windows .ini formats. The Header is encased in [ ] and the Key/Value pairs are listed under the header with a "=" sign separating each. The .ini format and IniTools support any file of this format, but homeseer.ini is the convention that I have used to collect all configuration information into a single file. If you are starting from scratch, then the homeseer.ini file is an empty text file that you create.

2) IniTool is a VBScript Class that defines some methods that make reading and writing a file that conforms to the windows .ini syntax. Headers, Keys, and Values can be read and written. The tool supports two modes of operation. One is a compiler/install-time mode. The other is an interpreter/run-time mode. The initial use was for run time, but user community feedback balked at the potential run-time burden and the need to include IniTool with the scripts. The run-time burden was benchmarked at around 10 milliseconds. Based on this feedback I provided a set of install-time tools that copies the information defined in the .ini file and places it in the target script. When it does this it comments the line that was changed and places an entry in the ...IniLog.txt file. In this mode of operation an install script is included that is executed each time a configuration change is made to place those changes in the target script. Several of my scripts/ASP have been converted to use this install-time mode of the Initool use.

3)The movies package started using the databaseutilities as it recorded movie information into a database. This was done at the same time that the poster & summary features were added to movies and a configuration switch was included to enable or disable this feature since the development was not complete at that time. It is my intention to use the database as the primary repository for the movie data and build the device string from there, should the user want to have a virtual device string built. At one time the database was optional. It will be required eventually. If you say the install does not work without it, then I guess it is required now and the documentation should reflect this.

4) Homeseer.mdb was introduced to my knowledge with UltraLog. It does not require any purchased software to reside on the homeseer computer. Everything that is required is downloadable from the Microsoft side as described in the setup instructions. The required download is native in W2K/NP. Most of my scripts/ASP are data-oriented and will use the database to manage this data.

5) My install scripts create devices and events and database tables if they do not already exist. If they already exist then they leave them alone. For devices I always use the Location/Name to identify a device. The install script will assign it an unused device code if the Location/Name device does not exist and you are free to change the device code to suite your organizational preferences. It will not get changed back automatically unless you delete the device and rerun the install script.

6) I try to document all that is needed to run a posted script. This usually contains a description of the installation steps as well as the links to all the supporting files. When new revisions are introduced they will contain the upgrade instructions from the prior revision. There is no single place to look if you are not current with the posts, however the latest post will have the change and install cronology so the necessary environment can be recreated. If you are at version 2 and the current post is version 5 then you will need to review the version descriptions for versions 3 and 4 to make certain that all configuration changes have been identified. It would be too much work to try to document all possible upgrade paths(i.e. 2->4, 2->5, 3->5).

If there is an existing script (e.g. custom_CNN) that has some user-editable Constants then to convert this script to the .ini format the following would be done:
1) Place a header in the homeseer.ini file that identifies this set of constants and the set of constants and values in homeseer.ini such as shown below

[Custom CNN]
; your virtual device
virtualdevice="V16"
; speak the news when available (true/false)
speak=true

2)Write an install script that has the following:
sub main()
dim hsINI Set hsINI = New IniTool
hsINI.Load hs.GetAppPath & "\HomeSeer.ini"
hsINI.InstallKeys hs.GetAppPath & "\Scripts\" & "Custom_cnn.txt","Custom CNN"
end sub
#include "includes\IniTool.inc"

3)Run the install script from a manual event. It will take the values of V16 and true and replace the values that were in the Custom_cnn.txt file.

The next time custom_cnn.txt is released by xplosiv then you will not need to edit it, but only rerun the install script you created. Of course if he provided somemore user-configuration constants then you will need to place those in the homeseer.ini before rerunning the install script.

Note that in xplosiv's case he wanted the user to specify his virtual device code. In my scripts I try to automate as much as possible so I will typically find a device code that is not being used. This will then require the minimum amount of effort for a user to try out a script. Similarly if an event needs to be created I will include the creation of this event in my install script for the same reason.

The autogeneration has nothing to do with .ini configuration formats, however with the data included in the .ini it makes the autogeneration possible. The user specifies what configuration he wants in the homeseer.ini and the install script will go off and implement this configuration.

The bottom line --

Hopefull with this background you will have a chance of implementing the Movies package.
1) Take the data contained in Movies.ini and plop it into homeseer.ini. The data values in Movies.ini should look very similiar to the USER CONFIGURATION area of the earlier movies packages. Be careful to pay attention of spaces around the "=" in the homeseer.ini. The IniTool treats spaces as valid characters so xyz = 123 is not the same as xyz=123. Do not use spaces around the "=".
2) Download the latest version of all supporting posts identified at the bottom of the readme.txt file. If you say you need database utilities then get it too. If you do not yet have the database homeseer.mdb, then get it at the referenced post or from UltraJones's earlier post. If you do not have W2K/XP and have not previously run a database then get MDAC 2.5 from Microsoft. Again look at the readme references.
3) Create a manual event with the install script run from it. Run it.
4) For your own benefit, and confidence building, look at the movies.txt, Movies.asp, or Theater_List.asp to see what the install script did. It will place a comment with the date of the homeseer.ini after each line that it modified.

The Movies does not require a very complex configuration setup and you could do this all manually without creating an homeseer.ini and not running the install script. All you need to do is play the role of the computer and follow the steps performed in the install script and do them manually yourself. The problem you will run into, however, is that the database table will need to be created and to do this manually you will need Access.

The other note of caution is that before you run the install script it is always a good idea to have a backup of your hdv file so if something goes wrong you will have a fallback position. My scripts are a long way from perfect.

**Jake** · March 12, 2002, 07:42 PM

I took a look at the whole INI thing. And it really sounds like a good idea, but there were two thoughts that kept me from using it in my project...

1. hmmmm, MS Windows Registry, sounds like a good idea, put all the info for everything in one place, but it gets to BIG and causes lots of problems. And where's the Registry maid when it's time for cleanUp?

2. Kind of the same as #1, I was worried about the INI getting to BIG and slowing all the programs/script down while they had to parse through some HUGE text file. Especially scripts that refresh often, as many do with HomeSeer. You have 3 or 4 stations all refreshing 2 or 3 pages and reading a BIG INI file each time they refresh... can you say, kaBOOM?

But, then again I also think... FIRE BAD!

**Jake** · March 12, 2002, 07:47 PM

Sorry... I couldn't find an answer that fit my polled opinion. If you can edit the poll and include a choice like... "I've checked it out, but am not convinced that it is the way to go". I bet you'd get some responses on that choice.

**Rupp** · March 12, 2002, 08:01 PM

I appreciate all the thought and work you have put into the scripts that you have posted, but any time an explaination is longer than most of the scripts I have written, I'll pass on implementing them. In additon I have found that I spent more time "tweeking" scripts such as the movies script than it took me to key in www.my.yahoo.com and slide down to the movies heading which has all the information formated for me. Hum, now that I think of it most of the information in most of these scripts is available with a simple url. Oh well keep up the good work and I'll just stick with the simple things in scripting.

-Rupp

**bdickhaus** · March 12, 2002, 09:48 PM

I am a relatively new Homeseer user, and I have yet to contribute to the script library, but I have a background in software development that goes back 20+ years, and I had hoped if I could find some time to contribute I would. But I find this veiled trashing of Michael and his excellent work in trying to bring Homeseer script development to a professional level disturbing.

There is another key item missing from the poll, and why I didn't respond, and that is "I understand it, everyone should use it, and I don't understand what everyone is complaining about" Even the poll was rigged to be anti-ini from the start.

The .ini concept has been around from the inception of Windows (ask your parents about that if you don't remember it). In the early 90's I developed my own .ini parsing (and later update) routines for a non-windows OS because I found it to be so simple, and yet powerful and flexible.

I have only been at this a few months, but I am already sick and tired of modifying scripts every time a new version comes out. Wading through all the comments, lines of code, etc. to find some obscure line of code in the script that I have to modify to match my system is something out of the dark ages. As much as I like the collection of CDJ scripts, NowPlaying in particular (which I think is awesome, thanks Jake!), every time a new script comes out I have to go in and modify it, because for whatever reason the authors of the scripts never seem to use defaults on application installs, among other things. There are now .inc files, but I had to change the CDJ directory information in four places! This makes no sense. There should be one place in a .ini file that I can define the CDJ directory, that should be all I have to do, and if there are 1000 updates of the script, or even 20 new scripts written, it will continue to use that same value, I should never have to edit a script or .inc file again, and only a .ini to add new parameters. From a users perspective this constant editing of program files is very aggravating, and for anyone that is not a programmer, very confusing, whereas .ini files are much easier to understand and update. You guys are thinking like programmers (I can say that because I am one) not like the people that have to install and use these scripts.

I have almost all of Michael's scripts installed, and had no problem getting them set up and working, welcomed the .ini concept when he introduced it, and can't wait for it to be implemented in Homeseer. Actually what I would like to see is an automatic run of an install script when I install a new version of a script or script set, that's how all other windows apps work.

Also it would not be difficult, once .ini support is implemented in HS itself, to add the ability to update options for custom scripts, not just HS itself. So that scripts could be added and customized all from HS just like the plug-ins. All it would take is a definition of keywords and acceptable values in a table format that HS understands. I know, that is how the .ini routines I wrote 10 years ago worked.

Bill

**DSteiNeuro** · March 12, 2002, 10:27 PM

<BLOCKQUOTE>quote:<HR>But I find this veiled trashing of Michael and his excellent work in trying to bring Homeseer script development to a professional level disturbing. <HR></BLOCKQUOTE>

Don't disturbed! [img]/infopop/emoticons/icon_smile.gif[/img] No one is trying to trash Michael's excellent work (especially in a veiled fashion). Like I already stated, I think that his scripts are among the best available to the HS community.

The poll had the option "No Problem here - .ini working great". I suggest that you give that a click [img]/infopop/emoticons/icon_smile.gif[/img] .

Now the good news- I have .ini working and agree that it is very slick.

All that was needed was some guidance. You have to remember that there are all different levels of users participating in the HomeSeer experience. Some users have no coding experience, some like myself are novices and some like yourself have "20+ years" experience.

Even more good news- .ini isn't that hard to set up. We just need better documentation. Some of us are most excellent coders, others are great at documenting.

So I propose a continued team project (it is already going on!) to better document and structure the HomeSeer Script Formats. This probably should include not only the .ini format but the includes and control panels etc.

Peace and have fun!

DSteiNeuro [img]/infopop/emoticons/icon_smile.gif[/img] (Much less frustrated)

[This message was edited by DSteiNeuro on Wednesday, 13 March 2002 at 01:15 AM.]

**mhunter** · March 12, 2002, 10:49 PM

All,

Please don't take any of this as a flame, it truly is not meant that way, as everyone on this board has become great friends.

Just thought I'd throw in my thoughts. First let me start off with a basic comment, I've been use HS for a couple of years now and have seen it grow (like all great environments). Each growth has added more complex features. This is usually due to some demand by the users.

As 'we' want more and more cool stuff, this requires a more complex operating environment. Like all things this will go through some pain while growing (anyone remember moving from DOS to the first windowing environment, by todays standards it sucked). I guess what I'm saying is that folks have a lot of choices to make as well as the script writers. Remember that most people who are writting scripts are doing it for FREE. Anyone who is using them does so by choice.

I'll be the first to admit that some of the new scripts stump me for a while (ie UltraView and DButils), but most of the authors are more than willing to help with installation.

Most of us want the latest cool feature, but when they can't be installed in a couple of minutes or we run into problems, it causes us some pain. Please don't let that pain spill over to those folks that spend hundreds of hours giving us FREE software. Most of this stuff I could never write no matter how much time I spent, so I'm VERY greatful for all the effort. And on the other hand I'm also the first one to want to pick up the computer an toss it out the window when it doesn't do what I want, and I mean NOW.

What I would ask is that folks make requests of the people writing scripts (i.e. I can follow the first 3 steps of the install, but could you please explain step 4 and by the way you might add this to the installation in your next version).

For those who choose not to use the .ini format, which I think is a great step forward considering where some of the scripts were headed for.

Personally I hope to get back to making some modifications to the weather program. I currently have a beta converted to the runtime version of INItools. fyi there are currently 37 variables that need to be changed each time I release a new version, this number will probably quickly approach 50 in a few versions. This is why I have moved to an .ini format.

You also have to know that Michael will probably adapt to anything that Rich supports/releases. He is just trying to create an environment to assist his development of great applicaitons. Sorry to ramble on, but I don't want to see Michael stop releasing his great scripts, so I plan on doing whatever it takes to keep following.

Oh, by the way I'm very guilty of sending panic messages to Michael, he has been great in responding.

Mike

**DSteiNeuro** · March 12, 2002, 11:08 PM

<BLOCKQUOTE>quote:<HR>I usually view the board on a regular basis, but often have the problem of my New Since Last Visit gets reset so I do not see the posts, or there are more than 200 so I only see the first 200. This is my first view of DSNs frustration.<HR></BLOCKQUOTE>

No problem! It is hard to keep up with everything. Like I said, I have been distracted by Now Playing!! (it is so cool)
Thanks for the detailed response.

<BLOCKQUOTE>quote:<HR>The scripts that I develop all use the .INI format because it provides me a way of maintaining a user-customizable configuration that spans multiple files.<HR></BLOCKQUOTE>

Definitely a big plus to this!!

<BLOCKQUOTE>quote:<HR>I also tend to build upon prior developments so my scripts/ASP will typically not be standalone. I find it more productive to build upon what I and others have done rather than starting from scratch for each new development. I agree that this makes it more difficult for the general user, but I also know that I have no chance of maintaining a configuration if I replicate everything in every library post and try to keep all posts current with every change made to the supporting files. When I do upgrade the supporting file I do make every attempt at backward compatibility. <HR></BLOCKQUOTE>

Understandable. I think that at some point after several major revisions, it is easier for the general user to start fresh.

<BLOCKQUOTE>quote:<HR>1) The homeseer.ini file is a text file that contains a set of Headers, Keys, and values with syntax compatible with early Windows .ini formats. The Header is encased in [ ] and the Key/Value pairs are listed under the header with a "=" sign separating each. The .ini format and IniTools support any file of this format, but homeseer.ini is the convention that I have used to collect all configuration information into a single file. If you are starting from scratch, then the homeseer.ini file is an empty text file that you create.

2) IniTool is a VBScript Class that defines some methods that make reading and writing a file that conforms to the windows .ini syntax. Headers, Keys, and Values can be read and written. The tool supports two modes of operation. One is a compiler/install-time mode. The other is an interpreter/run-time mode. The initial use was for run time, but user community feedback balked at the potential run-time burden and the need to include IniTool with the scripts. The run-time burden was benchmarked at around 10 milliseconds. Based on this feedback I provided a set of install-time tools that copies the information defined in the .ini file and places it in the target script. When it does this it comments the line that was changed and places an entry in the ...IniLog.txt file. In this mode of operation an install script is included that is executed each time a configuration change is made to place those changes in the target script. Several of my scripts/ASP have been converted to use this install-time mode of the Initool use.<HR></BLOCKQUOTE>

Thanks for clarifying this. I need to learn more about VBScript Classes, obviously powerful tools.

Also thank you for explaining about the compiler/install-time mode. I think that this has been a major misconception about the INI format. It is important to understand that in the compiler/install-time mode the INI file is called only during INSTALLATION of the scripts! It therefore does not place a burden on system resources

<BLOCKQUOTE>quote:<HR>
3)The movies package started using the databaseutilities as it recorded movie information into a database. This was done at the same time that the poster & summary features were added to movies and a configuration switch was included to enable or disable this feature since the development was not complete at that time. It is my intention to use the database as the primary repository for the movie data and build the device string from there, should the user want to have a virtual device string built. At one time the database was optional. It will be required eventually. If you say the install does not work without it, then I guess it is required now and the documentation should reflect this.<HR></BLOCKQUOTE>

Sounds like a good concept. I am not sure if the install needs it or not. Last night, the install script stalled without it, but I didn't have HomeSeer.ini set up correctly.

<BLOCKQUOTE>quote:<HR>4) Homeseer.mdb was introduced to my knowledge with UltraLog. It does not require any purchased software to reside on the HomeSeer computer. Everything that is required is downloadable from the Microsoft side as described in the setup instructions. The required download is native in W2K/NP. Most of my scripts/ASP are data-oriented and will use the database to manage this data.<HR></BLOCKQUOTE>

Again a good concept. Most of us should have Access available anyway.

<BLOCKQUOTE>quote:<HR>5) My install scripts create devices and events and database tables if they do not already exist. If they already exist then they leave them alone. For devices I always use the Location/Name to identify a device. The install script will assign it an unused device code if the Location/Name device does not exist and you are free to change the device code to suite your organizational preferences. It will not get changed back automatically unless you delete the device and rerun the install script.<HR></BLOCKQUOTE>

I was pretty sure that you had this in place. Might be nice to add some failsave options, maybe a msgbox opening if a conflict arises.

Bottom line is backup your .hdv before doing an install. Tonight, I simply made a copy of my .hdv and named it test. Once I have every thing in place, I will make the changes to my main .hdv (If you are ready this and don't have a backup copy of you .hdv off of your hardrive- DO IT NOW)

I know that you have a development machine and a working machine, nice concept.

<BLOCKQUOTE>quote:<HR>(6)I try to document all that is needed to run a posted script. This usually contains a description of the installation steps as well as the links to all the supporting files. When new revisions are introduced they will contain the upgrade instructions from the prior revision. There is no single place to look if you are not current with the posts, however the latest post will have the change and install cronology so the necessary environment can be recreated. If you are at version 2 and the current post is version 5 then you will need to review the version descriptions for versions 3 and 4 to make certain that all configuration changes have been identified. It would be too much work to try to document all possible upgrade paths(i.e. 2->4, 2->5, 3->5).<HR></BLOCKQUOTE>

No offense, but you are a much better coder than instruction writer! [img]/infopop/emoticons/icon_smile.gif[/img] I had a tough time going backwards, but I should have worked at it a bit more. Hopefully we can jump in and help with the instructions
<BLOCKQUOTE>quote:<HR>
If there is an existing script (e.g. custom_CNN) that has some user-editable Constants then to convert this script to the .ini format the following would be done:
1) Place a header in the HomeSeer.ini file that identifies this set of constants and the set of constants and values in HomeSeer.ini such as shown below

[Custom CNN]
; your virtual device
virtualdevice="V16"
; speak the news when available (true/false)
speak=true

2)Write an install script that has the following:
sub main()
dim hsINI Set hsINI = New IniTool
hsINI.Load hs.GetAppPath & "\HomeSeer.ini"
hsINI.InstallKeys hs.GetAppPath & "\Scripts\" & "Custom_cnn.txt","Custom CNN"
end sub
#include "includes\IniTool.inc"

3)Run the install script from a manual event. It will take the values of V16 and true and replace the values that were in the Custom_cnn.txt file.

The next time custom_cnn.txt is released by xplosiv then you will not need to edit it, but only rerun the install script you created. Of course if he provided somemore user-configuration constants then you will need to place those in the HomeSeer.ini before rerunning the install script.

Note that in xplosiv's case he wanted the user to specify his virtual device code. In my scripts I try to automate as much as possible so I will typically find a device code that is not being used. This will then require the minimum amount of effort for a user to try out a script. Similarly if an event needs to be created I will include the creation of this event in my install script for the same reason.

The autogeneration has nothing to do with .ini configuration formats, however with the data included in the .ini it makes the autogeneration possible. The user specifies what configuration he wants in the HomeSeer.ini and the install script will go off and implement this configuration.
<HR></BLOCKQUOTE>

Got it!

<BLOCKQUOTE>quote:<HR>The bottom line --

Hopefull with this background you will have a chance of implementing the Movies package.
<HR></BLOCKQUOTE>

[img]/infopop/emoticons/icon_smile.gif[/img] [img]/infopop/emoticons/icon_smile.gif[/img] [img]/infopop/emoticons/icon_smile.gif[/img] [img]/infopop/emoticons/icon_smile.gif[/img]Done Deal [img]/infopop/emoticons/icon_smile.gif[/img] [img]/infopop/emoticons/icon_smile.gif[/img] [img]/infopop/emoticons/icon_smile.gif[/img] [img]/infopop/emoticons/icon_smile.gif[/img] :

Thanks again for all of the work that you have done and the patience to share it.

**Jim Doolittle** · March 13, 2002, 09:55 AM

Okay, I can't stand it and I have to throw in my two cents as well.

I think INI files are a good idea. My motion scripts use a my_motion_const.txt file which, in retrospect, was my attempt at an INI. I can easily port this file to homeseer.ini. However, using the "old Windows" ini approach, I plan on converting my_motion_const.txt to its own ini file (my_motionsensor.ini?).

I think it is better to keep separate ini files. Windows 3.1 did that. This is a compromise on the tradeoff of being able to "tweak one file" versus "stand-alone script".

I have also been waiting for an hs.readini command which I think Rich may implement which would make INITools obsolete. With that said, if I happen to come up with new ideas for the motion script package and Rich hasn't implemented INI functionality, I will use INITools.

I agree Michael has done great work. I also understand the frustation of others. Hopefully, we can go forward and still have some fun while we are at it.

Jim Doolittle

**paugusto** · March 13, 2002, 11:20 AM

In case you hadn't seen that. Check out the ASP Emporium link I posted earlier in this thread.

Paul

I am clueless in regard to the .ini format	0%	0 votes
Need some help with .ini format	0%	0 votes
Haven't tried it yet, but I think I have it	0%	0 votes
No problems here, .ini working great	0%	0 votes
What is .ini, anyway	0%	0 votes

Announcement

Need help with setting up .ini scripts

Need help with setting up .ini scripts

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment