Tento text je nyní již poněkud zastaralý.
Týká se mého boje s komponentou TRichEdit, který
dopadl podle přísloví "moudřejší ustoupí": ustoupil
jsem od RichEditu protože není pro mně.
Není pro mně, protože je idiotský. Proč je
idiotský? Čtěte dál.
Musel jsem text změnit, aby bylo jasné, že problémy
jsou nyní vyřešeny - a to odhozením RichEditu
a přechodem k lepší programátorské knihovně.


          O PROGRAMOVÁNÍ DANIELSOFT EDITORU
          °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Nedá mi to a musím vám povědět Příběh O Strašlivé
Věci Jménem RichEdit:
Pokud nevíte, co RichEdit je, pak vězte, že je to onen
bílý box, do kterého se v editorech pod Windows
zapisuje a ze kterého se čte text. RichEdit jsem
neprogramoval já, je zabudovaný ve Windows a můj editor
se při nízkoúrovňových operacích musel spoléhat na
jeho služby. Nyní již ne, ale přesto vám popíšu
problémy, se kterými jsem se před nedávnem potýkal.

Dlouhou dobu jsem byl místo RichEditu nucen používat
jeho "mladšího brášku" Memo, které se vyznačovalo hlavně
nízkou kapacitou. Maximální velikost souboru, který
bylo Memo schopné načíst bylo něco kolem 63k (skutečně
63k a ne oněch v DOSu notoricky známých 64k)
a to jsem ještě měl dojem, že soubory blížící se této 
magické hranici se nenačtou celé. Samozřejmě celou dobu
mluvím (a taky mluvit budu) o 32bitových Windows.
V 16bitových to bylo ještě horší (32k).
RichEdit _také_ větší soubory odmítal, avšak tvrdil o
sobě, že je v pořádku načítá. Soubory od 100k výše 
byly načteny v jakémsi podivném "read only" módu, kdy
do nich šlo zapisovat pouze když jsem něco smazal
přes schránku (???). Znovu opakuji, že celou dobu jde
 o věci do Windows vestavěné, které jsem nemohl
 sám nijak přeprogramovat, jen se spolehnout na jejich    
"skvělé" služby.
Nakonec jsem z hlubin Internetu vytáhl,
že když snížím (??) maximální velikost akceptovatelného
souboru RichEditem tak, aby byl nejvyšší byte nulový,
divné chování přestane. Přitom tvůrce této rady napsal,
že sám neví proč to tak je. Prostě černá magie 
nejmenované monopolní softwarové firmy. 
Když jsem tedy mohl RichEdit konečně místo Mema použít,
radostně jsem je zaměnil a zdálo se, že kapacita se
zvýší a všechno bude "chodit" jako dříve. To byla
verze 4.1 editoru. Bohužel některé věci, které
se u Mema programovaly jedním způsobem se u RichEditu
(ve stejném OS od stejné firmy) programovaly nyní
úplně jinak. A to ještě nemluvím o tom, že pomocná
skrytá Mema, která pomáhala tomu hlavnímu zpracovat
text, jsem musel změnit na pomocné RichEdity, protože
milostpán RichEdit se se svými chudými příbuznými
nehodlal bavit. Díky těmto problémům byla verze 4.1
chybová a musel jsem jí urychleně opravit na 4.2 a
upgradovat to na webu.
Někteří programátoři, kteří čtou tento text by mohli
namítnout "a proč jste musel něco u RichEditu či
Mema *programovat*, když on poskytuje nízkoúrovňové
služby, jak jste říkal. Proč jste tyto služby pouze
*nevolal* ?". Hmmm ... tito programátoři zřejmě málo
programovali ve Windows (to jim nevytýkám, pouze to
konstatuji).
Některé -podle mě bazální- služby se musely po
Memu/RichEditu žádat vskutku krkolomě. Posuďte sami 
- pro zjištění, na kterém řádku je kurzor, se
musí provést něco takto neintuitivního a
překombinovaného:

function GetTextPosLine(var rich:TRichEdit):longint;
var c:TCharRange;{co je to proboha za datový typ???}
begin
rich.Perform(EM_GETSEL,0,integer(addr(c)));
Result:=rich.Perform(EM_EXLINEFROMCHAR, 0 , c.CpMin);
end;

u Mema se to dělalo úplně jinak, taktéž krkolomě.
Bohužel si to už nepamatuju. Pokud jsem ten "memový"
postup použil na RichEdit, VRACELO TO VŽDY NULU, takže
pokaždé když jsem se zeptal na kterém jsem řádku
odpovědělo to že na nultém - tj. prvním! Tím vznikaly
(zpočátku těžko odhalitelné) chyby.

A nastavení řádku jsem si taky musel napsat sám:

procedure SetTextPosLine(rich:TRichEdit;pozice:longint);
var pocet,i:integer;
begin
pocet:=0;
for i:=0 to pozice-1 do                     
              inc(pocet,length(rich.lines[i])+2);
         {to +2 jsou zřejmě znaky CR LF, ale kdo ví...}           
rich.selStart:=pocet;
rich.selLength:=0;
end;

Všimněte si, že ani pro změnu pozice počítané ve znacích
neexistuje funkce a musí se celkem hloupě "vybrat"
nulové množství znaku do Selection (pomocí SelStart
a SelEnd).
Také jsou tu nepříjemnosti, jako že například RichEdit 
přepnul pokaždé při svém spuštění klávesnici na "Cz" a
přepnul ji tak také pokaždé, co už jednou "vejdu" do
již napsaného textu. Jako programátor však často
potřebuju hranaté závorky, mřížku, zavináč, ampersand
apod., takže bych nutně potřeboval mít nastavení
*anglické*, jaké mám jinak v celých Window$, ale
RichEdit to prostě nebral. Řešením bylo označit celý
dokument a přepnout na "En".

Nyní se mi již KONEČNĚ povedlo toto překonat, avšak
ještě jsem se musel potýkat s tím, že pokud jsem
klávesnici přepnul na En, najednou přestaly "chodit"
české znaky, což se mi nakonec naštěstí podařilo 
obejít. Znovu je však před přepnutím nutno označit
celý text, díky čemuž nemůže uživatel přepnout normálně
alt+shift, ale musí použít položku z menu Čeština, která
označí text, přepne a zase ho odznačí. Jinak by totiž
neoznačené části textu, pokud by k nim člověk došel
kurzorem, znovu "samy přepnuly" do původní klávesnice,
bůh ví proč. Uff. 

A to ještě nemluvím o tom, že několikrát text při 
načtení prostě
zmizel a musely se změnit rozměry RichEditu aby se
zase objevil... Stane se to třeba při posouvání textu
pomocí Ctrl+Alt+ -> hodně doleva, nevím proč.

Nyní, když místo RichEditu používám SynEdit
(který není od M$), programuje se vše daleko
lépe. Dokonce mám pocit, že je editor i rychlejší,
ale to může být jen můj subjektivní dojem.
Posuďte sami skok mezi verzí 6.9 a 8.0 .