Una detalle sobre ficheros INI

[Bingen Ugaldebere]

Estoy trabajando mucho con ficheros INI y cuando son muy grandes si
quiero leerlos es complicado más que nada por que las secciones se
encuentran todas juntas sin espacios en medio.
No veo manera de añadir un espacio en el medio de dos secciones como en
la mayorí­a de los INI que hay en Windows lo cual facilitarí­a su lectura.
No es que sea imprescindible pero para una futura versión no estarí­a mal.
Muchas gracias.

[ignacio]

Bingen,
Me temo que el tratamiento interno de los ficheros es realizado
completamente por el API de Windows y nosotros no podemos hacer nada al
respcto. Lo siento.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Bingen Ugaldebere" <bingen@muninser.com> escribió en el mensaje
news:471610f1$[email=1@ozsrv2.ozlan.local...]1@ozsrv2.ozlan.local...[/email]
> Estoy trabajando mucho con ficheros INI y cuando son muy grandes si quiero
> leerlos es complicado más que nada por que las secciones se encuentran
> todas juntas sin espacios en medio.
>
> No veo manera de añadir un espacio en el medio de dos secciones como en la
> mayoría de los INI que hay en Windows lo cual facilitaría su lectura.
>
> No es que sea imprescindible pero para una futura versión no estaría mal.
>
> Muchas gracias.

[xAvi]

Bingen,
Prueba a crear la estructura de las secciones tú si te es tan importante antes de atacarlo con el Api, por ejemplo con.-
Local cFileINI := Application:cDirectory + 'File.ini'
if( !File(cFileINI) )
MemoWrit( cFileINI, e"[SECCION_1]rn rnrn[SECCION_2]rn rnrn[SECCION_X]rn" )
endif
WITH OBJECT TIni():New( cFileINI )
:SetEntry( 'SECCION_2', 'DATA', 'Hola' )
LogDebug( :GetEntry( 'SECCION_2', 'DATA', '' ) )
END
El Api sólo modifica no reescribe.
Un saludo
Xavi

[Bingen Ugaldebere]

Muy ingenioso, a veces la solución mas tonta es la mas efectiva.
Gracias.
xAvi escribió:
> Bingen,
>
> Prueba a crear la estructura de las secciones tú si te es tan importante
> antes de atacarlo con el Api, por ejemplo con.-
>
> Local cFileINI := Application:cDirectory + 'File.ini'
>
> if( !File(cFileINI) )
> MemoWrit( cFileINI, e"[SECCION_1]rn rnrn[SECCION_2]rn
> rnrn[SECCION_X]rn" )
> endif
> WITH OBJECT TIni():New( cFileINI )
> :SetEntry( 'SECCION_2', 'DATA', 'Hola' )
> LogDebug( :GetEntry( 'SECCION_2', 'DATA', '' ) )
> END
>
> El Api sólo modifica no reescribe.
>
> Un saludo
> Xavi

[Bingen Ugaldebere]

O me creo el INI y luego le paso esta función que acabo de cavilar.
FileStrTran( ".DataEjemplo.Ini" , "[" , CRLF+"[" )
Function FileStrTran(cFile,cOriginal,cSubstitute)
Local nItem:=0, cText2:=""
If !File(cFile)
Return .F.
Endif
CursorWait()
cText:=Memoread(cFile)
FOR nItem := 1 TO MLCOUNT(cText)
cText2+=StrTran(MEMOLINE(cText,,nItem),cOriginal,cSubstitute )+CRLF
NEXT
MemoWrit(cFile,cText2)
CursorArrow()
Return .T.
Salu2.

[xAvi]

Bingen Ugaldebere escribió:
> FOR nItem := 1 TO MLCOUNT(cText)
> cText2+=StrTran(MEMOLINE(cText,,nItem),cOriginal,cSubstitute )+CRLF
> NEXT
>
Nada, como me aburro: ver post "Re: Nuevo comportamiento del IDE". Prefiero debatir sobre algoritmos de programación.
Esto es un desastre. Menos malo será en un futuro si se aprueba FIXE.-
FOR nItem := 1 TO MLCOUNT(cText) FIXE
Y si bajamos a la capa C, tela marinera la de instrucciones desperdiciadas.
IMHO: Si asumimos que no existen corchetes en los datos del ".INI", más efectivo será.-
Function FileStrTran(cFile,cOriginal,cSubstitute)
Return iif(File(cFile), MemoWrit( cFile, StrTran( Memoread(cFile), cOriginal, cSubstitute ) ), FALSE)
Un saludo
Xavi
PD: Pruébame el IDE 1.76, por favor, que si la he pifiado me gustarí­a saber dónde. :'(

[Bingen Ugaldebere]

Si luego me he dado cuenta, lo que hace el copiar y pegar de otro lado y
quitar 2 cosas.
Por cierto el tamaño máximo de una variable en clipper era de 64Kb pero
en xHb de cuento es?
Salu2.
xAvi escribió:
> Bingen Ugaldebere escribió:
>> FOR nItem := 1 TO MLCOUNT(cText)
>> cText2+=StrTran(MEMOLINE(cText,,nItem),cOriginal,cSubstitute )+CRLF
>> NEXT
>>
>
> Nada, como me aburro: ver post "Re: Nuevo comportamiento del IDE".
> Prefiero debatir sobre algoritmos de programación.
> Esto es un desastre. Menos malo será en un futuro si se aprueba FIXE.-
>
> FOR nItem := 1 TO MLCOUNT(cText) FIXE
>
> Y si bajamos a la capa C, tela marinera la de instrucciones desperdiciadas.
> IMHO: Si asumimos que no existen corchetes en los datos del ".INI", más
> efectivo será.-
>
> Function FileStrTran(cFile,cOriginal,cSubstitute)
> Return iif(File(cFile), MemoWrit( cFile, StrTran( Memoread(cFile),
> cOriginal, cSubstitute ) ), FALSE)
>
> Un saludo
> Xavi
> PD: Pruébame el IDE 1.76, por favor, que si la he pifiado me gustarí­a
> saber dónde. :'(

[xAvi]

Bingen Ugaldebere escribió:
> Por cierto el tamaño máximo de una variable en clipper era de 64Kb pero
> en xHb de cuento es?
>
Buena pregunta. Pues no lo sé, serí­a cuestión de preguntárselo a Patrick.
Si te refieres a "Strings", el xharbour que estoy utilizando en teorí­a ULONG_MAX que en BCC Win32 es 4294967295 bits.
Aunque mi lí­mite "mental al utilizar algoritmos de terceros" para strings no supera (INT_MAX - 1) 2.147.483.646 bits en Win32
por si acaso y no está de más pegarles un vistazo antes si la cosa se va a aproximar a ese lí­mite.
¿Nadie está utilizando el IDE de la 1.76.?
Ignacio, por favor, dime si al menos has reproducido el error o es un problema mio.
Un saludo
Xavi

[jfgimenez]

Xavi,
>> Por cierto el tamaño máximo de una variable en clipper era de 64Kb pero
>> en xHb de cuento es?
>>
>
> Buena pregunta. Pues no lo sé, sería cuestión de preguntárselo a Patrick.
> Si te refieres a "Strings", el xharbour que estoy utilizando en teoría
> ULONG_MAX que en BCC Win32 es 4294967295 bits.
> Aunque mi límite "mental al utilizar algoritmos de terceros" para strings
> no supera (INT_MAX - 1) 2.147.483.646 bits en Win32 por si acaso y no está
> de más pegarles un vistazo antes si la cosa se va a aproximar a ese
> límite.
En 32 bits, el límite teórico es de 2^32, o lo que es lo mismo, 4GB ó
4294967296 bytes. Pero ese es el límite teórico, que en la práctica no es
alcanzable. Concretamente, los procesadores de 32 bits mantienen una
limitación real de 1GB de memoria por proceso, y para superar dicho límite
hace falta montar un pollo de cuidado. Se supone que los procesadores de 64
bits funcionando en modo 32 bits no tienen esa limitación, pero no estoy
seguro.
Por supuesto, los procesadores de 64 bits funcionando en modo 64 bits tienen
un límite muchísimo más alto: 2^64 o un porrón requeteporrón de bytes (lo
siento, pero mi calculadora da 'overflow' )
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info