Dej si pozor na délkové omezení načtených dat do těchto komponent.
Všechna tato omezení tady popisovaná, nejsou chybami "Borlandů", ale prostě tyto objekty jsou v systému takto navrženy.
TListBox pod Win95/W98 (pod WinNT toto omezení neplatí) pojme maximálně 2^15 (32768) položek vycházející z 16-ti bitové architektury tohoto objektu. (^16 ne protože jeden bit je na znaménko).
Doporučuji počítat z 32500 položkami maximálně a ošetřit program tak, aby toto číslo nepřesáhl.
TMemo přesně nevím, protože jsem to nestudoval, ale mám dojem, že toto omezení pod W95/W98(pod WinNT 2GB znaků)je na 2^15 (32768)znaků NE ŘÁDKŮ. Když se zamyslíš tak je to asi jen 1000 řádků po 32 znacích.
Já osobně používám tento objekt jen asi na max 500 řádků. Tím si v 99% nepřivodíš žádné problémy.
TRichEdit je pro načítání většího počtu dat nejvhodnější (ale zas to nepřeháněj). Teoreticky by se do něj měl dát načíst 2GB soubor, což jsem nezkoušel - potřebuju počítač ještě tento týden používat. ALE je to jen teorie a ještě jedno "kouzlo".
Pokud necháš property MaxLength nastavenou na 0 (nebo stádo jíných hodnot včetně 2147483648), což znamená bez omezení a načteš si tam tak asi 4MB soubor(kde je hranice nevím a myslím, že záleží na počítači), tak zjistíš, že už do něj nelze nic dopsat ikdyž není ReadOnly, ale když odmažeš třeba pět znaků, tak je můžeš zas kdekoliv dopsat. - Hezká vlastnost ne ? Ale nezoufej lze to nastavit, stačí když zapíšeš do property MaxLength hodnotu 1073741824 ta nastaví správný bit na 1 (když, si to číslo zobrazíš ve dvojkové soustavě, tak aj uvidíš který to je) a to vlastně nastaví že do RichEditu můžeš načíst max 1GB dat.(což je až dost).
Toto nastavní je takové kouzlo jak načíst 4Mb soubor a ještě s ním něco dělat a nemá žádný vliv na velikost paměti spotřebovávanou RichEditem (má, ale opravdu zanedbatelnou).
Další nepříjemná vlastnost, ale celkem logická je že pokud do RichEditu (i Mema), načítáš data postupně(třeba nějaký generovaný delší výpis) pomocí metody "Add"(Insert), tak to trvá pří větších datech(už od 0.5Mb) dost dlouho(0.5Mb = 1min - PII/350). Je to zapříčiněné neustálou realokací paměti. Proto silně doporučuji když je to jen trochu možné nejprve data "vysypat" do pomocného souboru a načíst až z něj do RichEditu pomocí fce "LoadFromFile".
Zrychlení je radikální (u 0.5MB je načeno pod 1 sec což se rovná asi tak 100 násobnému zrychlení).
Pokud mně nevěříš:
Tyto zkušenosti jsou z Delphi 4 a C++Builder 4, na novějších zkus sám.
Komponenta TrackBar, byla pravděpodobně převedena s 16-ti bitové architektury na 32-ti bitovou, ale asi se na něco zapomnělo.
Pokud například ho chceš použít na zvukový záznam (v milisekundách), tak bacha, stejně tak na jakýkékoliv data větší než 32768 jednotek. Pokud budeš použivat jen property position, tak neni problem, ale pokud použiješ SelStart a SelEnd (třeba pro vyběr části zvukového záznamu), tak jsi namydlený.
Tato hodnota je pravděpodobně uchována v 2bytovém integeru a při větší honotě si číslo vesele přebublává.
Někdy mě mrzi, jak jsou některé programy zbytečně pomalé jen kvůli tomu, že programátor vložil do kodu nějaké počitadlo nebo TProgressBar a špatně ho nastavil. A moc nepomože že máš P4 na milionu Ghz.
Jená se o počitadla které mohou dosahovat hodnot větších než cca 2000 například při čtení z větších souborů nebo při třídění různých seznamů apod.
Nebudu se moc rozepisovat... .Jedná se o to že Win "čekají" na vykreslení. A moc vykreslení může několikanásobně brzdit dobře napsaný rychlý kód.
Ke stažení je zde projekt v C++Builderu verze4. Uživatelé Delphi se nemusí lekat kód je téměř totožný s Delphi a jde jen o pochopení proč to tak je a možných způsobů řešení (s využitím knihovny VCL). Jen snad pomůcka v C++ je zápis Button.Caption nahrazen Button->Caption (proč to tak je, není předmětem diskuze).
Upozorňuji, že kód neobsahuje nic co by ho brzdilo jedná se jen o vykreslování. To co bys do kódu zařadil by ti to samozřejmě ještě zbrzdilo. Malý popis k "testu":
V horní části se testují počitadla, které z nějakého důvodu chceš aby počítala po 1. (U větších čísel nad 5000 je rozhodně vhodnější vypisovat každé N-té číslo ikdyž si to musíš předem předpočítat - tento čas potřebný pro předpočet je asi jako komár vůči Venuši).
1.Test vypisuje do TLabel
2.Test vypisuje do TStaticText
3.Test vypisuje do TBitmap, přes Canvas a vypisuje nebo vlastně vykresluje počitadlo do TPaintBox. Tento zpusob je docela rychlý a nejmíň promrkává. Jen nesmíš zapomět nastavit Event OnPaint daného TPaintBox-u.
4.Test vypisuje do vypisuje TPaintBox přes Canvas. Tento zpusob je nejrychléjší (z testovaných - jednoduchý rychlejsí mě nenapadl). Jen nesmíš zapomět nastavit Event OnPaint daného TPaintBox-u.
Tlačítka jsou ve dvou řadách, první řada využíva AnsiString a v zasade Pascalovskou fci IntToStr. Druhy řádek zajímá jen céčkaře a je nutné nahlédnout do zdrojového kódu ke zjištění rozdílů - prostě se nepoužívá AnsiString ikdyž funkce Canvasu ho vlastně používají (jukni a uvidíš).
Ve spodní části je test vypisu třeba při hledání souborů apod. Jedná so ruzné délky řetězců neznámé předem.
1.Test vypisuje do TLabel
2.Test vypisuje do TStaticText
3.Test vypisuje do TBitmap, přes Canvas a vypisuje nebo vlastně vykresluje počitadlo do TPaintBox. Tento zpusob je docela rychlý a nejmíň promrkává. Jen nesmíš zapomět nastavit Event OnPaint daného TPaintBox-u.
4.Test vypisuje do vypisuje TPaintBox přes Canvas. Tento zpusob je nejrychléjší (z testovaných - jednoduchý rychlejsí mě nenapadl). Jen nesmíš zapomět nastavit Event OnPaint daného TPaintBox-u.
5.Test zajimá zase jen céčkaře a je o tom, že si řetězec skládá s pole char-ů (klasicky céčkový řetězec). Tady bych chtěl jen upozornit, že AnsiString je dobrá věc, ale pokud děláš hodně operací z řetězci, tak se radši hezky vrať ke klasickým řetězců AnsiString má krutou daň za pohodlnost a to je rychlost (Když spracováváš 100 řetězcu a v každém 10x něco hledáš, tak to samozřejmě moc nepocítíš).
No a test v pravo je jen o správném nastavení TProgressBar-u.
Pravy ProgressBar má nastavenou hodnotu Max na počet cyklů.(Pokud je cyklů více než cca 2x jeho délka v pixelech, tak si toufám říct, že to není dobré co se týče rychlosti)
Levý ProgressBar má nastavenou hodnotu Max na ProgressBar.Height (Pascalovský zápis) a ProgressBar.Step na PocetCyklů / ProgressBar.Height a jukni na rozdíl rychlosti napr už u 1000 cyklů nemluvě u vyších počtů cyklů. Vhodné tak do max. 10000 cyklů. ProgressBar a prodleva: všimni když si nastavíš vyšší počet cyklů (např. 80000 - záleží na vykonu počítače) a spustíš pravý ProgressBar, tak vykreslení sice proběhne rychle, ale vznikne prodleva na konci než se vypíše stopnutý čas, tuto prodlevu vytváří ProgressBar(nestudoval jsem proč).
Proto tady nabízim jedno rozumné řešení pro počet cyklů 0-2147483647 (prakticky nad 500cyklů do 100 000 000).
K vykreslován počitadla dochází jen ve velmi málo případech, ale oku to nevadí - za předpokladu, že jedna smyčka netrvá několik sekund. Pokud jedna smyčka trvá např. 10sec a víc a zpracovává se větší počet smyček např. 500 a víc, tak doporučuji nedávat tam počitadlo, nebo místo něj dát jen procenta splnění a vypisovat je stejným způsobem, tzn. jen tolikrát kolik má ProgressBar šířku (pokud má cca 600 a víc můžeš uvést i procenta na 1 desetiné místo :) ). Klasické počitadlo je v tomto případě zbytečné protože nikdo na to hodinu a víc (tolik by to trvalo, si to spočítej) nebude nepřetržitě čumět. Projekt ke stažení včetně "exe" (227kB zipováno) Slušné rychlé řešní včetně "exe" (214kB zipováno)