why is it non standard, his idea is what I was going to have as a feature request.

It is actually standard for progams to use an include line to a central config file.

Whether or not that can be done on windows batch files I dont know tho, it certianly can be done on linux bash scripts.

I prefer ini files to his current scripts (where have to edit many scripts) or using registry storage, this is probably the best way he can do it.

Edited by Chrysalis (Wed 26-Dec-12 15:28:41)

In reply to a post by Chrysalis:

why is it non standard, his idea is what I was going to have as a feature request.

That part of my post was referring to "The same ini file could then be used for obtaining & storing snapshot data and ongoing data". By definition such are not initialisation values and have no place in the file. He has since clarified his intentions, viz "The ini file will indeed only store very basic details, similar to those I mentioned. At some stage it may also store details of which graphs to include on a yes or no or a true or false basis", which is fine.

It is actually standard for progams to use an include line to a central config file.

Assuming I understand your word "include" correctly, a "#include" file is included during the early passes of a compilation. It's contents at that time are in effect hard-coded into the exe. That is not the purpose of an ini file nor is it what Bald_Eagle1 envisages.

Whether or not that can be done on windows batch files I dont know tho, it certianly can be done on linux bash scripts.

Yes, batch files can be executed from within a Windows exe.

I prefer ini files to his current scripts (where have to edit many scripts) or using registry storage, this is probably the best way he can do it.

There is no disagreement from anyone in the thread about that for this particular application. I was merely unhappy with the thought of transient data, (as opposed to possible system status indicators), being included in an ini file.

I should be able to help with the parsing side of this (much as I hate C).

For simplicity I'd leave out the use of sections (as in [login]), I don't think they's add anything useful.
I'd make sure # comment lines were allowed, these could be used for informal sections if anyone wanted to.

I wouldn't go near trying to write a GUI in C though.

~~~~~~~~~~
On the graphing side, users of up to date browsers may like to try my more interactive graphing that works from the current log file:
http://programbits.co.uk/modemGraph/plotstats.html

Edited by StephenTodd (Wed 26-Dec-12 17:20:22)

I agree about not using the INI file to store persisted data.

I would however strongly suggest that care is taken in choosing the location of any data file. It should not be written to the application folder. Microsoft has tried over recent years to introduce security into its OS and one of the better things they have done is make it harder for applications to write to anywhere under c:\program files\. of course the user may put this application anywhere they want but as a general rule I think EXEs should never share a folder with data.

Unfortunately working out where to write the file isn't obvious because it's changed so much. Even the API call used to determine the location has been superceded twice. The latest incarnation is SHGetKnownFolderPath(). I would choose FOLDERID_LocalAppData as the base path with the application name appended to complete it.

More choices here: http://blogs.msdn.com/b/patricka/archive/2010/03/18/...

Personally I'd have a wrapper function that forks underneath into separate Linux and Windows modules. The Windows module can then store the data where it wants. The registry is the simplest way frankly and wouldn't be difficult. For the registry just use the bits in []s as the key name and then the name/value pairs are key name and key value. I actually have a C++ class somewhere that does just that. To the outside it looks and acts like an INI file wrapper but it uses the Registry instead.

Edited by Andrue (Wed 26-Dec-12 17:27:39)

ideally it should be in the app folder in my view and it will then make this app easily portable.

I would like this app to not use an installer, stay out of program files completely, rather you just unzip to a dir and run it as is, and edit ini if needs be.

The problem being he wishes and needs to cater for different settings for the subnet, and the user needs to be able to set and modify this at will to cater for router changes. The rest of it I see as being relatively fixed so no reason not to be hard-coded.

Also, not being up-to-date with the why's and wherefore's of what you are saying, is there any problem with using the Program Data folder? That's assuming he intends to use a Windows installer to put the exe in a c:\Program Files directory.

I have the feeling he is thinking of dropping the whole lot into a folder in C:\, as per his existing scripts. Which should work fine.

In reply to a post by RobertoS:

I have the feeling he is thinking of dropping the whole lot into a folder in C:\, as per his existing scripts. Which should work fine.

Yes, that's about the jist of it.

The default folders (unless users wish to change them) will still be:-

C:\HG612_Modem_Stats (main folder)
C:\HG612_Modem_Stats\Scripts (that's where I also intend to store the compiled exe program)
C:\HG612_Modem_Stats\Apps (where all the graphing programs & other utilities are stored)
C:\HG612_Modem_Stats\Current_Stats
C:\HG612_Modem_Stats\Ongoing_Stats

In reply to a post by RobertoS:

Also, not being up-to-date with the why's and wherefore's of what you are saying, is there any problem with using the Program Data folder? That's assuming he intends to use a Windows installer to put the exe in a c:\Program Files directory.

It assumes everyone has Administrator rights. If only targeting home users that is fine, but for those of us who run Windows networks in corporates will hate you. Using your own c:\app directory (yuck its not a folder) is the best solution.

%progdir% has system default Access Control Lists on all operating systems, XP's is the weakest, Vista, 7, and 8 are all very good. Even home edition.

In reply to a post by Bald_Eagle1:

In reply to a post by RobertoS:

I have the feeling he is thinking of dropping the whole lot into a folder in C:\, as per his existing scripts. Which should work fine.

Yes, that's about the jist of it.

Meh. Well it's up to you and it's not a deal breaker

It's just that as a professional developer I've seen Windows security evolve from 'none' to 'very good if only people used it'. Your solution is simpler but it's a solution from a by-gone era when home computers were just that. These days they are corporate tools and attached to public networks. My instinct is to do the job properly if I can

Edited by Andrue (Wed 26-Dec-12 18:31:46)

Well, I now have the (still undergoing testing) new compiled.exe programs working with an ini file on Windows systems.

It is a very basic file so far, just for testing purposes:-

Text

1 23 45 67 89 1011 1213 1415 1617 1819

[Login] IP_address = 192.168.1.1Username   = admin Password   = adminShell      = sh  [Locations] Drive                = C:Main_folder          = C:\HG612_Modem_Stats Scripts_and_Programs = C:\HG612_Modem_Stats\ScriptsApps_folder          = C:\HG612_Modem_Stats\Apps Current_Stats_folder = C:\HG612_Modem_Stats\Current_StatsOngoing_Stats_folder = C:\HG612_Modem_Stats\Ongoing_Stats  [Mode] Mode=extensive  [Graphing]Auto_graph_Snapshot_data = YES

More configurable options will be added in due course.

Could anyone who is interested please let me know the details of how you would like to be able to configure the settings?

e.g. Harvest & store the data on a server yet plotting the output graphs on another PC, graph resolution, which graphs to actually plot, colours etc. etc.


EDIT:

Also, how does one get to show a backslash instead of the 'W' character in the code section?

Edited by deleted (Sat 05-Jan-13 16:48:48)