Modální story

vložil Radek Červinka 27. dubna 2013 00:55

Příběhů z praxe není nikdy dost. Narazil jsem na problém, že v některých případech kdy zobrazuji modální dialog z modálního dialogu a ještě do toho připletu jiný styl okna (WS_POPUP), někdy nastane problém, že Windows ztrácí informaci o pořadí modálních oken.

Klíčové slovo je "ghosting windows" a projevuje se to (asi) do Windows Vista, tj. okno je vytvářeno bez informace explicitní informace o tom, které okno je jeho nadřízeným oknem (neplést s Owner - což je objekt odpovědný za jeho uvolnění).

Naštěstí jsem zjistil, že v Delphi 2009 (pravděpodobně, možná i dříve) byly do TForm přidány dvě property:

  • PopupMode
  • PopupParent

PopupMode může nabývat třech hodnot:

  • pmNone (staré chování)
  • pmAuto (Screen.ActiveForm se stává aktivním otcem okna)
  • pmExplicit (otec okna je definován via PopupParent)

Vtip je v tom, že pokud uděláte ShowModal, tak se automaticky použije pmAuto, ale díky tomu se zavolá RecreateWindow. Pokud tomu chcete zobránit, tak jednoduše nastavte popmode na pmAuto před voláním.

Zdálo by se, že to je výjimečná situace, ale jak zjišťuji není to tak úplně pravda.

Pokud máte starší Delphi, tak pokud se nepletu je řešení přes CreateParams.


Nabízíme Delphi školení a konzultace na různá témata, primárně ve Vaší firmě.

Tagy:

Praxe

Komentáře

29.4.2013 9:31:10 #

anec

popupmode a popupparent je už ve verzi 2007 (možná i dříve)

aplikace kompilovaná v delphi 7 má výše uvedené chování i pod Windows7

anec

29.4.2013 12:05:41 #

oxo

Navíc má ShowModal problémy s maximalizovanými okny. Např. tento kód:

procedure TForm1.BtnShowParentModalClick(Sender: TObject);
var xMF: TForm;
  xMemo: TMemo;
  xBtn: TButton;
begin
  xMF := TForm.CreateNew(TComponent(Sender));
  try
    xMF.SetBounds(100, 100, 700, 500);
    xMF.WindowState := wsMaximized;
    xMemo := TMemo.Create(xMF);
    xMemo.Parent := xMF;
    xBtn := TButton.Create(xMF);
    xBtn.Parent := xMF;
    xBtn.Caption := 'Show Child Window';
    xBtn.Left := 400;
    xBtn.Width := 200;
    xBtn.OnClick := BtnShowParentModalClick;

    xMF.PopupMode := pmAuto;
    xMF.ShowModal;

  finally
    xMF.Free;
  end;
end;

Zkuste ho spustit, objeví se maximalizovaný formulář. Při následném zmenšení (zrušení maximalizace) si formulář nepamatuje původní velikost a zobrazí se jako nejmenší možný. Udělal jsem si na to opravu jako class helper, pokud si Radku myslíš, že je pro tebe zajímavá, pošlu ti jí.

Problémem je, že ShowModal obnoví Handle formuláře a informace o původní velikosti se ztratí.

Asi bych měl svými bugfixies začít plnit CodeCentral, ale jelikož udržuju projekty i na starších verzích Delphi, pro které Embarcadero už žádné updaty nikdy uvolňovat nebude, tak se mi to zdálo vždycky jako ztráta času...

oxo

29.4.2013 13:09:44 #

radekc

Když pošleš, zveřejním. Pokud to dáš do QC tak určitě pomůžeš někomu kdo to bude potřebovat. Navíc podle firemních pravidel je nutné zadat chybu přes QC, to pak spouští docela silný mechanismus selekce a opravy chyb. Takže s QC nic nezkazíš.

radekc

29.4.2013 14:15:26 #

oxo

Máš to v mailu! Budu doufat, že opravy chyb ve VCL zůstaly nadále jednou z priorit Embarcadera. Dám jim šanci to ukázat a pár chyb tam pošlu.

oxo

29.4.2013 17:43:34 #

oxo

Tak jsem jim tam tento bug poslal, pak ještě jeden ohledně CanFocus, ale ten tam mají otevřený už od roku 2006 (!), tak nevím, jak moc je ten mechanismus na opravu chyb silný: http://qc.embarcadero.com/wc/qcmain.aspx?d=32663
Hlavně, když se jedná o chyby, které se dají opravit jedním řádkem kódu :(

oxo

29.4.2013 19:34:05 #

JFK

Myslím, že je to objektivní fakt, který vnímá celá globální komunita. Tj. že cílem EMBT je vždy zahltit novinkami (někdy patřícími spíše do uvozovek), ale na bugfixing se jaksi po mnoho let nedostává (TeamA, B, ... ponechme bez komentáře). A některé chyby jsou skutečně do očí bijící. A pokud tento trend - místo updatu k uvolněné verzi vydat v poločase raději hned verzi novou - bude pokračovat, tak se možná některým otevře v kapse i ta pověstná kudla. Delphi sice stále považuji ze své nejmilejší IDE i jazyk, ale společnost samotná mi reálně tak přátelská už nepřipadá. Nemluvě o tom, že někteří její "promotéři" by měli už opravdu "omladit" a dát prostor lidem více aktivním a otevřeným. Snaha o dosažení zisku by neměla nutně implikovat ignoranci a demagogii. A ve "vymývání" bohužel EMBT rozhodně nezaostává.

JFK

29.4.2013 23:29:06 #

radekc

Hmm, zdroje a čas je limitovaný. Borland předtím na to kašlal a změny např. mezi Delphi 3 - 7 jsou minimální. Ale to nikdo moc neprotestoval.

Teď během několika verzí máme Unicode, Generika, 64bit, OSX, iOS, FireMonkey, brzo Android. To je vám málo? Chyba ve VCL nebo IDE je blbá - taky mne štve, ale dá se vždycky nějak obejít, nový kompilátor nebo platformu ani náhodou. Takže zásadně nesouhlasím. A vím dobře jak R&D tvrdě makal aby iOS kompilátor a FMX vypadal tak jak vypadá. VCL je relativně stabilní a zralá knihovna, která je udržovaná a minimálně rozvíjená.

Ono kolikrát to, že něco vypadá jako jednořádkový fix, může mít různé interference. Ale taky nemusí. A vím že se opravují chyby ve VCL které tam jsou i z dob D3. Mimochodem jsem nedávno nahlásil chybu kompilátoru z D3 a během týdne byla do nové verze opravena. Popravdě: kolik verzí Vašeho SW vy udržujete? Ono backportovat opravu není jednoduché - zvláště u tak velkého SW - to se musím EMBT zastat.

Na druhou stranu taky některé věci se mi nelíbí - např. zero based string - ale myslím, že je za tím nějaký dlouhodobější plán, takže jen doufám, že ví co dělají.

radekc

30.4.2013 9:43:19 #

Petr Kohut

Moje zkušenost je (a není to kritika EMBT), že chybové reporty zadané na právě betatestovanou verzi byly řešeny promptně a ty které nebyly vyřešeny do určité doby, zůstaly otevřené (možná navždy). Takže pokud je třeba nějakou chybu opravdu opravit, chce to zůčastnit se betatestu a tam tu chybu hned nahlásit. Případně ji nahlásit k nejnovější verzi hned po jejím vydání.

Petr Kohut

30.4.2013 12:25:23 #

Daniel Andraščík

Radku, velmi pekne si to zhrnul v tvojom komentari. Uz sme tu diskutovali ohladom toho ze som dost pesimista pri uvadzanych terminov vydavania noviniek a nakoniec ich nasledneho odladenia. Ale vzdy som podotkol ze to nikomu nevicitam, hoci ma to niekedy samorzejme rozhorcuje. Ale vsetci vieme co vyvoj obnasa a ja tiez vzdy, ale naozaj vzdy meskam, mozno jediny termin v zivote som stihol :P a aj tak to nakoniec trebalo prerobit skoro cele. Velmi trefna je tvoja veta:
"Ono kolikrát to, že něco vypadá jako jednořádkový fix, může mít různé interference."

Daniel Andraščík

30.4.2013 13:13:02 #

radekc

Snad mne za to nezastřelí:

Entering things into QC is critical. It's part of our process which has
several layers and checks/balances. This is especially true as the
release date nears.

QA will review bugs as they arrive (or as quickly as humanly possible)
and evaluate the quality of the report itself. Can it be reproduced, is
it the right classification, etc...

The bug is then opened into the internal system. Then there is a daily
"bug-council" in which the R&D, QA and product managers will go through
every new bug from the previous day. Each developer is contacted based
on who the bug is assigned to. In concert with the developer and
managers, a decision is made on the priority and whether this bug
*must* be fixed now or if there are other higher priority bugs that
must be addressed first. Once that process is complete and everyone
agrees on a priority, the developer is given this "approved" list of
bugs to fix, or sometimes merely research a possible fix.

Sometimes it is determined that the "fix" could have broader negative
impact which could be worse than the original bug. In those cases more
senior developers are brought in to help assess the situation and see
if a "safer" fix can be done.

At this stage in the cycle, every fix must then be peer-reviewed so
that another set of eye-balls have looked over the code. We've been
using Crucible from Atlassian to facilitate this process due to our
distributed teams. The *goal* is to keep regressions to a minimum since
they just waste everyone's time. Since humans are involved, some things
still get through this whole process and regressions still occur... but
we do know that this process significantly reduces those occurances.

radekc

30.4.2013 17:39:28 #

JaroB

No, v dobách, kdy Inprise mělo v ohlávce Borland, a neopravovali zjevné chyby ve VCL (anebo je s další verzí domastili), např. řízení fokusu nebo správu menu, tak se našlo spousta nadšenců, kteří se pokusili chybu, přetrvávající přes více verzí Delphi, opravit. Ale jakmile EMBT naskočilo a opravdu významně rozšířili agendu, tak opravovali stylem "nová verze to vyřeší". Díky roční periodě a v cyklu prototyp-předverze-final (např. 2009-2010-xe, xe3-xe3-xe4?) to spousta nadšenců vzdala, protože se nůžky bugů otevřely ke zcela novým obzorům a roční perioda updatů je taky dost krátká. Takže shromáždit chyby ke konkrétní verzi Delphi např. ve VCL je dost fuška (byť oprava je třeba jen na pár řádků). A to že EMBT s vydáním nové verze na patche verzí předchozích zapomene není překvapení, je to jen otázka vícenákladů...

JaroB

30.4.2013 23:06:24 #

oxo

Radku, když už jsme u toho "kolik verzí Vašeho SW vy udržujete?"- ruku na srdce, jaký software Tě nejvíce živí - ten "obyč" na VCL 32bit pro Windows, nebo ten na FireMonkey pro Win+Mac popř. iOS?

Delphi taky holt není samospásné a není jediné na světě, pokud nebudou opravovat chyby, tak jim to nepomůže v ničem. Vím, že jsem vypíchnul jen jednu věc, ale přeci jenom za těch 7 let mohli ten bug alespoň uzavřít jako "není to bug, je to feature" a nebo ho opravit. Ale to, že je stále otevřený (=nevyhodnocený), o něčem svědčí... Psát si o interních, skvěle fungujících procesech můžou, co chtějí :) Upřímně řečeno mě pan Tomohiro dost překvapil, když mě napsal, že je to duplikát 7 let starého a stále ještě otevřeného bug reportu - a to hned po vydání nové verze jejich softwaru.

Uvidíme, ještě jim pošlu jeden bug ohledně jejich zip komponenty, která si nedokáže poradit se soubory, které jsou v zipu pouze uložené (t.j. nejsou zkomprimované). Se zbytkem počkám. Přeci jen mě to taky stojí čas to sepisovat (když jsem si to už stejně byl schopen opravit), aby se na to potom zapomnělo.

oxo

30.4.2013 23:19:44 #

radekc

>oxo

to s tou verzí bylo nedorozumění: VCL 32bit, ale pokud se najde chyba ve verzi třeba rok staré, tak se opravuje v aktuální nebo předchozí. Nebackportuji (až na vyjímky) a zákazník je většinou pod maintenancí a dostane novou verzi.

radekc

1.5.2013 18:25:52 #

oxo

radekc> Já tě pochopil, spíš jsem komentoval ty změny ("Unicode, Generika, 64bit, OSX, iOS, FireMonkey, brzo Android").
Pod Delphi 2007 se Unicode dalo řešit přes TntUnicodeControls, ale je pravda, že teď je to mnohem lepší. Generika jsou taky fajn. Ale 64bit+OSX+iOS+FireMonkey jsem zatím nepoužil. Nehledě na to, že iOS se mě netýká, protože mám jen prof.

Zase jsem jim chtěl jednu kravinku postnout, a zase jí tam už mají: http://qc.embarcadero.com/wc/qcmain.aspx?d=96350 .

Jinak k maintenance: předpokládám, že když tvůj zákazník pod maintenancí objeví chybu, tak se jí snažíš vyřešit - i když se týká staršího kódu. Stejně by se mělo chovat i Embarcadero, t.j. opravovat i chyby, které jsou tam déle a netýkají se zrovna iOS. Jinak asi nepřesvědčí moc lidí, aby si kupovali nové verze, protože stejně jak pro tebe, tak i pro ostatní je VCL stále ještě hlavní zdroj obživy.

oxo

2.5.2013 10:28:51 #

ps

Asi tak ako píše OXO, mňa napr. strašne štvalo v Delphi 6 pri zatváraní okna, že na Vistách a vyššie (Aero) sa ikonka okna zmení na "default" a pôsobí to veľmi rušivo pri aplikácii ktorá otvára form za formom.  Po upgrade na XE to isté :( Dokonca aj v samotnom IDE Delphi XE.

http://qc.embarcadero.com/wc/qcmain.aspx?d=106255

video:
https://www.youtube.com/watch?v=F3jYZ7VsfVA

Simple riešenie (WM_SETICON):
http://www.delphinotes.ru/2013/01/blog-post_30.html

Je to už v XE4 opravené? QC je stále OPEN.

ps

5.5.2013 12:45:48 #

Daniel Andraščík

Mne sa zase v jednej aplikacii stava iny problem. Zobrazujem v nej nemale mnozstvo roznych okien. Modalnych, nemodalnych a aj okna ktorym pomocou CreateParams nastavujem hodnotu Params.WndParent. Nemal som este cas tento problem blizsie lokalizovat, ale stava sa mi ze ked zavriem niektore z tychto okien, tak sa mi cela aplikacia minimalizuje. Nemate niekto s tym skusenost?

Daniel Andraščík

Komentování ukončeno

Naše nabídka

Partial English version.

MVP
Ing. Radek Červinka - Embarcadero MVP
profil na linkedin, Twitter:@delphicz

Nabízím placené poradenství a konzultace v oblasti programování a vývoje SW.
Dále nabízíme i vývoj speciálního software na zakázku.

Neváhejte nás kontaktovat (i ohledně reklamy nebo burzy práce).

Pokud chcete podpořit tento server libovolnou částkou, můžete použít PayPal. Moc děkuji.

Delphi Certified Developer

O Delphi.cz

Delphi je jediný moderní RAD nástroj podporující tvorbu nativních aplikací pro platformu Win32, Win64 , Mac OSX a na iPhone a Android (s výhledem na další platformy díky FireMonkey) na současném trhu (včetně Windows 8.1).

V současnosti je světová komunita přes dva miliónů vývojářů.

Delphi.cz je nezávislý portál pro uživatele Delphi. Portál není koncipován pro úplné začátečníky, i když i ti se zde nebudou nudit, ale spíše na programátory, kteří již něco znají a chtějí své znalosti dále rozvíjet a sledovat novinky.

Anketa

Poslední komentáře

Comment RSS