C# + aplikacja WPF a reklamy w aplikacji.

Witam!
Stawiam pierwsze kroki w programowaniu w C#, stworzyłem sobie ostatnio aplikację WPF która po prostu mi się przyda, ale do rzeczy.
Kolega zażartował by puścić ją w świat, dodać reklamy i robić $. Wolne żarty, ale z drugiej strony narodziło to we mnie pytanie. Czy jest jakiś sposób na generowanie dochodów ze swojej aplikacji WPF? Wiem, że jest to możliwe w UWP, ale jestem posiadaczem Windows 7.
Polecacie coś? Istnieje jakaś opcja "tak na przyszłość"?
Serdecznie pozdrawiam

W zasadzie skoro stawiasz pierwsze kroki w C# to naprawdę jesteś pewien, że Twoja aplikacja nadaje się do szerszego rozpowszechnienia?

Siedzę w .NET'cie już w sumie 5 lat i w stosunku do własnych apek często się nad tym poważnie zastanawiam, a co dopiero będąc na początku drogi...

Może pokaż co zrobiłeś. Ktoś Ci doradzi, pomoże... jeżeli dopiero zaczynasz to na bank robisz jakies błędy, ktorych nawet nie widzisz.

Warto przemyśleć to pod tym kątem.

Jasne, jestem kompletnie świadomy tego, że jest to odległa przyszłość, lecz po prostu zainteresował mnie owy temat który pojawił się po żarcie znajomego.

Pod względem działania. - Działa.

Najbardziej boli mnie fakt paskudnego UI i za pewne można by znaczenie kod osłodzić. Nie mniej jeśli uda mi sie na GitHuba wrzucić (chociaż przyznaje się bez bicia mam z tym nie lada problem), to podrzucę, chyba, że chodziło Ci o wstawienie samego kodu.

Nie mniej pomysł sprawdzenia na pewno byłby bardzo dobry dla procesu nauki, zwłaszcza gdy nie za bardzo wiem czy i kiedy powinienem stosować nowe klasy, gdzie do tej pory w C posługiwałem co najwyżej funkcjami.

Git spokojnie starczy. :)

https://github.com/Sebixxu/SummsCD/commit/f4d962cb5b57bcddd0efad232f80b17a229df84e
Chyba się udało..
Prosiłbym bez linczu, konstruktywne wytykanie błędów. <3

// Z własnych luźnych przemyśleń, za pewne do innej klasy można by wrzucić wypełnianie ComboBoxów. Czy moje myślenie jest poprawne? Bo ciężko mi zrozumieć istotę oddzielnych klas jak na ten moment.

1. Wnętrze metody FillInComboBox jest nienajlepsze. Nie każda kontrolka musi mieć nazwę. W zasadzie to żadna takowej mieć nie musi. Zrób tablicę jednakowych kontrolek i wypełniaj nimi widok, bo tak to masz wsadzanie identycznych itemów do całej masy kontrolek. Na to wystarczyłaby jedna pętla;

2. Zamiast czegoś takiego void dtTicker(object sender, EventArgs e) możesz użyć zwykłej lambdy np. dt.Tick += (sender, e) => { };. Zazwyczaj jest to bardziej pomocne i mniej zaciemnia kod;

3. Nazwy metod zawsze piszemy z wielkiej litery i raczej w czasowniku, żeby mówiły o tym do czego owe metody służą;

4. Wszystkie te metody private void adcButton_1_Click(object sender, RoutedEventArgs e) można zastąpić jedną zwyczajnie przypinając do zdarzenia Click wszędzie tę samą metodę. Rozpoznawanie jaka to kontrolka można zrobić korzystając z obiektu sender, a i tego w zasadzie robić nie trzeba, bo tak na pierwszy rzut oka wystarczy zwyczajnie przekazać sendera do SwitchCaseMethod zamiast wstawiać kontrolkę po nazwie po kolei;

5. SwitchCaseMethod hmm... trochę dziwne są tam te switche. Dałoby się to pewnie jakoś przeorganizować :)

6. Regiony... jedni lubią, inni nie lubią. Zasadniczo regiony trzeba pozamieniać na metody ale w przypadkach kiedy chce się oddzielić np. pola prywatne od reszty to te pola można zaregionować i ja tam nie widzę w tym tragedii;

7. W samym XAML'u masz niezakotwiczone kontrolki, a ich rozmieszczenie jest oparte sztucznie na marginesach np. Margin="658,247,0,0" etc... To może rodzić wielorakie problemy. Zainteresuj się rozbudowaniem tego Grid'a wewnątrz, którego wszystko masz. W necie jest tego pełno żeby pooglądać.

Kod tego programu można by tak nawet o 2/3 skrócić :)

BTW: jak już idziesz w WPF czy inne technologie oparte o XAML to po poznaniu podstaw zainteresuj się MVVM.

1. Myślałem nad tym, na tablice nie wpadłem a na pierwszym roku były "tłuczone" do upadłego.
2. Przyznaję się, że ta metoda jest bardziej "kradziona" niż moja, miałem spory problem ze zrobieniem odliczania od tyłu, ale chętnie zastosuję poprawkę!
3. Cenna uwaga, niby mi znana, ale jak widać sporo jeszcze ucieka.
4. Nie wiem czy do końca zrozumiałem, w jaki sposób przypinając? Druga część wydaje mi się bardziej zrozumiała.
5. Też nie bardzo mi się podobają, ale uznałem, że lepsze to od wielokrotnych if'ów :P
6. Będę miał to na uwadze.
7. Aktualnie zablokowałem resize okna bo mniej więcej o to mi chodziło, ale fakt, układ okna w xaml'u rodził już problemy i rano oglądałem różne xamlowe cuda, ale aktualnie nie zmieniałem za dużo, bo mam kilka pomysłów na dodatkowe opcje na przykład korzystanie z API. I właśnie, miałbyś jakieś sprawdzone poradniki/porady co do pobierania danych z API? Czy to kwestia "indywidualna"?

Nie mniej, bardzo, bardzo dziękuję, za wszelkie uwagi. Chociaż i tak pozwolę sobie być z siebie względnie dumnym z "pierwszego cuda"! :D

Mam problem!
Uznałem, że dodam sobie przycisk resetowania danego odliczania.
Przycisk po jego naciśnięciu, ma przerywać odliczanie -> wypełniać dany Label: "READY!" i odblokowywać przycisk.

private void StopingCountdown(DispatcherTimer dt, Button positionButton_number, Label positionLabel_numer)
        {
            dt.Stop();
            positionLabel_numer.Content = "Ready!";
            positionButton_number.IsEnabled = true;
        }

Wyciągnąłem to i owo z if'a w metodzie CountingDown, ale skończyło się to tym, że nie mam dostępu do DispatcherTimer dt, jest jakiś sposób by po za tą metodą przekazywać właśnie ten DispatcherTimer? Czy w jakiś inny sposób trzeba to obejść?

Później uznałem, by po prostu wywołać po naciśnięciu przycisku Reset metodę CoutingDown z wartością początkową która odliczamy tak by przy pierwszym obrocie od razu doszło do zera. I faktycznie to się dzieje, ale potem poprzednia metoda wygrywa i tak kończy swoje odliczanie.