Translhextion .NET (nuova versione)

[Gemini]

In questi giorni mi è saltato in testa di voler prendere Translhextion e potenziarlo per essere un pochino più professcional e portarlo alla edizione 2.0. Avrei già qualche idea in mente per modificarlo come si deve, anche se alla fine si tratterebbe di riscriverlo da 0 con MFC più che modificarlo semplicemente. Vorrei però che proponeste idee per renderlo più flessibile e adattabile alle esigenze di un po' tutti o magari semplicemente più carino.

Insomma, PROPONETE, PROPONETE e PROPONETE ANCORA! Anche le cose più strane vanno bene, basta che ci sia almeno l'idea.

Vediamo cosa potrebbe uscirne fuori. :ph34r:

Vi ringrazio per la possibile collaborazione. :clomax mode:  

[mentz]

Migliorare la ricerca del testo e dei byte (perché funziona male...)

Migliorare il reinserimento (perché è lentissimo)

Dovrebbe segnalare eventuali conflitti nella table che possono portare a errori nel reinserimento...

[Vash]

forse è una cavolata, ma per a chi ha "poca" ram translextion non apre file più grossi di 10-20 mega...si potrebbe provare a eliminare o a diminuire questo difettaccio

[mentz]

Basta aggiungere RAM...

Come puoi aprire un file più grande della tua ram disponibile ?

[|GeO|]

Si può, basta vedere il searchr di chop... (Come mi disse tempo fa pixel basta usare gli handle).

[Syxtem]

Le uniche cose che mi vengono in mente sono 3 (che mancano per rendere il prog perfetto):
- fare in modo di poter aprire anche file più grossi della quantità di ram disponibile.
Teoricamente non è impossibile... basta dire al prog che deve considerare il file come una serie di blocchi da una certa dimensione e a seconda della posizione del file, leggere da un certo blocco (chiaramente la cosa va espansa per supportare ricerche o altre operazioni a tutto il file)
- correggere il caricamento delle tbl che a volte scazza del tutto e fa piantare il programma al momento dell'attivazione (soprattutto con file di una certa dimensione)
- inserimento byte con TBL, immediato (come fa Hex Workshop per le sue tabelle)

E queste sono le cose più importanti...
Poi non sarebbe male sviluppare una bella mascherina che ti scrive i dati su cui si è posizionati in Intero, Float, Signed Double, Byte... e tutti gli altri.
E infine penso sarebbe molto carino un sistema di conteggio byte (per la lunghezza della frase) integrato e funzionale.

Queste diciamo che sono le mie esigenze per un programma coi controfiocchi. L'unica cosa che mi chiedo è se tu sia in grado di fare tutto ciò. In fondo mi pare che non è da tanto che lavori con programmi in C per Windows. Già per fare un programma contatore di frasi un po' decente, che confronta le lunghezze delle frasi di due edit e restituisce un risultato colorato a seconda del risultato stesso, ci vogliono alcune conoscenze che non sono proprio così alla mano.  :rolleyes:
Con questo io non voglio scoraggiare nessuno... è solo che ho paura tu stia sottovalutando quello che ti stai proponendo di fare. È un progetto di un certo rilievo, che richiede molto tempo, costanza e discrete conoscenze tecniche.

[|GeO|]

Il conteggio dei byte sarebbe utile anche per il reinserimento di script...

[Sephiroth 1311]

Aggiungerei una modifica al layout dei dump.
Hai presente come sono ora, no?
Ecco, invece dello spazio, in bel <Textblock X> non sarebbe affatto male.

[Gemini]

Riepilogando:
1) Apertuna veloce dei file grossi
2) Fissaggio dei vari metodi di ricerca
3) Migliore gestione delle table con salvaguardia da possibili errori
4) Velocità di reinserimento maggiore
5) Modifica al formato dei dump
6) Aggiunta del riconoscimento dei valori secondo base char, short, long, float, etc...
7) Cambio del nome del programma in Transhexual

La prima è facilmente fattibile. Basta riciclare l'idea di base dietro gli odierni editor esadecimali, ovvero userò un bel buffer per contenere i dati e altri eventuali buffer extra per sezioni di file modificate.
La seconda sarà un po' difficile, anche perché per implementare un buon metodo di ricerca bisognerà creare un bel codice sicuro al 100%. Spero di non doverlo appesantire troppo...
Tre, quattro e cinque sono dei punti decisamente interessanti. Stavo pensando di riscrivere quasi completamente il sistema di table per fare qualcosa di più serio. Mi spiego meglio: alcuni giochi usano particolari flag per identificare funzioni di gioco lanciate direttamente da script, esempio un ritardo sul testo, esecuzione di una musica di sottofondo o altro, per cui una semplice table creerebbe confusione nel caso in cui questi flag dovessero avere degli argomenti (es: byte 01XX, dove XX è la canzone da caricare. Se la canzone dovesse essere 00 e il byte di end verrebbe a coincidere, si otterrebbe un problema di equivoco nell'interpretazione). Praticamente più che semplici table sarebbero dei mini script da interpretare. Ammetto che la cosa non è facilissima da inserire, ma il risultato sarebbe davvero fantastico e praticissimo, soprattutto per chi si trova scomodo con gli attuali dump di Translhextion, come me. Per chi avesse idee su come scrivere questo formato, fate sapere. Sarebbe carino vedere le vostre esigenze anche in questo ambito per creare un formato fatto un po' da tutti.
La sei non è proprio nuovissima, visto che la vecchia versione più o meno presentava già questa caratteristica, anche se si limitava solo a Byte (char), Word (short) e Long, e in effetti non sevirebbe a molto inserire altri valori, ma alla fine non è nemmeno un grosso problema implementare, per cui vedrò cosa fare di questo punto.
La sette ovviamente è falsa. :°D

C'è questa richiesta però che non ho capito:

- inserimento byte con TBL, immediato (come fa Hex Workshop per le sue tabelle)

Mi spieghi esattamente cosa intendi? Non ho presente questo tipo di funzione, non esattamente almeno.

Anche questa è ambigua:

E infine penso sarebbe molto carino un sistema di conteggio byte (per la lunghezza della frase) integrato e funzionale.

Intendi un conteggio sul numero di caratteri/larghezza in pixel per linea oppure un sistema per non sforare il numero massimo di caratteri? In entrambi i casi comunque non sarebbe difficile da inserire.

Per il resto dovrebbe essere tutto a posto. Stasera vedo di costruire almeno il vestitino al programma e di implementare qualcosa.

[Syxtem]

Significa che ora (almeno da quanto ho potuto vedere io... è passato tanto tempo dall'ultima volta che ho provato il programma), per inserire dei byte che fanno riferimento ad uno TBL bisogna ricorrere ad una barra che ti fa inserire prima lì i valori etc...
Il top sarebbe fare in modo da poter scrivere subito i caratteri nel programma, senza doverli mettere in questa nuova finestrella per l'inserimento.
Capito ora?

Per il conteggio io avevo pensato più ad un conteggio di lunghezza stringhe (o se vogliamo qualcosa riferito a tutto il file come "DimensioneFileModificato/DimensioneFileOriginale [Differenza]".
L'altra cosa mi sa più da utility esterna che qualcosa da inserire nell'editor a tutti i costi.

Poi, immaginando che il punto 7 sia la mia considerazione finale, se per te si tratta di una cavolata tanto meglio  
Io mi ricordo che personalmente ci rimasi un po' male quando capìi che casino dovevo fare solo per far cambiare colore ad una label.  :rolleyes:  

[|GeO|]

Ehi, non vi dimenticate il conteggio byte su reinserimento da file, ogni volta mi scazza vedere se sovrascrive i pointer o altra roba. =\

Ps: il nuovo nome è carino, xD

[yuumeikai]

Per le ricerche esistono tanti metodi e algoritmi di ricerca anche molto potenti (ora, non so quale algoritmo usi Translhextion) come l'albero binario di ricerca, etc, etc.

Su uno dei libri che ti ho prestato, questo argomento è ampliamente trattato, con inclusi i sorgenti di vari metodi di ricerca.

[|GeO|]

I libri del primo anno dovrebbero trattare sorting e ricerca, vero?

[Syxtem]

Ma come intendete sfruttare gli ABR?  :blink:
Insomma... come ricerca sarà anche veloce (logN), ma analogamente alla ricerca dicotomica, non è possibile utilizzarla sempre.
L'ABR è costruito inserendo nella radice un valore, nel sotto albero di sinistra un valore minore della radice e in quello di destra un valore maggiore (e ciò vale per ogni sottoalbero visto come albero). Cosa pensate di utilizzare come "valore" per costruire l'albero? Inoltre bisogna tenere anche a mente che ci vuole un po' di tempo per la creazione dell'albero e che occupa anche memoria del sistema.
Cioè, sono daccordo anche io che ad esempio una ricerca tramite ABR sarebbe molto più veloce, ma non sono riuscito a capire come si possa implementare ciò per una ricerca in un editor esadecimale.
Essendo il contenuto di un editor esadecimale come quanto di più eterogeneo ci possa essere, secondo me la ricerca sequenziale è l'unica alternativa.
Se sapete come fare, sarei felice di essere smentito... mi piacerebbe impararne di più al riguardo    

[yuumeikai]

Cioè, sono daccordo anche io che ad esempio una ricerca tramite ABR sarebbe molto più veloce, ma non sono riuscito a capire come si possa implementare ciò per una ricerca in un editor esadecimale.

Proprio perché so quanto sono potenti e veloci l'ho proposto.
Non sono io a doverlo implementare