Mam takich kilka banalnych pytań dla znających C#
Przesiadam się z javy i jestem nowy w C# moje pytanie jest takie jakie są metody robienia aplikacji okienkowych w c#. W javie wydaje mi się to takie przystępne. Mogę <ort>odpoczątku </ort>do końca być sam odpowiedzialny za kod. Buttony panele wszystko sam programuje. Po zainstalowaniu Visual C# nie mogę odnalźć na pewno robienie aplikacji w stylu drop and drag jest miłe ale czy można programować wszystko samemu od początku. Może jakiś linka do jakiejś ciekwej wypowiedzi na ten temat.
0
0
Zlituj się człowieku, piszesz w dziele 'C/C++', piętro niżej jest 'C# i .NET'. Co do pytań zaś - są przyklejone adekwatne tematy. Popraw temat na sensowny.
0
Programuję w Javie od paru lat i stosuję taki "podział obowiązków":
- prosty projekt edytor Context i kompilacja z wiersza poleceń
- duży projekt Eclipse bez stosowania drag and drop
W C# napisałem kilka prostych programów, również okienkowych, stosując zasadę sprawdzoną w Javie: Context i kompilacja z wiersza poleceń (csc). Programy działają, można mieć zatem pełną kontrolę nad kodem.
pozdrawiam
0
Zapytam tak z ciekawosci - a po co ta "pelna kontrola"? Nie wiem jak to jest w javie, ale jezeli chodzi o C# to dla mnie wystarczy drag&drop i bardzo mi to pasuje. Nie musze wglebiac sie w zadne szczegoly dotyczace tworzenia GUI - klikne i mam.
W ogole moim zdaniem niedobrze sie dzieje, jezeli tworzenie gui pochlania za duzo czasu, bo to nie jest programowanie. GUI to tylko interfejs użytkownika, ktory zawsze latwo zmienic (w dobrze zaplanowanym projekcie) i nie stanowi o wartosci programu jako takiego. Czesto mi sie zdarza ze pisze jakas klase i testuje ja w trybie tekstowym, bo tak jest wygodniej. A dopiero wtedy, gdy wiem ze dziala jak chce, tworze aplikacje gui i dolaczam do niej to co napiaslem wczesniej.
Nie wyobrazam wiec sobie sytuacji, gdzie bym musial recznie tworzyc obiekt kazdej kontrolki i moze jeszcze wyliczac gdzie ja ułożyć w oknie (bo designer to przeciez drag&drop i brak kontroli).
Zreszta w Visual C# kod tworzacy gui wygenerowany automatycznie zawsze byl dobrze oddzielony od reszty aplikacji w 2008 jest w oddzielnym pliku, we wczesniejszych wersjach byl w zwijanym regionie i rzadko kiedy trzeba w niego wnikać.
0
@othello, W Javie problemu rozmieszczenia komponentów graficznych na ogół nie ma - rozmieszczeniem zajmuje się menedżer rozkładu. Ja wyłączam menedżera tylko w celach testowych. Nawet bez menedżera tworzenie GUI nie jest pracochłonne. Kod rozmieszczający 10 przycisków po przekątnej i powodujący, że po kliknięciu przycisk zmienia napis na ikonę wygląda tak:
for (int i=1;i<=10;i++)
{
JButton b=new JButton(""+(i-1));
b.setPressedIcon(new ImageIcon("images/Open.gif"));
b.setBounds((i-1)*40,(i-1)*40,40,40);
add(b);
}
Dużo mniej pisania byłoby przy stosowaniu drag&drop ?
Komponent utworzony techniką drag&drop ma od razu jakąś nazwę, którą i tak zmienię, jest też automatycznie składową klasy opisującej okno. Ja wolę mieć trzy typy komponentów:
- komponent, który mogę całkowicie zbudować przy pomocy konstruktora komponentu, kod w konstruktorze okna wygląda tak (nie ma żadnej jawnej referencji do komponentu):
add(new JLabel("Nazwisko "));
- nie ma właściwego konstruktora komponentu, ale komponent nie będzie się zmieniał później (referencja jest zmienną lokalną)
JLabel l=new JLabel("Nazwisko"));
l.setFont(...);
add(l);
- komponent będzie się zmieniał później
private JLabel nazwisko;
....
nazwisko=new JLabel("Nazwisko: ");
add(nazwisko);
0
A kto mówi, że nie można w C# tworzyć interfejsu przy pomocy kodu?
for (int i = 0; i < 10; i++)
{
Button b = new Button();
b.Text = i.ToString();
b.Location = new Point(i * 40, i * 40);
b.Size = new Size(40, 40);
b.Click += new EventHandler(delegate(object sender, EventArgs e) { ((Button)sender).Image = Image.FromFile("images/Open.gif"); });
Controls.Add(b);
}
Fakt, konstruktory kontrolek WinForms nie pobierają żadnych argumentów, ale w C# istnieje ciekawsza rzecz:
Controls.Add(new Label() { Text = "label", Height = 100, Width = 50 });
Reszta jest identyczna.
Po prostu designer w Visual Studio jest na tyle dobry, że większość rzeczy naprawdę da się ładnie i szybko przy jego pomocy zaprojektować.
0
Hmm ostatnio zauwazylem nawet, ze zamieniane sa nazwy obiektow klas reprezentujących kontrolki, ktore nie zostaly wygenerowane automatycznie, czyli na przyklad jezeli napisze gdzies w kodzie:
button1.Text ="blabla";
To po zmianie w designerze button1 na przycisk1 automatycznie zostanie zmienione:
przycisk1.Text = "blabla";
Co do pisania interfejsu w kodzie jeszcze... no coz ja jestem przyzwyczajony ze mam tak jak klikne, zechce miec buttony po przekatnej to sobie poprzesuwam.... nigdy nie zagladam do kodu wygenerowanego przez designera, ale wiem jak dziala. I nie widze zadnej potrzeby zeby pisac go samemu....
w C# istnieje ciekawsza rzecz:
Zgadza sie, konstruktory nie musza pobierac nic bo istenieje taki zapis, to zreszta dotyczy kazdej klasy a nie tylko kontrolek.
0
Ręczne tworzenie kontrolek przydaje się chyba, gdy tworzy się aplikację chodzącą w trayu, nie posiadającą okna. Chyba nie da się czegoś takiego zrobić w designerze, prawda?
0
Hmm ale jak to nie posiadajaca okna? Aplikacja musi posiadac okno, tyle ze moze byc ukryte. Da sie w designerze, nie ma zadnego problemu.
0
@Rev.pl, podając przykład
for (int i=1;i<=10;i++)
{
JButton b=new JButton(""+(i-1));
b.setPressedIcon(new ImageIcon("images/Open.gif"));
b.setBounds((i-1)*40,(i-1)*40,40,40);
add(b);
}
nie sugerowałem, że tego się nie da napisać w kodzie C#. Chodziło mi o to czy końcowy efekt łatwiej osiągnąć pisząc kod, czy stosując designera.
0
jesli potrzebny ci statyczny interfejs, to jak najbardziej to co wyklikasz w designerze wystarczy, tym bardziej ze visual studio nic nie ukrywa, dostarcza tylko wizualnego narzedzia do projektowania gui, jak kazde wieksze IDE
wiec po co sie meczyc i pisac z palca co i gdzie ma lezec
ale jesli potrzebujesz interfejsu dynamicznego, np. w zaleznosci od jakiegos parametru wygenerowanc kilka pol, czy cos showac/wysunac etc. w tedy trzeba napisac kod z palca
po co utrudniac sobie zycie
ale jak juz napisano, tak w .net masz pelna kontrole nad kodem
tak, mozesz samodzielnie pisac kod tworzacy formularz
tak, nie musisz miec zmiennych w klasie formularza ktore trzymaja referencje, wystarczy ze stworzysz obiekt kontrolki i dodasz do kolejcji controls
zmiana button1 na przycisk1 wynika z prostej funkcji Visual Studio (inne wieksze IDE tez ja posiadaja), mianowicie refactor (nie wiem jak to na pl tlumacza bo refaktoryzacja, to troche co innego)
generalnie Visual Studio ma dostarczyc programiscie takich rozwiazan i narzedzi, aby ten mogl skupic sie faktycznie na programowaniu, a nie a duperelach jakim jest interfejs przecietnej aplikacji biznesowej
0
othello napisał(a)
Hmm ale jak to nie posiadajaca okna? Aplikacja musi posiadac okno, tyle ze moze byc ukryte. Da sie w designerze, nie ma zadnego problemu.
Nie lubię słowa "musi". Jest takie stanowcze...
Bez okna, czyli coś takiego:
using System;
using System.Windows.Forms;
using System.IO;
using System.Drawing;
namespace WithoutForm
{
static class Program
{
static void Main()
{
Application.Run(new WithoutForm());
}
}
internal class WithoutForm : ApplicationContext
{
private NotifyIcon trayIcon = new NotifyIcon();
private ContextMenuStrip trayMenu = new ContextMenuStrip();
private ToolStripMenuItem menuShow = new ToolStripMenuItem();
private ToolStripMenuItem menuExit = new ToolStripMenuItem();
internal WithoutForm()
{
InitializeMe();
}
private void InitializeMe()
{
//menuShow
this.menuShow.Text = "Pokaż";
this.menuShow.Click += new EventHandler(menuShow_Click);
// menuExit
this.menuExit.Text = "Zakończ";
this.menuExit.Click += new EventHandler(menuExit_Click);
//trayMenu
this.trayMenu.Items.AddRange(new ToolStripItem[] { this.menuShow, this.menuExit});
//trayIcon
this.trayIcon.Icon = Icon.ExtractAssociatedIcon(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "calc.exe"));
this.trayIcon.ContextMenuStrip = this.trayMenu;
this.trayIcon.Text = "WithoutForm";
this.trayIcon.Visible = true;
}
void menuShow_Click(object sender, EventArgs e)
{
MessageBox.Show("Samotranscendencja jest parafenomenem ewolucji!");
}
void menuExit_Click(object sender, EventArgs e)
{
Application.Exit();
}
}
}
Ja tu okna nie widzę, a aplikacja jest. Moim zdaniem nie widzę go, bo go nie ma, a nie dlatego, że jest ukryte. O obecności okna świadczyłoby chyba gdziekolwiek użycie słowa "Form", a tu też go nie widzę.
I teraz moje pytanie - jak to narysować w designerze, bo ja nie umiem :(
0
Użyłeś ApplicationContext zamiast Form, to raczej sztuczka :-) W designerze mozesz na przyklad zrobic, zeby formularz uruchamial sie zminimalizowany i wylaczyc pokazywanie na pasku zadan.
Z drugiej strony, nawet jak aplikacja jest w trayu, to i tak po wybraniu opcji z menu kontekstowego prawie zawsze jest jakis dialog ustawien i do tego bardzo nadaje sie glowne okno aplikacji, wieć wygodniej jak jest.
Poza tym nie napisalem nieprawdy - aplikacja okienkowa musi posiadac okno, czy to ukryte, czy widoczne. Tutaj nie uzywasz Form, ale z pewnoscia aplikacja jako taka okno posiada, tyle ze nie masz do niego dostepu
0
othello napisał(a)
Użyłeś ApplicationContext zamiast Form, to raczej sztuczka :-)
Ja wiem czy sztuczka - tak się po prostu robi, w zależności od tego, co się chce osiągnąć.
othello napisał(a)
W designerze mozesz na przyklad zrobic, zeby formularz uruchamial sie zminimalizowany i wylaczyc pokazywanie na pasku zadan.
Tak, mogę. Ale to nie będzie to samo. Wtedy to będzie właśnie sztuczka :) Na dodatek kiepska, bo do tego okna będzie się można dostać np. przez Alt + Tab. Tylko po co? Aplikacje ze schowka nie powinny dawać takiej możliwości.
othello napisał(a)
Z drugiej strony, nawet jak aplikacja jest w trayu, to i tak po wybraniu opcji z menu kontekstowego prawie zawsze jest jakis dialog ustawien i do tego bardzo nadaje sie glowne okno aplikacji, wieć wygodniej jak jest.
No tak, to jest wygodniejsze, bo mniej pisania i faktycznie wszystko wyklika się w designerze. Nie trzeba też przekazywać konfiguracji między aplikacją ze schowka i oknem konfiguracyjnym.
Za to bardzo nieeleganckie. Przecież konfiguracja jest dokonywana raz na jakiś czas, może nawet tylko raz, po pierwszym uruchomieniu programu i z tego powodu cały czas ma siedzieć w pamięci ukryte okno? Bez sensu.
othello napisał(a)
Poza tym nie napisalem nieprawdy - aplikacja okienkowa musi posiadac okno, czy to ukryte, czy widoczne. Tutaj nie uzywasz Form, ale z pewnoscia aplikacja jako taka okno posiada, tyle ze nie masz do niego dostepu
Faktycznie projekt kompiluje się jako WinForm, ale tego Form tu nie widzę tu ani ukrytego, ani tym bardziej widocznego.
Masz może gdzieś jakieś źródło na potwierdzenie swoich słów? Bo temat, chociaż bardzo teoretyczny, w sumie ciekawy :)
0
Masz może gdzieś jakieś źródło na potwierdzenie swoich słów?
Poznaj WinApi :P O ile dobrze pamietam, aplikacja musi posiadac okno, ktore obsluguje komunikaty. Nie ma okna - nie ma aplikacji ;P Wiec na tym najnizszym poziomie jest na pewno ukryte okno.
0
Zerknąłem Reflectorem na klasę Application i używa ona funkcji PeekMessage do odbioru komunikatów. A MSDN o tej funkcji mówi tyle, że odbiera ona komunikaty do okien oraz wątku. I jeżeli jako hwnd okna podamy null, dalej będziemy odbierać komunikaty. Z tego wynika, że do istnienia aplikacji potrzeba minimum wątku, a nie okna (w każdym razie .NET żadnego dodatkowego, ukrytego okna nie tworzy, jeżeli nie podamy go w ApplicationContext).
0
othello napisał(a)
Poznaj WinApi :P O ile dobrze pamietam, aplikacja musi posiadac okno, ktore obsluguje komunikaty. Nie ma okna - nie ma aplikacji ;P Wiec na tym najnizszym poziomie jest na pewno ukryte okno.
hehe, bzdura. Tego wcale być nie musi. Aplikacja może wyglądać tak:
for(;;)
{
Beep(); //czy jakoś tak
Sleep(10000);
}
:p
Ale owszem, jeżeli okno to i pętla komunikatów musowo (bezpośrednio, lub pośrednio np. funkją DialogBox).
//edit
A aplikacja Windows Forms jest pewnie oparta o pętlę w stylu:
for(;;)
{
switch(MsgWaitForMultipleObjectsEx(...))
{
//...
}
}
0
Aplikacja może wyglądać tak:
No w sumie... aplikacja nie zakonczy sie dopoki nie zakonczy sie WinMain. Ale szczerze mowiac nie pomyslalem o tym :P
0
Chyba to nie jest dokładnie odpowiedź na moje potrzeby tutoriali :-D ale Chyba się każdy zgodzi, że dobrze przejść przez mechanizm tworzenia GUI, żeby potem wiedzieć jak on działa. Z doświadczenia wiem, że łatwiej jest potem w użyciu.
To jeszcze raz się zwracam do doświadczonych użytkowników C# co byście poradzili na początku, znajomy polecał mi książkę C# i .NET Autor: Stephen C. Perry ale wydaje mi się trochę przestarzała 2006. Robię teraz tutoriala z http://www.learnvisualstudio.net/ ale jest trochę za banalny.
0
adak007 napisał(a)
To jeszcze raz się zwracam do doświadczonych użytkowników C# co byście poradzili na początku, znajomy polecał mi książkę C# i .NET Autor: Stephen C. Perry ale wydaje mi się trochę przestarzała 2006.
Ta ksiazka (mam i polecam) naprawde dobrze opisuje podstawy programowania w C# i .NET 2.0. Obecnie wersja 2.0 .NET Frameworka jest najbardziej popularna. Po przeczytaniu tej ksiazki bedziesz mogl zajac sie nowosciami w .NET 3.0 i 3.5 (WPF, WCF, LINQ)