Tipy a triky v Delphi, díl 43.

Zaujala mne konstrukce:

  if Timer1.Enabled <> false then Timer1.Enabled := false;
  Timer1.Enabled := false;

Autora k tomu zřejmě vedlo staré dobré pravidlo "sichr je sichr".

Dál už jsem to raději neprohlížel... 

No pan programovator, co taketo "riesenie" bublinkovej napovedy navrhol, musi byt fakt profik. Ani nevravim o nutnosti kliknutia na button, aby sa napoveda objavila, to este dokazem tolerovat, kedze je to len priklad. Na com som sa fakt velmi dobre pobavil bola situacia, ak button umiestnime blizko k pravemu okraju a potom sa ukaze zaujimavy ukaz, ked sa zobrazi napoveda. Bud je odseknuta alebo sa v spodnej casti objavi scrollbar (samozrejme v zavislosti od property Borderstyle . Bravoooooo, bublinkova napoveda fak slak... Podla mna, toto bol vysoko odborny clanok.

Nemluve o:

1. zbytecnem pouziti GetMem, StrPCopy, FreeMem (AnsiString lze totiz pretypovat na PChar).

2. zbytecnem predavaji druheho parametru do FreeMem. Tento parametr je totiz zcela ignorovan a nema zadny smysl.

Pokud to ma slouzit jako ukazka pro zacinajici programatory, tak je to velmi smutne

Jeste dalsi chyby a nesmysly:

procedure TForm1.ShowAHint(x : integer; y : integer; Caption : string; Duration : LongInt);

Parametry, ktere jsou typu jenz se fyzicky predava jako pointer (tedy AnsiString, dynamicka pole, recordy ...) se zasadne predavaji jako const, tedy const Caption: string. Tento "drobny detail" ma totiz vliv na rychlost behu kodu, protoze se tak zabrani vytvoreni lokalni kopie uvnitr dane metody/procedury.

Doporucuji si vlozit do CD mechaniky instalacni CD s Delphi a precist si "Object Pascal Language Guide", kterou lze najit v souboru OPLG.PDF. Chapu ze nikdo nemuze vedet vsechno, ma-li vsak tento serial slouzit jako pomucka ci ucebnice pro programatory, nemely by se v nem vyskytovat takovehle veci.

if Timer1.Enabled <> false then Timer1.Enabled := false;

Mozna autorovi unikl zpusob prace s vlastnostmi a jejich implementace. Navic zapis vyhodnoceni podminky je vice nez podivny.

Timer1.Enabled := false;

Nebylo to nastaveno jiz v minulem radku ?

if Panel1.Visible <> false then Panel1.Visible := false;

Opet stejny nesmysl, viz vyse.

>Parametry, ktere jsou typu jenz se fyzicky predava jako pointer (tedy AnsiString, dynamicka pole, recordy ...) >se zasadne predavaji jako const, tedy const Caption: string. Tento "drobny detail" ma totiz vliv na rychlost >behu kodu, protoze se tak zabrani vytvoreni lokalni kopie uvnitr dane metody/procedury.

Obavam se, ze v techto pripadech k zadnemu vyznamnemu zrychleni nedojde. AnsiString a dynamicka pole (promenne pouzivajici reference counting) se vzdy predaji jako pointer a zadna kopie se automaticky pri vstupu do funkce nevytvari (pouze se zvysi reference counter na to stringo). Ovsem k vytvoreni kopie dojde, jakmile menim hodnotu promenne (stringa), protoze reference counter poukazuje na to, ze hodnota stringa je pouzita jeste v jine casti kodu. Pokud tedy nemenim hodnotu promenne, k zadnemu zpomaleni by dojit nemelo.

Zrejme si to pletes s promennymy typu ShortString, array, Record, atd - ty se pri volani bez CONST vzdy kopiruji do stacku (a to kopirovani muze trvat relativne dlouho) aby se zajistilo, ze funkce ma svoji vlastni lokalni kopii bufferu se kterou si muze delat co chce aniz by ovlivnila puvodni buffer. Pri pouziti CONST (nebo VAR) se predava pouze pointer, coz vede k tomu zrychleni ...

S tim reference countingem mas pravdu, bylo to asi prilis zjednodusene. Nicmene se podivej na vygenerovany kod v pripadech:

procedure MyProc(S: string);
begin
  WriteLn(S);
end;

a

procedure MyProc(const S: string);
begin
  WriteLn(S);
end;

Ten prvni pripad se totiz prelozi jako:

procedure MyProc(S: string);
begin
  @LStrAddRef(S);

  try

    WriteLn(S);

  finally

    @LStrClr(S);

  end;
end;

Co blbneš, copak nevidíš ty parametry tý fce ? Ten hint si můžeš vrazit kam chceš a ne jen dolu. A kdybys byl trochu šikovnej, tak si to ve svým programu ošetříš....

Nazdar Matej,

no, na zaklade tvojho prispevku my je jasne, ze zrejme sikovny nebudes ty Sorry. Ale zrejme si ma nepochopil a absolutne ti nedoslo, ze takto sa bublinkova napoveda nerobi a efektivne sa ani neda spravit !!! Parametre su tam ... a co ??? Priklad. Zober si okno, ktore bude mat rozmery povedzme 100x30 pixlov a uprostred bude len jedno tlacitko a k tomuto tlacitku chces spravit bublinkovu napovedu napr. "Stlacenim  tlacidla sa aktivuje hlavny process". Problem je, ze akokolvej budes to umiestnovat, nesprace sa ti to tam, ani nahodou a potom nastava orezanie resp. zobrazi sa scrollbar. Pricom pri bublinkovej napovede je uplne bezne, ze tato "vychadza" von z okna. Svojim prispevkom som len chcel naznacit fakt, ze takto sa HINTy nerobia a cely "Tip a Trik" (a com by mal byt tento clanok) je trosku na figu. A toto je len jeden problem, z viacerych, nuz ale tie napadnu iba tych bystrejsich, vsak Matej

Ještě jsem zapomněl na DÚ, takže stačí odchytit zprávy: CM_MOUSEENTER a CM_MOUSELEAVE.

Milan

ano, rovněž bych prověření počtu instancí řešil mutexem, v horším případě pak pojmenovanou BROADCAST zprávou a patřičnou reakcí na ni.

O tipu na MediaPlayer a "bublinkovou nápovědu" ani nemluvě. Nebylo by mnohem lepší a jednodušší použít THintWindow?

Milan

Jiste ze bylo. Spravne reseni je odvodit novou tridu od THintWindow a priradit do HintWindowClass.

1. V daném příkladu by bylo vhodné definovat konstantu a tu pak použít jako parametr pro obě volání. Takhle je to značně nečisté.

2. Použití GlobalFindAtom nemusí být vždy úplně spolehlivé, protože počet takto vytvořených kombinací je omezený, navíc po ukončení aplikace ji již nelze znovu spustit, protože GlobalFindAtom vrátí nenulovou hodnotu. Je to sice popsáno v textu, ale pod tímto si asi většina lídí představí, že aplikaci lze spustit pouze v jedné instanci. Vhodnější je použít pojmenovaný mutex.

3. Test na vícenásobné spuštění instance by měl být proveden daleko dříve než až v TForm.OnShow, ideálně přímo v .DPR souboru.