I do precisely that in all my apps. I place a small text file (I call it
knet.ini, so smart ass users won't touch it) that contains the path and other
variables that are then read by the main program, using execscript. See the
following example:
PROCEDURE MAIN
close databases
close tables all
clear memory
DO SETSCREEN
set path to ( _screen.cPath )
set default to ( _screen.cDefault )
Set Classlib to controles.vcx additive
set classlib to formularios.vcx additive
set classlib to especial.vcx additive
set classlib to _base.vcx additive
set classlib to _datetime.vcx additive
(some more statements in here)
application.visible = .f.
on shutdown do getout
Do form principal name oPrincipal linked && showwindow = 2 (top level
form)
read events
On Shutdown
ENDPROC
PROCEDURE SETSCREEN
public cServer,cLocald,cPath,cDefault
with _screen
EXECSCRIPT( FILETOSTR( FULLPATH( "knet.ini" ) ) ) && reads every line in the
KNET.INI file, one by one
.addproperty("cServer",cServer)
.addproperty("cLocald",cLocald)
.addproperty("cPath",cPath)
.addproperty("cDefault",cDefault)
.addproperty("cDataBase",Addbs(cServer)+"datos.dbc")
.fontname = 'foxfont'
release cServer,cLocald,cPath,cDefault
endwith
ENDPROC
**KNET.INI file (this contains all the properties read by the main program)
cPath =
"c:\yourapp\tables;c:\yourapp;forms;reports;classes;prog;graphics;menus"
cDefault = "c:\yourapp"
cServer = "c:\yourapp\tables"
cLocald = "c:\yourapp\temp"
In the setscreen procedure I declare all variables to be read from KNET.INI
file as public, so they are briefly in scope for the EXECSCRIPT function to
work properly and then I release them, because they are not needed. Instead,
those variables are made properties of the _screen object, which is the only
"public" object, available to all forms and functions in the application.
The knet.ini file can easyly be changed using the notepad, as you want. If you
have inquisitive smart ass users that will touch everything and screw up things
in the process, you can complicate things for them a little bit, by using a
KNET.DBF file instead, containing one memo field and one record. In there you
put everything you find in the KNET.INI file (don´t forget the carriage return
at the end of each line)
You can then substitute the one line with the execscript function above with
these ones:
Use c:\yourapp\knet.dbf
go top
ExecScript(cpath) && the memo field name is cpath
Use in knet
Rafael Copquin
www.copquin.com.ar
----- Original Message -----
From: John Weller
To: [EMAIL PROTECTED]
Sent: Friday, March 16, 2007 5:55 PM
Subject: INI Files
I'm having a real brain stall here! I'm trying to write a simple routine to
read and write to an ini file. I had a sample piece of code years ago but
it is so long since I used it I've lost it. I have an app which only uses
two pieces of data, a source path and a target path. I thought that it
would be convenient if the user could edit them with notepad so decided to
use an ini file. I've found the definitions fro GetPrivateProfileString and
WritePrivateProfileString but I'm blowed if I can make them work! Does the
ini file have to exist to write to it or will it create one; also the
section? Anyone got some sample code out there that I could copy.
TIA
John Weller
01380 723235
07976 393631
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
