Newsgroup: it.comp.lang.visual-basic
Titolo: Alternative (****)

Volevo fare un Editor Hex, ma rispetto a sw commerciali, i tempi di apertura
e lettura file, con le funzioni PUT e GET sono scandalosi!!!
Esiste la possibilità di accellerare il processo, che ne so, magari
richiamando qualche funzione su una DLL nota???  Se si, Quali sono le DLL
che fanno queste operazin???
Grazie Grazie!!!!

 e lettura file, con le funzioni PUT e GET sono scandalosi!!!
come tempo di apertura e gestione file non sono poi cosě scandalosi,
potrebbe forse esserlo l'elaborazione...
Non č che sbagli qualcosa nell'apertura del file ? :)))
ciao
-------
sito: 
www.dadev.it
ultime: Ocx per irc testi freeware
-------

 richiamando qualche funzione su una DLL nota???
è semplice, fai come fa UltraEdit: blocchi il file su disco, e leggi di 
volta in volta solo la parte effettivamente mostrata su schermo. A che 
serve averlo tutto in memoria quando è già sul disco? Tanto è un hex 
editor, no? quindi ogni volta saprai esattamente quanti caratteri 
leggere
Chessò io, hai 20 righe e 20 colonne? leggi i primi 400 byte del file. E 
ti sposti su e giù per il file (con una scrollbar? pulsanti su-giù?) e 
di volta in volta leggi tot byte a partire da un certo byte. Non usando 
le funzioni di VB, finiresti in un bruttissimo vicolo cieco. Allora, le 
funzioni che ti servono sono:
Operazioni su file:
 CreateFile
 ReadFile
 CloseHandle
Allocazione di memoria (i byte array non so, non mi convincono):
 LocalAlloc
 LocalLock
 LocalUnlock
 LocalFree
La lettura del file sarà relativamente semplice, è con la scrittura che 
arriveranno i dolori...
Mi sono reso improvvisamente conto che il progetto ha un gran potenziale 
(d)istruttivo. Capire come funzionano cose come l'allocazione di 
memoria, le funzioni di Windows, spararsi in un piede... 
Dunque cambio il subject e inizio un thread didattico sulla costruzione 
passo-passo di un hex editor, con tutto quello che ciò comporta. 
Dedicato ai niubbi, aperto agli esperti
Però ora vado a dormire. Che è tardi

> Perņ ora vado a dormire. Che č tardi
vai a dormire alle 8 e 25 ??

 LocalFree
Perche' allocare dinamicamente memoria se sai gia' che la
misura del tuo buffer e' fissa ?
Se so che devo leggere 400 byte alla volta, mi basta avere
un array di dimensione fissa.
--
Naquern Yansbetevn
naquern.y...@africamail.com

 (d)istruttivo.
Ma noooo, basta non fare come ho fatto io qualche anno fa.
Volevo provare un mio programmino pascal-dos per la compressione RLE di
files, quindi mi serviva un file binario... chi meglio del 
command.com?.
..
Ciao

 wrote in message
klbb7.118611$Qf6.7...@news2.tin.it...


un array di dimensione fissa.
non ridimensioni mai finestre, tu?

vai a dormire alle 8 e 25 ??
alle 9 e 7. Per la precisione

non ridimensioni mai finestre, tu?
Non vedo, onestamente, cosa c'entri.
Io assumo, come dimensione dell'array, la misura massima di
simboli visualizzabili.  Poi, posso anche usarne meno.
--
Naquern Yansbetevn
naquern.y...@africamail.com

simboli visualizzabili.  Poi, posso anche usarne meno.
non esiste una "misura massima". Potrei anche pretendere un display 
65536*65536 caratteri, perchè no?

 65536*65536 caratteri, perchè no?
prechè non ci stanno tutti a schermo....
ciao!
Marco Trapanese

Bč... io una volta con un HexEditor ho modificato TUTTE le stringhe
all'interno dell'exe di DukeNukem 3D (ho cambiato pure le cheat ;) )... E'
grave secondo te? Ho l'attenuante che ero giovane... si sa... da giovani si
sbaglia :D
CiaoZ
SebaMix

 writes:
K:H> Non usando 
K:H> le funzioni di VB, finiresti in un bruttissimo vicolo cieco. Allora, le 
K:H> funzioni che ti servono sono:
Hmmm...Non usando le funzioni di VB e poi indichi delle call a sistema ?
Qualcosa non mi torna...
K:H> Operazioni su file:
K:H>  CreateFile
K:H>  ReadFile
K:H>  CloseHandle
K:H> Allocazione di memoria (i byte array non so, non mi convincono):
K:H>  LocalAlloc
K:H>  LocalLock
K:H>  LocalUnlock
K:H>  LocalFree
K:H> La lettura del file sarà relativamente semplice, è con la scrittura che 
K:H> arriveranno i dolori...
Hmmm... E  se si usassero  la CreateFileMapping() e  MapViewOfFile() ?
Sotto  9x  richiedono tanta  memoria  libera  quanta  è la  dimensione
dell'oggetto mappatura del  file che mi pare sia  almeno grande quanto
il file...
K:H> Mi sono reso improvvisamente conto che il progetto ha un gran potenziale 
K:H> (d)istruttivo. Capire come funzionano cose come l'allocazione di 
K:H> memoria, le funzioni di Windows, spararsi in un piede... 
Meglio rischiare di ferirsi un piede che castrarsi con l'ignoranza...
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

editor?). Puoi prevederlo grande quanto vuoi, non sarà mai abbastanza
Gli hex-editor li ho visti e onestamente sorrido di fronte
al fatto che con "buffer on-screen" tu voglia far credere di
star parlando di chissa' quale mostro intrattabile con
un'allocazione statica di memoria.  Io posso stabilire che
la mia applicazione visualizzi e gestisca 256/512/1024 byte
alla volta, dov'e', di grazia, il problema ?
--
Naquern Yansbetevn
naquern.y...@africamail.com

prechè non ci stanno tutti a schermo....
e che ne sai? metti che ho uno schermo 100000*100000 pixel? una specie 
di schermo a parete?

 di schermo a parete?
allora vivi in fahrenheit 451 :)