Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailemVyřešeno RichEdit v Delphi - efektivní rozlišení slov (syntaxe)

Zdravím,
řeším rozlišení slov(syntaxe) v RichEditu - mám to již funkční - používám vlastnost RichEditu SelAttributes - takže procházím znak po znaku, skládám je do slov a pokud je vybrané slovo v tabulce klíčových, označím jej pomocí SelStart + SelLength a vlastností SelAttributes nastavím požadovaný styl. Problém nastává při rozlišování většího objemu dat - když procházím a rozlišuji např: 35-ti kilový text, už to trvá asi 20 vteřin, což mi příjde moc a navíc to zdržuje.
Nezná tedy někdo jiný efektivnější způsob rozlišení slov než dle výše zmíněného postupu?

Děkuji ;-)

Předmět Autor Datum
Akym sposobom prechadzas znak po znaku? (volas pre kazdy znak funkciu richeditu?) ak ano tak zavolaj…
MM.. 16.04.2008 15:48
MM..
No jedu znak po znaku z toho richeditu RichEdit.text[i] ... Dělal jsem to předtím tak jak píšeš - v…
mrazek 16.04.2008 19:30
mrazek
Dolezite je poslat co najmenej sprav tomu richeditu. Kedze to programujes cez nejaky objektovy frame…
MM.. 16.04.2008 19:42
MM..
Tak jsem upravil to hledání slov v RichEditu tak, aby to co nejvíc hledalo v paměti a docela se to z…
mrazek 16.04.2008 22:26
mrazek
A ak ten script tahas z nejakeho txt suboru, tak este je ina moznost: nacitas si ten txt subor do pa…
MM.. 16.04.2008 19:58
MM..
:-) Nemusis chodit dalko, pokud se nepletu, tak pouziva jinou komponetu a tusim, ze i nekde zverejni…
AZOR 17.04.2008 01:05
AZOR
pokud je jen malo klicovejch slov a ma to bejt neco jako program na jedno pouziti - pak bych premesl…
AZOR 17.04.2008 01:09
AZOR
Takhle mi to fungovalo na počátku - používal jsem funkci RichEdit.FindText - a hledal jsem jednotliv…
mrazek 17.04.2008 08:51
mrazek
Add) první část - ano, nemuselo to být rychlejší, psal jsi, že máš malý počet klíčových slov, asi ne…
AZOR 17.04.2008 14:09
AZOR
Richedit je na zvýrazňování syntaxe dost nešťastné řešení. Představ si, že máš dlouhý zdroják, pracn…
Jan Fiala 17.04.2008 08:38
Jan Fiala
Kruci fix ted jsem chtel o tom Syneditu napsat aspon sem hodim link, synedit :puff:
virus 17.04.2008 09:12
virus
Dík, za tip - vyzkouším ten SynEdit ;-) Pes: kdybych chtěl rozlišovat jen viditelný text tak aby to…
mrazek 17.04.2008 12:57
mrazek
Ak chces zvyraznovat len viditelny text tak nepouzijes ziaden richedit, zvyraznovanie sa robi pri vy…
MM.. 17.04.2008 13:30
MM..
A já jen dodám, že vlastní vykreslování v RichEditu bych teda opravdu dělat nechtěl... ;-)
Jan Fiala 17.04.2008 15:08
Jan Fiala
V tom vykreslování v RichEditu nevidím problém, akorát je naprd ta rychlost ;-) Jo, kdybych se rozh…
mrazek 17.04.2008 19:10
mrazek
V tom vykreslování v RichEditu nevidím problém, akorát je naprd ta rychlost Já jsem nemluvil o nast…
Jan Fiala 17.04.2008 19:41
Jan Fiala
Tak to jsem špatně pochopil... ;-) K tomu balíku SynEditu - dík za radu, prubnu :-) A jinak pravda…
mrazek 17.04.2008 20:26
mrazek
Odsraneni baliku NetMaster a nahrazeni balikem INDY, odstraneni QuickReport a nahrazeni RaveReportem…
Jan Fiala 17.04.2008 20:50
Jan Fiala
Pravda je, že s balíkem NetMaster ani nynějším INDY nedělám, QuickReport jsem kdysi používal, ale už…
mrazek 17.04.2008 22:09
mrazek
V době, kdy BDE vyšlo ses mohl připojovat maximalně přes ODBC, popř. později přes problematicke ADO…
Jan Fiala 17.04.2008 22:21
Jan Fiala
S tím BDE jsem to asi napsal nešťastně a sám jsem ho nepoužíval, ale asi 2x jsem byl nucen rozjet ně…
mrazek 17.04.2008 22:43
mrazek
Celkem jsme odběhli od tématu ;-) Každopádně děkuji všem zúčastněným za cenné informace, které mi do… poslední
mrazek 20.04.2008 19:27
mrazek

Akym sposobom prechadzas znak po znaku? (volas pre kazdy znak funkciu richeditu?) ak ano tak zavolaj gettext len raz a uloz si cely string a prechadzaj si string v pamati.

Inac ak robis nejaky editor tak je lepsie zobrazovat si obsah okna sam (grafickymi funkciami), nepouzivat richedit ani iny edit, su na take veci moc tazkopadne a drzia si obsah okna vo vlastnej pamati co nie je moc dobre (nechcem si predstavit co bude robit richedit ak do neho nacpes 10MB textu).

P.S. este sa mi nieco mari (neviem teraz zhlavy) ze richedit ma atribut, ze ci ma scrollovat obsah okna na aktualnu selection, skus to najst, ak to najdes tak to by som vypol.

No jedu znak po znaku z toho richeditu RichEdit.text[i] ...
Dělal jsem to předtím tak jak píšeš - v paměti jsem hledal ty slova a pak je označoval v tom "richi", ale nepřišlo mi to nějak rychlejší a přišlo mi to jako takové lámání přes koleno...
Ale je pravda, že od té doby tam dost věcí přibylo, takže to tak možná zkusím ještě jednou a dám si na tom víc záležet :-)
Jinak nejde o žádný editor, prostě potřebuju rozlišovat slova ve scriptech, které případně upravuju a pak spouštím(líp se s nimi pracuje, když jsou zvýrazněné klíčové slova).
Navíc tyhle scripty 10MB nebudou mít asi nikdy - odhaduju, že půl mega je až až ;-)

Dolezite je poslat co najmenej sprav tomu richeditu. Kedze to programujes cez nejaky objektovy framework (v tvojom pripade delphi) tak nevies kontrolovat kolko sprav a kedy sa poslu, robi to u teba ten objekt RichEdit. Ak by si si chcel byt isty ze posielas co najmenej sprav, tak si zisti HWND tvojho richeditu a posielaj mu spravy sam :-) (http://msdn2.microsoft.com/en-us/library/bb787877(V S.85).aspx - popis sprav pre richedit, v podstate staci jedna sprava pre oznacenie vyseku a jedna sprava pre nastavenie farby).
Predpokladam ale ze kazde RichEdit.text[] posle spravu, takze ak si nacitas naraz (nie po pismenach) cely text do nejakeho stringu a prezeras si string tak to moze byt rychlejsie.

inac myslim ze by si si mal overit (napr. zakomentovanim tych operacii nastavenia farieb) ze co tam zere tolko casu. Ze ci
a) praca s richeditom (to oznacovanie vyseku a nastavenie farieb)
alebo ci
b) to tvoje porovnavanie s klucovymi slovami.
Pretoze si viem predstavit ze tolko trva to porovnavanie s kluc.slovami, ak to nie je urobene optimalne (priklad ak mam 30000 pismen a pre kazde zavolam nejaky string compare s 1000 kluc.slovami, tak to je dohromady 30milionov krat stringcompare... apod) A si predstav ze co ked tam budes mat pol miliona pismen... (pol miliardy krat stringcompare ak mam 1000klucovych slov :)

V pripade b) by stala potom otazka uplne inac (ako urobit porovnavanie s kluc.slovami)... :)

P.S. a ako som uz pisal v predch.prispevku, vlasne vykreslovanie textu je (IMHO) v tvojom pripade omnoho vyhodnejsie (pretoze potom mas kontrolu nad tym ktory vysek vykreslujes, a staras sa / farbis len ten vysek, nie cely 0.5MB script). Podla mna urobit vlastne vykreslovanie textu nie je zlozite, urcite mas v delphi aj fcie aj na vykreslenie textu na canvas apod. ...ale ak to ma mat aj moznost editacie tak to je uz zlozite, to hej...

Tak jsem upravil to hledání slov v RichEditu tak, aby to co nejvíc hledalo v paměti a docela se to zrychlilo(asi 3x). ;-)

Jinak k tomu prohledávání - nehledám pro každý znak v tabulce klíčových slov - mám definované specielní znaky, které oddělují jednotlivá slova, takže ikdyž procházím text po znacích, hledat resp. srovnávat slovo s klíčovými začínám až v okamžiku, kdy jsem "poskládal" celé slovo od jednoho specielního znaku k druhému - takže ta složitost je o dost menší...

Klíčových slov taky není tolik, ale navíc je hledám v listu, který používá "binární" hledání(půlením intervalů v sesortovaném seznamu), takže to taky až tak nezhoršuje čas rozlišení.

A k tomu rozlišení jen části kódu, která je vidět - nad tím jsem taky přemýšlel, ale bál jsem se následného zpomalení samotného posunu v textu...

Navíc neustále potřebuju i rozlišený text měnit - můžu do něj dopisovat jednotlivé znaky, ale i vkládat větší kusy kódů.(rozlišení syntaxe "real time" při psaní textu mám vymyšleno a pracuje to rychle a bez problémů 8-) )
Problém nastává vyloženě při prvním otevření většího souboru kódů, pak už to frčí.

Ale s tím množstvím posílaných zpráv do RichEditu máš pravdu to ještě upravím :-)

Zatím díky za tipy ;-)

A ak ten script tahas z nejakeho txt suboru, tak este je ina moznost:
nacitas si ten txt subor do pamate, a sformatujes ho priamo v pamati do rtf formatu (scanujes jeden string v txt formate a zapisujes do noveho stringu v rtf formate). A az potom to cele (v rtf formate) z pamate nacpes naraz (nie po pismenach) do richeditu.

P.S. ale ak uzivatel v tom richedite nieco zmeni (dopise pismeno alebo zmaze apod) tak budes musiet robit kontrolu na format po kazdom napisanom pismene (budes si musiet zadefinovat hook alebo ako sa to robi v delphi, aby ti volalo nejaku fciu vzdy ked tam uzivatel nieco zmeni), ale kontrolujes len tam kde je momentalne kurzor takze to by sa dalo. Ale nie je to easy...

P.S.2. rtf format vcetne linku na specifikaciu Rich_Text_Format

:-) Nemusis chodit dalko, pokud se nepletu, tak pouziva jinou komponetu a tusim, ze i nekde zverejnil nazev. Rozhodne bych se s richeditem nepatlal a hledal bych pro to specialni komponentu, ktera syntaxi uz umi.

Dalsi vec je jakym zpusomen vyhledavas slova a jakym zpusobem je porovnavas - prohledavni v textu je hnusnej algoritmus, presto se daji najitt/vymyslet rychle i pomale algoritmy...

pokud je jen malo klicovejch slov a ma to bejt neco jako program na jedno pouziti - pak bych premeslel o zmene strategie - neporovnavat slova s tema klicovejma - ale primo vyhladavt klicova slova jedno za druhym - pak bude hledani prenesno na vnitri implementaci v delphi strfind () (nebo jak se ta funkce jmenuj v delphi)

Takhle mi to fungovalo na počátku - používal jsem funkci RichEdit.FindText - a hledal jsem jednotlivá klíčová slova - jenže je to nechutně pomalé(při jednoduchém zamyšlení dojdeš k tomu, že to má daleko více průchodů cyklem než stávající řešení) - navíc hledáš i slova, která v textu vůbec nemusí být...(při řádově stovkách klíčových slov je složitost příliš veliká...)

A k tomu "používat jinou komponentu, která už syntaxi umí" - nebráním se tomu, ale má to zase jiný problém, pokud už najdu nějakou tu free komponentu, která to umí(a umí to rychle), né vždy se to chová stejně nebo aspoň obdobně na různých systémech...
Pár komponent jsem vyzkoušel a vesměs byly odladěny na jednom operačním systému a vzhledem k tomu, že můžu pracovat na Win98, Win98 SE, Win Me, Win XP, Win NT, Win 2000, Win 2003, Vista - (i na Win 95 - ale tu snad již nikdo nepoužívá) - snažil jsem se používat standardní komponenty a z těch, které existují a nejvíc vyhovovaly popisovanému problému byl RichEdit jasná volba, ikdyž je dost pomalý...

Add) první část - ano, nemuselo to být rychlejší, psal jsi, že máš malý počet klíčových slov, asi ne zastak málo :o) aby se to vyplatilo.

:-) Já už vlastně nemam co odpovědět, předtim jsem myslel JaFiho a ted už Tě navedl na jinou komponentu. Čimž je to vyřešeno, předpokládám. Jinak s chovanim komponenty na jinejch systémech bych si asi moc starostí nedělal, pokud nevyužívá nějaké speciální fce - a to se u komponenty obravující písmenka moc nečeká.:-)

Richedit je na zvýrazňování syntaxe dost nešťastné řešení.
Představ si, že máš dlouhý zdroják, pracně nastavíš atributy a pak na začátku vložíš komentář bloku. V té chvíli bys měl nastavit pro celý zbývající zdroj zvýraznění komentáře. Pak komentář zrušíš a můžeš začít zvýrazňovat od začátku.

Pro takové věci se používá prostý text a zvýrazňování v průběhu vykreslování obrazovky. Zvýrazňuješ jen to, co uživatel vidí. A tohle zase není tak jednoduché.

Efektivnější metodou je použít "hotové" řešení, např:
SynEdit - free komponenta s podporou zvýrazňování + spusta hotových zvýrazňovačů, nástroj na tvorbu nových atd.
PlusMemo - neni free, ale velmi dobra implementace
Scintilla - free, je to DLL, ale existuje pro ni i Delphi wrapper

Pokud bys trval na RichEdit, tak se podivej na: RichEdit Syntax Highlighter
Jsou to tridy, ktere zvyraznovani syntaxe v RichEdit umoznuji

Dík, za tip - vyzkouším ten SynEdit ;-)

Pes: kdybych chtěl rozlišovat jen viditelný text tak aby to bylo vidět i při posunu (scrollování) - bylo by asi lepší pro to rozlišení použít vlákno ne? Aby se to při posunu necukalo...
Už jsem pracoval s vlákny na grafických komponentách, ale zase je tam třeba ošetřit "kritickou sekci" a obávám se, že při použití v RichEditu to asi nebude sranda :-(

Ak chces zvyraznovat len viditelny text tak nepouzijes ziaden richedit, zvyraznovanie sa robi pri vykreslovani textu takze musel by si naprogramovat vykreslovanie textu do okna, uz som o tom pisal, (resp. pouzit na to komponentu ak to uz niekto naprogramoval nejako univerzalne - predpokladam ze nieco take bude ten SynEdit).

V tom vykreslování v RichEditu nevidím problém, akorát je naprd ta rychlost ;-)

Jo, kdybych se rozhodnul si pohrát s tím vykreslováním pouze zobrazeného obsahu, jak jsi psal v prostém textu, jakou komponentu na to nejlíp použít? Obyčejné TMemo?

Pes: jinak zkoušel jsem ten SynEdit - stáhnul jsem nějakou verzi 2.0.6, ale nepovedlo se mi to nainstalovat - teda pokud se to instaluje, jako package - nenašel jsem tam žádný *.bpl ani *.dpc soubor - možná bude problém v tom, že mám Delphi 2007 - v adresáři package toho SynEditu jsem našel jen soubory do verze 2006 (ikdyž předpokládám, že z Delphi 2006 by to mohlo jet...)

- mimochodem - tohle je další důvod, proč se od počátku snažím vyvarovat jakýchkoliv externích komponent, protože při použití standardních komponent z 99-ti % není problém s přechodem mezi verzemi Delphi - bez větších problémů jsem spustil databázový prográmek(na Oracle) napsaný v Delphi 6 pod Delphi 2007 - což je naprosto skvělé, když si vzpomenu, jak jsme přepisovali programy napsané v C# + .NET ve visual studiu 2003 - do visual studia 2005 - bylo to podobné, jako přejít z Win XP na Visty (všechno je jinak, jinak funguje a jinak vypadá) :-D (a to byl rozdíl jen dvou verzí předpokládám v rámci 3 roků - ve srovnání s Delphi 6 - Delphi 2007 - tuším 6 let a 7 hlavních verzí je to nebe a dudy 8-))

V tom vykreslování v RichEditu nevidím problém, akorát je naprd ta rychlost

Já jsem nemluvil o nastavování atributů textu, ale o vylreslování. To je docela rozdíl.

To by jet mělo, instaluje se to přes DPK v adreari Packages. BPL (zkompilovany balíček ani DPC nepotřebuješ). Popr. si uprav soubor .\Source\SynEdit.inc a dopln si tam vetev pro D2007

A ze pri pouziti standardnich komponent neni problem? Z Delphi zmizely cele baliky komponent a byly nahrazeny novymi baliky. Externi komponenty, ktere mas se zdroji bez problemu prelozis i pod novejsimi verzemi Delphi.

Odsraneni baliku NetMaster a nahrazeni balikem INDY, odstraneni QuickReport a nahrazeni RaveReportem, presouvani SQL linku v dbExpress mezi edicemi Delphi, odstraneni SQL linku v BDE, odstraneni lokalizatoru z IDE, ...
Je toho vic, ale zrejme jsi mel stesti, ze jsi na nic z toho nenarazil.
U konkurence je to podobne.

Pravda je, že s balíkem NetMaster ani nynějším INDY nedělám, QuickReport jsem kdysi používal, ale už je to docela dlouho, co jsem ho zavrhnul, Rave je celkem slušný a zdál se mi i jednoduchý na použití, ale v Delphi 2007 standardně není(nenašel jsem ho tam) a někde jsem četl, že je placený(zas tak dobrý není, aby stál za nákup...) (pro tisk používám jiné komponenty resp. nástroje).

BDE jsem taky nepoužíval(a neuraž se, ale podle mě to bylo zastaralé už v době, kdy to vyšlo - a přišlo mi divné být s připojením k DB závislý na ovladačích Borlandu a ne společností, které ty databázové stroje vytvářejí
(ikdyž v tomhle možná trochu kecám, nevím přesně, jak to s nimi je, ale je to každopádně produkt Borlandu) - navíc se mi nelíbilo, že se připojení k DB konfigurovalo v BDE a ne přímo v aplikaci... - a nešťastné je, že při přesunu aplikace využívající BDE na jiné "železo" se musí BDE doinstalovat a nastavit v něm zvlášť připojení k DB)

A pokud vím, tak dbExpress je taky výtvorem Borlandu a obsahuje konekty na nejpoužívanější DB stroje.
(ikdyž tohle už je zdařilejší balík a sám jsem zvažoval jeho použití ;-))

Osobně používám pro DB aplikace ADO resp. balík dbGO - dá se s tím připojit v podstatě k jakémukoliv DB stroji, na který jsou OLEDB ovladače - a ty jsou dneska opravdu na všechno... (vyzkoušeno to mám na Informixu, MSSQL 2000 i 2005, Oracle, DB2, MySQL, i na "souborové" databáze typu Paradox, FoxPro, Access a dokonce se dá připojit i k Excelu a dělat do něho selecty :-D) a krásné na tom je, že ConnectionString se nastavuje přímo v aplikaci, takže s přesunem na jiné PC nejsou problémy(v podstatě to stačí zkopírovat :-))

V době, kdy BDE vyšlo ses mohl připojovat maximalně přes ODBC, popř. později přes problematicke ADO (ze začátku). Takže BDE bylo ve srovnani tenkrat s tim narosto skvělé a i dnes, když je s ADO srovnám tak má pár věcí, které jsou na ADO nepříliš dobře.
Ano, BDE se muselo instalovat, ale veškeré nastavení se dělaly v aplikaci. Přes BDE administrátora to dělali jen nešťastníci, kteří si dobrovolně způsobovali problémy.
ADO se instalovat nemusí, protože je už ve Winows "nainstalované". Pokud chceš, aby tvůj program fungoval i na Win98, musíš si ADO nainstalovat.

dbExpress obsahuje připení na nejpoužívanější SQL servery, bohužel Borland (Code Gear) šibuje s jejich obsažením v různých edicích Delphi. Takže ve verzi professional 2006 už byla tuším jen Interbase a MySQL

A on se Connection string někdy nastavoval i jinde než v aplikaci? Dělat to přes nějakého administrátora připojení na stanici v ovládacích panelech je nesmysl. Je to stejně hloupé jako to dělat v BDE administrátorovi.

S tím BDE jsem to asi napsal nešťastně a sám jsem ho nepoužíval, ale asi 2x jsem byl nucen rozjet nějakou starou aplikaci(jejíž autor někde "zmizel") na novém PC a byla to celkem sranda.

Pokud jde o ADO, pravda je, že jsem ho používal od Delphi 6, ve starších verzích nevím, jak to šlapalo nebo jestli to tam vůbec bylo...

S tou Win98 jsem problém neměl, šlo tam spíše o verze ovladačů, nepamatuji si, že bych tam něco musel instalovat, ale to už je docela dlouho a lhal bych, kdybych řekl, že jsem tam nic neinstaloval, je to tak dlouho, že už to sám nevím.
(nicméně už to je stejně docela dlouho nepodporovaný systém a zřídka se na něj dostanu - mimochodem brzy bude i Win XP nepodporovaný :-()

A o tom ConnectionStringu jsem to možná napsal taky nešťastně, prostě mi to přes ten BDE administrátor, jak jsi psal přišlo podobné, resp. jsem v něm nastavoval "parametry" pro připojení, nic víc ani nic míň.

Zpět do poradny Odpovědět na původní otázku Nahoru