dotNETportal.cz

Ahoj, potřebuju vytvořit navigační tlačítka (předchozí / další), která by byla umístěna na stále zobrazeném navigačním panelu a pomocí nichž by se dalo přejít na další nebo předchozí formulář (něco jako jsou šipky v internetovém prohlížeči). Existuje ve VB.Net 10 nějaká vhodná komponenta? Setkal jsem se s tím pouze u procházení dat v tabulce, ale pro přecházení z formuláře na formulář jsem nic nenašel. Na netu jsou příklady právě jen pro procházení dat a tady na fóru jsem taky nic nenašel.

Tohle se neřeší několika formuláři, ale jedním formulářem s TabPanelem, který má skryté záložky. Přepínáním Další Předchozí se potom zobrazují panely s požadovaným obsahem.

To je samozřejmě možnost, ale já bych to chtěl řešit jako u internetového prohlížeče. Nad formuláři je stabilně lišta s tlačítky, které jsou svázané s jednotlivými formuláři. To mi funguje a v podstatě bych ty navigační tlačítka nepotřeboval, jenom mně zajímá, jak se to řeší. Stačily by mi dvě, dopředu a zpátky. Na netu jsem našel nějaké příklady, ale ty se týkaly OutLooku. Díky.

Ve webovém prohlížeči je to řešeno rovněž jedním formulářem. Šablona pro IE/Průzkumník-like aplikaci se ve WPF jmenuje Browser Application, ve Windows Forms je to možné udělat pouze mnou uváděným způsobem.

Alternativní možností je použít UserControl.

http://www.vbnet.cz/clanek--39-vytvareni... Tento článek danou problematiku popisuje.

Pokud takové uživatelské prvky máte, můžete je dát do TabControlu, jak navrhl pan Linhart, díky enkapsulaci dceřinných prvků v UserControlu nebudou nijak interferovat s UI hlavního okna (z hlavního okna ani nebudou vidět) a formulář bude snazší na údržbu, jelikož jeho logika bude rozdělena do menších celků.

Druhou možností by bylo nepoužít TabControl, ale držet si komponenty v code-behindu formuláře. Příkladem budiž slovník Dictionary<string, Control>, kam byste jednou (buď při vytvoření formuláře, nebo při prvním dotazu na daný klíč) načetl komponenty a poté pouze vracel reference na ně. Na formuláři by tam nebyly všechny komponenty zároveň, ale pouze jedna aktuální. Výhodou je to, že se zkrátí doba vytváření formuláře, protože komponenty se nebudou načítat všechny naráz ale až když budou potřeba. Ovšem pokud v kontruktoru komponent nebude probíhat nic výpočetně náročného, rozdíl bude zanedbatelný a řešení s TabControlem bude komfortnější.

1) Proč vytvářet další kolekci ovládacích prvků, když k tomu účelu je Controls, do kterého by se to stejně muselo ve výsledku zkopírovat?

2) Režie na vytvoření ovládacích prvků v konstruktoru formuláře je zanedbatelná, ovšem probliknutí/čekání na jejich vytvoření na žádost se už negativně projeví na straně uživatele při práci s aplikací. Kromě toho je to spousta zbytečného kódu navíc.

Proto bych toto řešení zavrhnul už od začátku.

On-demand vytváření ovládacích prvků by mělo smysl, pokud by v jejich konstruktoru byla nějaká dlouhotrvající logika, která by tím pádem protáhla i trvání konstruktoru fomuláře, jež by je načítal.

Nicméně je pravda, že typicky se jedná o zanedbatelné časy a pokud ne, dají se vracet prázdné prvky a data dosazovat asynchronně. Toto byl pouze nástin alternativního řešení, souhlasím s tím, že TabControl je nejlepší cesta, ale pokud by se jednalo o složitější formulář, resp. záložky, zkombinoval bych to s UserControly z důvodů, které jsem již načrtl - snadná správa jednotlivých částí i celku.

Co znamená dají se vracet prázdné prvky?

Omlouvám se za nejasné vyjádření, měl jsem tím to, že většinou je možné přenést logiku získávání dat do separátního vlákna z konstruktoru ovládacího prvku. Připomínám, že mluvíme o hypotetické situaci, kdy procedura vytvoření a inicializace prvku trvá delší časový úsek. Vracet prázdný prvek pak mělo znamenat vracet prvek, který zatím není naplněný daty a proces načítání dat, která prvek prezentuje nebo nějakým jiným způsobem utilizuje (a jejichž generace nebo načtení je hlavní faktor zapřičiňující prodlevu při tvorbě prvku) spustit asnychronně v konstruktoru (čímž by se samotná exekuce konstruktoru zrychlila, ale vrátili bychom "prázdný prvek" - prvek vytvořený, ale datově nenaplněný nebo jehož naplňování právě probíhá) nebo na vyžádání podobně jako by šlo na vyžádání získávat instance ovládacích prvků.

Nezlobte se na mne, ale to co píšete nedává smysl, protože se snažíte popisovat triviální věci pseudoodborným způsobem.

Dobře, omlouvám se. Vlákno je vyřešené, takže myslím, že naší diskuse již není třeba.