Newsgroup: it.comp.lang.visual-basic
Titolo: [?] RichTextBox; idea per colorare...

Ciao a tutti,
è mezzanotte e spero di non aver scoperto l'acqua calda :)
io non lavoro col VB ma con un altro linguaggio (inutile dirvelo non lo
conoscete :)
ma col Vb mi trovo spesso a risolvere un sacco di problemi accessori alla
programmazione per il gestionale che sviluppo..
Ora mi serve un editor per me e non per i miei clienti :)
e rimugginavo sull'idea dell'hilight del codice...
I sistemi che ho trovato sulla rete per l'hilight del codice in un editor
non mi soddisfavano,
con sorgenti di 1500 righe e passa erano lentissimi....
10 minuti fa mi è venuta un'idea....
mi chiedo:
perché non lavorare con dei replace sulle stringhe del testo piuttosto che
fare loops infiniti di selstart-sellenght-selcolor ?
se io lavoro sul testo RTF di una RichText e sostituisco "PAROLA" in "\cf2
PAROLA"
dovrei avere un codice molto più veloce, no?
questo è un testo RTF..aperto con un editor esadecimale..:
----------------------------------------------------
{\rtf1\ansi\ansicpg1252\deff0\deflang1040{\fonttbl{\f0\fswiss\fcharset0
Arial;}}
{\colortbl ;\red255\green0\blue255;\red255\green0\blue0;} >> si nota
chiaramente una tavola dei colori
\viewkind4\uc1\pard\f0\fs20 ciao\par.. >> non ancora decifrato
\cf1 PAROLA\par.. >> ecco il punto...\cf1 è il primo colore dichiarato in
tabella e \par è un car. di invio
\cf2\par..                  >> \cf2 secondo colore ed invio
ciao\cf0\par..}...
--------------------------------------------
l' idea sarebbe:
Testo = RT1.TextRtf
Testo = colora(Testo)
RT1.TextRtf = testo
calcolando che devo solo aggiungere la tabella dei colori in testa...non mi
resta che aggiungere alle parole da colorare il relativo tag...
certo così non risolvo tutto l'hilight, (vedi commenti e casi
particolari)...devo ancora ragionarci su
..ma credo che così sia molto + veloce
Vi scrivo per chiedervi se, secondo voi,  questa è una strada percorribile o
farei meglio a non sudarci troppo su....
Grazie :)
P.S.
è tardi e muoio dal sonno e domani lavoro, quindi non rispondo dei miei
gesti :) ,
se ho violato qualche regola del manifesto scusate..l'ho letto da poco enon
ancora assimilato del tutto
.. volevo condividere con voi questa intuizione pre-sonno... :)
Notte.........

 farei meglio a non sudarci troppo su....
Tecnicamente funziona di sicuro. Se non vuoi fare il "cut&paster",
buon lavoro :-)
Bye, G.

se ti puo' interessare ho fatto un ocx per un client irc dove all'interno
c'è un motore di gestione stringhe compatibile al 100% con Mirc questo vuol
dire che gestisce corsivo, grassetto colore di sfondo ecc, ma in particolare
permette di cambiare colore ad ogni singolo carattere di una parola (incluso
lo sfondo del carattere stesso).
Inoltre ho incluso il riconoscimento delle parole (sito e mail).
Il tutto fatto con il controllo Rich con un sistema molto simile a quello
che hai pensato.
Quindi buttando via tutto il resto di codice ti trovi un'editor quasi fatto.
Se è quello che ti serve puoi scaricarti il source dell'ocx da :
http://vbios.cjb.net
il nome dell'ocx è XROOM.OCX e lo trovi nella sezione Internet.
Ciao
                   _pixel_
p.i....@katamail.com
http://vbios.cjb.net

 dovrei avere un codice molto più veloce, no?
Si. L'unica cosa a cui devi prestare attenzione sono gli a_capo nel testo.
RTF è una standard anziano che risale a epoche quando era impensabile
caricare il testo tutto in una volta in memoria. Siccome il testo doveva
essere letto a blocchi, gli inventori hanno pensato bene di farlo spezzare
ogni tanto da dei CrLf. Ogni quanto però non è uno standard.
Alcuni programmi lo fanno ogni 256 caratteri, altri ogni 512, altri ogni
quanto gli pare (o almeno a me è sembrato di capire così).
Il CrLf in questione ti potrebbe capitare nel bel mezzo di una parola.
Quindi tu cerchi "PAROLA" per sostituirla con la tua stringa colorata, e
invece (non) trovi "PAR" & CRLF & "OLA"
Verrebbe da dire: "poco male, visto che il CrLf in RTF serve solo come
separatore, strippiamolo e basta". Invece non si può.
La maggior parte dei comandi Rtf, richiedono di essere seguiti da uno
spazio. Ad esempio "\b" se non ha uno spazio subito dopo non viene
interpretato come un comando RTF ma come una parte di testo.
Beh, quello spazio può essere sostituito dal CrLf in questione, quindi se
strippi i CrLf rischi di trasformare in semplice testo dei comandi RTF.
Allora magari lo possiamo sostituire con uno spazio? No, neppure questo. Se
il CrLf in questione fosse affogato nel semplice testo (come nell'esempio
più in alto in cui non avresti trovato "PAROLA"), se trasformi il CrLf in
spazio, questo spazio diventa magicamente visibile e ti spezza il testo.
E quindi?
E quindi per avere un testo RFT senza i maledetti CrLf, devi scriverti una
routine che passi tutto il testo e trasformi ogni CrLf in spazio solo se
tornando indietro nel testo trovi uno barra "\" e non hai spazi in mezzo. In
caso contrario devi eliminarlo.
Anche questo metodo non è perfetto, e potrebbe fallire in caso di presenza
nel tuo RTF del tag \bin che consente di inserire dei dati binari nell'RTF
stesso.
D'altra parte l'alternativa sarebbe scriversi un completo parser RTF, e
questo mi sembra davvero esagerato. Oltretutto di RTF col tag \bin finora
non ne ho mai incontrati, pur avendone visti davvero parecchi per conto di
un mio cliente.
Questo a mio parere è l'unico difetto dell'RTF che altrimenti come standard
sarebbe perfetto.
Buon lavoro
*Roby*

Comunque è già venuto in mente a qualcun altro :-)
eheh ne ero sicuro, ma mi fa solo piacere...non devo per forza inventarlo
io...mi basta risolvere il mio prob :)
------Risposta a _pixel_:
grazie anche a te _pixel_ l'ho già scaricato :)
------------Risposta a Roberto Piazzolla:
Ciao Roberto, non ti nascondo che mi sono un pò sgonfiato quando ho letto il
tuo post.... hehe...
ho fatto subito delle verifiche....ho creato un testo rtf di 12 MB...tutto
con la stessa lettera sempre ripetuta e non ho mai trovato un CrLf in mezzo
al testo....sai dirmi se questo si verifica solo in particolari condizioni
di formattazione? o è sempre fisso ogni tot caratteri?
Raga, vi ringrazio ancora, se arrivo a qualcosa di stabile e veloce ve lo
posto....sempre che vi interessi :)
buona serata :)
kudo

 posto....sempre che vi interessi :)
a me interessa .... fammi sapere!!!
CIAO

 fare loops infiniti di selstart-sellenght-selcolor ?
Non credo funzioni :)
Ci avevo pensato anch'io, ma a parte casi strani (es: commenti multilinea
alla C o multilinea VB) ci sono anche problematiche del tipo:
Evidenzio la parola chiave FOR:
FOR i = 1 to NumeroFORnitori
    strPI(i) = FORmat$(intPartitaIva, "00000000000")
Next i
Il metodo migliore credo sia usare il tuo sistema ma non con un semplice
replace, ma con le regular-expression.
Purtroppo non so dirti altro perchè non le ho mai usate.
P.S.: per info sullo standard RTF trovi parecchio in MSDN.
Ad es. prova a cercare "Character Text RTF" (senza virgolette)
Ciao

Mi metto subito in cerca...
Grazie... :)


 al testo....sai dirmi se questo si verifica solo in particolari condizioni
L'inserimento del CrLf a caso avveniva sicuramente con Word 2, e Word 97. Ho
fatto qualche prova con Word 2000 e il CrLf viana ancora salvato, ma pare
che non spezzi più i testi (lo mettono al posto di uno spazio).
In ogni caso se guardi la documentazione dei .RTF ci trovi il riferimento al
CrLf come "noisy character".
Come hai creato l'RTF tu?
Ciao e scusa il ritardo per la risposta.
*Roby*

 Come hai creato l'RTF tu?
L'ho creato da vb con una RichTextBox versione 1 ed il relativo comando
savefile...
Ciao..... :)

 savefile...
Ah ecco. Il problema in questione io ce lo avevo per un prodotto che usava
Word per le stampe, affogando all'interno di documenti base RTF dei tag
testuali, che venivano poi processati e sostituiti con il dato finale
all'atto della generazione del documento effettivo. Una specie di mailmerge
di basso livello, che però funzionava con qualunque editor RFT l'utente
avesse a disposizione.
Lì era emerso il problema del CrLf. Il RichTextBox non poteva essere usato
all'epoca, sia per il limite di dimensione (si trattava di VB4 a 16 bit),
sia perché il RichTextBox non supporta la giustificazione del testo.
Ciao
*Roby*

 sia perché il RichTextBox non supporta la giustificazione del testo.
Non supportaVA ;-)
Un Paperino che ci sta ancora combattendo... per non
parlare della sillabazione. Però funziona.

 Non supportaVA ;-)
Stai parlando della versione 2 (che però è ridistribuibile, o sbaglio?)
Oppure ti sei inventato qualche altra cosa?
Ciao
*Roby*

"Roberto Piazzolla" ha scritto nel messaggio

Leggi il post nel 3ad "come usare Riched20.dll". Se hai le dll giuste
puoi attivare la giustificazione con un paio di SendMessage.
Il che (credo) è proprio quello che fa il controllo di Morcillo.
Io ci ero arrivato frugando sull'MSDN, e con l'aiuto di codice
trovato su un sito giapponese... :-)
Se ti interessa fammi un fischio.
P.S.: quegli arrosticini... ;-)
Bye, G.

 P.S.: quegli arrosticini... ;-)
Si freddano, eh? :-)
E' che al lavoro si somma lavoro. Segue mail...
Ciao
*Roby*

 Leggi qui: 
http://www.codeguru.com/mfc/comments/1783.shtml
Ma la 3.0 sě:
 
http://www.codeguru.com/mfc/comments/34179.shtml
:-PP
E in ogni caso, il problema si pone solo nel w95 prime versioni,
dall'osr 2 fa parte del sistema (e oltretutto č in una MAREA di
applicazioni). Ricontrollando su:
http://support.microsoft.com/servicedesks/fileversion/dllinfo.asp?sd=MSDN
esce fuori che la prima versione era:
*****
FILE INFORMATION: Name: riched20.dll
Description: Rich Text Edit Control, v2.0  [CUT]
PRODUCTS CONTAINING THIS VERSION:
Windows 95 OSR 2    385,536    6/24/1996    win95_22.cab\setupslt.exe
Windows 95 OSR 2.5    385,536    6/24/1996    win95_22.cab\setupslt.exe
*****
E altrettanto per le versioni successive dei vari OS.
Bye, G.