tabControl bez zmiany tabpage

um..
wez usercontrol
poloz gdzies w szeregu np. na gorze NIE przyciski, a RadioButton(!) z ustawionym Appearance=Button(!!)
pod przyciskami poloz "panel" "P", duzy, zajmujacy reszte miejsca
wszystkiemu visible=true

na panelu "P" umiesc inny panel, "A", poukladaj na nim zawartosc storny pierwszej, daj panelowi Visible=false
na panelu "P" umiesc inny panel, "B", poukladaj na nim zawartosc storny drugiej, daj panelowi Visible=false
...

teraz podpnij sie pod Checked w radiobuttonach, i w danym radiobuttonie od strony piewszej:
B.Visible = false
C.Visible = false
D.Visible = false
...
Z.Visible = false
A.visible = true
teraz podpnij sie pod Checked w radiobuttonach, i w danym radiobuttonie od strony drugiej:
A.Visible = false
C.Visible = false
D.Visible = false
...
Z.Visible = false
B.Visible = true
itp

"i juz" masz swoj tabcontrol.. brzydki.. ale mozesz robic z nim i go przestawiac ile Ci sie podoba.
a jeszcze sobie to wszystko uproscisz jak zgromadzisz wszystkie panele "A" "B"..."Z" w tablicy/liscie i zaczniesz operowac na idei "selected index", nadasz radiobuttonom wartosci odpowiadajace, i potem wszystkim radio dasz jeden ten sam handler ktory w petli przeleci po liscie i poprzelacza wszystko

• serio, radze dac podwojny panel, z tego powodu, ze mozesz chciec czasem cos "recznie" dostrzelic do "obszaru roboczego" i wtedy posiadanie "panelu-obszaru roboczego" jest wygodniejsze niz pamietanie, ze obszar roboczy lezy 5pixów ponizesz przycisków. Z drugiej mańki "strony" tez dobrze aby byly pogrupowane w panele i byly dziecmi obszaru roboczego, aby przelaczanie Visibility bylo maksymalnie proste i "jednokrokowe", na wypadek gdybys mial miec na stronie 50 kontrolek.. wtedy iterowanie po nich i wylaczanie im kolejno visibility jest dosc nieladne wizualnie

Coś mi się zdaje że @disease chce jakoś modyfikować tylko część kontrolek po "przejściu na inny tab" = wciśnięciu "przycisku taba".
Jak napisał quetzalcoatl jeśli jakieś grupy kontrolek, które tworzą jakąś logiczną całość wydzielisz do UserControl, to będziesz mógł łatwo pokazywać/ukrywać odpowiednie części interfejsu.

No tak , dzięki , ale

• napisales ze mam stworzyc kilka paneli , ja chce 1 (jeden glowny , przeskakiwanie pomiedzy przyciskami wywola mi funkcje na jednym gridView, nie chce tworzyc kilku gridView dla kazdego taba) - spoko da sie zrobic tym sposobem ktory podales ale:

• ja chce generowac w runtime kolejne przyciski na bazie user input. Wiec tabów moze byc kilkadziesiat nawet, a wiec dochodzi zarządzanie nimi w przypadku gdy wychodza za ekran. Niestety tabcontrol to zalatwi ale radiobutton juz nie.

Natywna kontrolka tab właśnie tak działa jak opisałeś (to użytkownik jest zobligowany do wyświetlania osobnych dialogów na zmianę tab-a)! :) tylko wszystkie wrappery to ładnie oplatają w tabpage'a dla wygody ;)

Nieco inaczej : W tym momencie wkladam tabcontrol na forma. mam standardowo 2 tabPage : tabPage1 i tabPage2. W standardzie jest wcisniety tabPage1. Przycisniecie przycisku reprezentujacego tabPage2 powoduje przejscie na tabPage2 (:P) Ja chce zeby on został na tabPage1, wywolal zdarzenie (powiedzmy tabPageIndexChanged) , wcisnal tabPage2 (wizualnie przycisk) i to wszystko , bez przeskakiwania na tabPage2. Takie troche MDI tylko ze z jednym formem.

@Bartosz
Wlasnie problem w tym ze nie da sie zablokowac przeskakiwania na tab2 , nie ma zdarzenia PRZED tabIndexChanged, nie ma zadnego tabIndexChanging, nie mozna dac e.Cancel.

Zrób sobie natywną (a nie .NET-ową wersję) tab-a, przykład tworzenia natywnych kontrolek z C# http://msdn.microsoft.com/en-us/library/system.windows.forms.nativewindow.aspx

@Bartosz - wiesz, to już lekki overkill mu zalecasz.. nie przesadzajmy.. on to samo moze osiagnac zwyklym badziewnym UserControl'em, a jelsli to spali to wciaz moze to napisac calkiem prosto w samym C#/.Net dziedziczac po Control albo Panel. Do native'a nie schodzi sie po takie proste rzeczy.. Ok, chyba ze uda mu sie native-gotowca na to znalezc..

@disease
ale za to, mozesz TabPage2 ukryc, albo zrobic chamski test na selectedindexchanged w ktorym sprawdzisz :czy juz mozna: i jezeli nie mozna, to ustawisz selectedindex z powrotem na stary i walniesz msgboxa z informacja ze "nie skonczyles z poprzednia strona"..

btw. to co Ci napisalem to nie byl gotowiec, tylko idea, jak to rozwiazac. jesli nie chcesz tabcontrol, to doszlifuj sobie to co napisalem do swoich potrzeb i juz.. co do dynamicznego tworzenia tresci, to co za problem czy dynamicznie tworzysz nowe kontorlki na oknie czy na nazwanym pod-panelu?

btw. poza tym, kurcze, co Ty wlasciwie chcesz? napisales wtedy ze chcesz tabpage ale bez przelaczania "okien", a teraz piszesz ze chcesz miec przyciski ala tab na gorze, ktore dadza sie wcisnac, ale "i to wszystko" ?? to co one maja robic? nic same z siebie nie maja robic? chcesz miec jedynie callback ze ich stan sie zmienil i reszte przelaczania widocznosci kontrolek chcesz robic samemu? to juz Ci napisalem: RadioButton+Appearance=Button "i juz".

"chce generowac w runtime kolejne przyciski na bazie user input" - jaki problem? pętla i generujesz do jakiegoś panelu kolejne przyciski, czy dowolne inne kontrolki jakie chcesz. Używasz np. właściwości Tag do dodania tam jakiejś wartości, dzięki której rozpoznasz jaki to przycisk.
Podpinasz wszystkim buttonom na Click metodę obsługi, w której pobierasz Tag sendera i ustalasz co robić dalej.
To była najbardziej prostacka metoda.

Bardziej wyrafinowane rozwiązania, to stworzenie własnej kontrolki, która dostanie listę przycisków do stworzenia, po kliknięciu których będzie generowała ładne zdarzenie.
Lub od razu podpięcia pod przycisk odpowiedniej metody obsługi jego kliknięcia.
Lub dziedziczenie po button (lub innej kontrolce) i rozszerzeniu jej o np. delegat do wywołania po kliknięciu (zaznaczeniu).

Może napisz przykład jakie miałyby być te przyciski, co robić i co dokładnie oznacza "generowac w runtime kolejne przyciski na bazie user input", tzn. masz tylko nazwę przycisku, czy coś jeszcze, bo nie wiem co masz na myśli pisząc "user input"

OK.

1. mam gridView1; gridView1 leży w TabControl (w tej chwili). w tabPage1;
2. Uzytkownik klika przycisk "Dodaj" , wpisuje jakis tam tekst. Pojawia sie nowy tabPage o nazwie wpisanego tekstu roboczo nazwijmy go tabPage2.
3. Uzytkownik klika na tabPage2 (przycisk na tabControl zeby mozna bylo sobie wyobrazic, a więc klika nowy tab). W tym momencie gridView1 zmienia dataSource na inna kolekcje, na bazie przycisnietego taba. poza tym nic sie nie zmienia i dalej sie wyswietla gridView1.

Wlasnie wymyslilem ! zrobie tabPage o rozmiarze 0 , bedzie po prostu niewidoczny a zdarzenia sobie bede obslugiwal normalnie :)))) tlumaczac wam sam sie doprowadzilem do rozwiązania :))

jasniej : mojego gridView wkładałem do tabPage1. i przy zmianie na tabPage2 znikał. Tego chcialem uniknąć.
Rozwiązanie to postawienie gridView poza tabControl, bezposrednio na formie, okno TabPage ukryc i zostawić widoczne tylko zakładki z przyciskami do zmiany tabów.
Dzięki i pozdrawiam

Trochę na około i amatrosko. Obsługa innego source rozumiem że jest generyczna.
Czyli wyklikam sobie przyciski "Użytkownicy", "Zamówienia", "Faktury", to po kliknięciu jednego z tych przycisków załaduje mi się odpowiednia tabela.
Nie widzę żadnego przeciwskazania, aby dynamicznie generować przysicki i dokładać je do jakiegoś panelu na formie. Po kliknięciu innym przyciskom ustawiam normalny styl, a temu "wciśniętemu" np. zmieniasz kolor (bo żeby zmienić mu styl na wciśnięty to trochę więcej zabawy). Metoda obsługi Click jest jedna i na podstawie nazwy wykonuje select i ładuej dane do grid.

ty mowisz o zupelnie innych tabelach na jednym gridzie a to jest amatorsko. Ja poprzez te taby zakladam filtry np przez linq:
this.gridView1.DataSource = collection.Where(x=>x.type == typesEnum.someType); ale tabela z ktorej grid ciagnie dane sie nie zmienia. Dlatego nie chcialem miec kilku gridow.

Generujac dynamicznie buttony jak radzisz powstalby problem gdy przyciskow byloby na tyle duzo ze wychodzilyby za ekran. Nie mowiąc już o manulanej potrzebie rysowania przyciskow kiedy są focused, ustawiania ich położenia względem siebie itp. TabControl takie rzeczy zalatwia dlatego nie chcialem sie wplątywać w jakies buttony czy radio..

"mowisz o zupelnie innych tabelach na jednym gridzie a to jest amatorsko" - zależy, jeśli chcesz mieć generyczny mechanizm wyświetlający dane z dowolnego źródła to nie jest to wcale amatorsko, wręcz przeciwnie, nie wyobrażam sobie tego inaczej, niż stosować jednego grid'a, czy ogólniej kontrolki wyświetlającej dane. Oczywiście źródło może zwracać też metadane precyzujące jak pewne elementy (czy nawet całość) zaprezentować.
Nie napisałeś też że "taby" to tak na prawdę filtry. Pomijam kwestię że trochę osobliwe rozwiązanie wymyśliłeś. Rozumiem że tekst na tab parsowany jest do jakiejś wartości enuma. Dlaczego nie zrobisz combobox'a do wyboru filtru? Lub po prostu kontrolek do filtrowania nad odpowiednimi kolumnami. Podpatrz sobie rozwiązania np. DevExpress czy Telerika.

Rozumiem że jeśli chodzi o pozycjonowanie kontrolek etc. nie masz doświadczenia, stąd łatwiej użyć ci TabControl i w sumie jest to ok podejście.
Zachęcam do zapoznania się z Dock i Anchor.
Możesz też podpatrywać pewne rozwiązania na codeproject.com, można tam sporo fajny rozwiązań znaleźć.

massther napisał(a)

"mowisz o zupelnie innych tabelach na jednym gridzie a to jest amatorsko" - zależy, jeśli chcesz mieć generyczny mechanizm wyświetlający dane z dowolnego źródła to nie jest to wcale amatorsko, wręcz przeciwnie, nie wyobrażam sobie tego inaczej, niż stosować jednego grid'a, czy ogólniej kontrolki wyświetlającej dane. Oczywiście źródło może zwracać też metadane precyzujące jak pewne elementy (czy nawet całość) zaprezentować.
Nie napisałeś też że "taby" to tak na prawdę filtry. Pomijam kwestię że trochę osobliwe rozwiązanie wymyśliłeś. Rozumiem że tekst na tab parsowany jest do jakiejś wartości enuma. Dlaczego nie zrobisz combobox'a do wyboru filtru? Lub po prostu kontrolek do filtrowania nad odpowiednimi kolumnami. Podpatrz sobie rozwiązania np. DevExpress czy Telerika.

Rozumiem że jeśli chodzi o pozycjonowanie kontrolek etc. nie masz doświadczenia, stąd łatwiej użyć ci TabControl i w sumie jest to ok podejście.
Zachęcam do zapoznania się z Dock i Anchor.
Możesz też podpatrywać pewne rozwiązania na codeproject.com, można tam sporo fajny rozwiązań znaleźć.

Latwiej szybciej , debug free. W zasadzie to bylo czego szukalem, analizowalem inne rozwiązania i po prostu to mi odpowiadalo, nie chciałem się zakopać w tworzenie custom controlek , skoro ta funkcjonalność już istnieje, trzeba było tylko wymyślić workaround.

Co do grida , z refleksji musialbys tworzyc kolumny na bazie pol w klasie, czy tam dataset, entity czy co uzywasz. Niezle rozwiazanie nie pomyslalem o tym ,ale w tym projekcie ktory aktualnie robie jest mi to zupełnie niepotrzebne. Wydaje mi sie jednak że ciężej byłoby tym zarządzac, nie mając tego w designerze. Szkoda mojej pary na takie rozwiązania, tylko po to żeby wyświetlić jedną tabelę :)

Taby to nie filtry. Podalem ci to jako przykład. będą to różne zestawy danych z jednej tabeli. Na przyciskach tabów bede potrzebował wyświetlić stan (zajęty ,działa) w postaci ikonki - combo odpada.

Dzięki za komentarz, jednak zostane przy swoim rozwiązaniu , gdyż implementacja tego nie zajela mi dłużej niż 5 min (poza szukaniem jak to zrobić oczywiscie)

sluchaj, nie chce marudzic.. ale na serio zamiast tabow z wysokoscia zero, nie sensowniejsze byloby wziecie radio ze skinem (toggle)button?
wiem ze one troche inaczej wyglada, ale daja Ci wiecej kontroli w kontekscie blokowanie/enabled/visible/itp..

a jak rozwiążesz to:

http://img843.imageshack.us/i/beztytuucn.jpg/

edit : oczywiscie tak zeby sie nie narobic ;)

hmmm, kilka sztuczek i da się zrobić.
panel w panelu i w tym wewnętrznym przyciski, a w zewnętrznym te przyciski do przesuwania, które powodują odpowiednie przesuwanie panelu wewnętrznego, oczywiście do tego trochę warunków, żeby nie przesuwać zbyt dalego tego panelu wew.
to taki na szybko pomysł :) można oczywiście bardziej pokombinować

massther napisał(a)

hmmm, kilka sztuczek i da się zrobić.
panel w panelu i w tym wewnętrznym przyciski, a w zewnętrznym te przyciski do przesuwania, które powodują odpowiednie przesuwanie panelu wewnętrznego, oczywiście do tego trochę warunków, żeby nie przesuwać zbyt dalego tego panelu wew.
to taki na szybko pomysł :) można oczywiście bardziej pokombinować

obliczac szerokosc forma, dzielic przez liczbe przyciskow i takie tam, potem przestawiac o rozmiar przyciskow po przycisnieciu strzalki. Stosunkowo latwe, jak zacznie mnie tabControl ograniczac to bede musial przy tym przysiasc i to zrobic.