Fullscreen & Debug – AddIn do VS

Jako, że w tej chwili jestem trochę uziemiony odnośnie pisania kolejnych wpisów o TPL (ale spokojnie powrócę do nich) postanowiłem napisać o czymś innym. Ale po kolei…

Wszystko zaczęło się od pytania na portalu devpytania.pl. Zacząłem się zastanawiać czy rzeczywiście nie ma jakiejś metody na to. Fullscreen’a, aż tak często nie używam, ale czasem się zdarza i rzeczywiście zachowanie to jest denerwujące. Tak więc postanowiłem coś z tym zrobić i napisać małego AddIn’a do VS, który będzie za to odpowiedzialny.

Zatem do działa.

Nie będę się rozpisywał co trzeba kliknąć w VS, aby stworzyć projekt AddIn’a bo z tym nawet najbardziej początkujący sobie poradzą. Zaczynamy zatem od momentu jak już nasze pliki zostaną utworzone. To co musimy zrobić to dowiedzieć się kiedy aplikacja jest w trybie Debug a kiedy nie, czy jesteśmy uruchomieni w trybie pełnoekranowym oraz to jak się przełączać w pomiędzy normalnym oknem a tym trybem.

Tryb pracy

Musimy rozeznać się w jakim trybie pracy aktualnie się znajdujemy a konkretniej musimy być powiadamiani przy zmianie tego trybu z Debugowania na Normalny. Na szczęście API pluginów dostarcza nam eventy. Jednym z nich jest ModeChanged. Jak się do nich podpiąć?

  _events = _applicationObject.Events.DTEEvents;
  _events.ModeChanged += DTEEvents_ModeChanged; 

Od razu uwaga. Uzywać należy naszej zmiennej w klasie przy podłączaniu się do eventów. Taki kod jak poniżej nie zadziałą prawidłowo
(ale nie będzie też rzycać wyjątków. Będzie wyglądało tak jakby eventy nie przychodziły).

_applicationObject.Events.DTEEvents.ModeChanged += DTEEvents_ModeChanged; // Nie zadziała!!!

Po podłączeniu się do eventów będziemy otrzymywać powiadomienia o zmianie wraz z parametrem LastState (będącym enumeracją vsIDEMode). Zatem możemy już działać.

Komunikaty na zewnątrz

Krótka przerwa przed kontynuacją. Choć AddIn’y możemy spokojnie debugować to czasem warto mieć możliwość wypisania czegoś na ekran. Tu przychodzi z pomocą konsola OutputWindow. Możemy dodawać do niej nasze “zakładki” i na nich pisać. Jak to zrobić pokazuje kod poniżej:

Windows w = _applicationObject.Windows;            
Window ww = w.Item(Constants.vsWindowKindOutput);
OutputWindow outputWindow = (OutputWindow)ww.Object;
outputPane = outputWindow.OutputWindowPanes.Add("Octal Solutions - Fullscreen & Debug");

Ostatnia instrukcja daje nam obiekt, na którym możemy wywołać metodę OutputString i nasz tekst ukaże się na naszej zakładce w oknie Output.
Uzbrojeni w taką wiedzę możemy przejść dalej.

Tryb pełnoekranowy

Z tym jest najwięcej problemów, bo nie udało się znaleźć właściwości czy metody zawracającej tę wartość. Trzeba sprawdzić rozmiar głównego okna VS:

private bool IsFullScreen()
{
    System.Drawing.Rectangle screen = System.Windows.Forms.Screen.PrimaryScreen.Bounds;
    var mainWindow = _applicationObject.DTE.MainWindow;
    return mainWindow.Width == screen.Width && mainWindow.Height == screen.Height;
}

Zmiana trybu pracy

Chyba najprostsza z tych rzeczy. Wystarczy wykonać polecenie View.Fullscreen. Visual Studio przełącza się pomiędzy pełnym ekranem a normalnym oknem.

_applicationObject.ExecuteCommand("View.Fullscreen", "");

W zasadzie to już wszystko co musimy zrobić aby nasz AddIn zadziałał. Warto pamiętać jeszcze o odłączeniu się od zdarzeń, gdy zostaje on wyładowane z pamięci tak by zostawić po sobie porządek.

Pełny plugin można ściągnąć używając poniższego linka: Fullscreen & Debug. Jeśli masz jakieś komentarze, uwagi napisz do mnie lub zostaw komentarz pod postem.

TPL – Zaczynamy

Tę serię przede wszystkim należy zacząć od pytania – po co nam to? To z kolei możemy rozbić na dwa kolejne. Po co nam w ogóle programowanie równoległe oraz po co nam TPL – przecież już mamy dostępne narzędzia.

Po co nam to w ogóle

Mam nadzieję, iż tak na prawdę na to pytanie odpowiadać nie trzeba, ale dla porządku zróbmy to. Potrzebujemy bo prawo Moore’a przestaje działać. Nie możemy już powiedzieć naszemu klientowi, który narzeka na słabą wydajność aplikacji, że gdy będziemy wydawać to oprogramowanie to procesory będą dwukrotnie szybsze więc nie będzie problemu (pytanie: czy ktoś kiedykolwiek tak powiedział?? :)). Dodatkowo procesory teraz posiadają 2 lub więcej rdzeni więc tak na prawdę wykorzystujemy tylko cząstkę dostępnej nam mocy. Przez to nasze aplikacje pracują mniej wydajniej i obciążając procesor blokują inne.

Po co nam TPL

No dobrze. Nawet jeśli widzimy potrzebę wykorzystania drzemiącej mocy naszych procesorów, to po cóż nam coś nowego? Przecież mamy namespace System.Threading. Po cóż więc nam coś nowego – jakieś Taski i inne takie? W zasadzie - po nic. Problem z System.Threading jest jednak taki, że API tam dostępne jest skomplikowane i przez to nie jest wykorzystywane w wielu przypadkach. Zrównoleglenie kodu zawsze zostawiamy na potem, aż w końcu po release’ie stwierdzamy, że znów zapomnieliśmy o nim – no bo w końcu wydajność to nie jest nasz priorytet.

TPL wprowadza nową jakość do wątków – udostępnia je – jak to powiedział Scott Hanselman – dla mas. Dzięki nowemu i prostszemu API więcej osób w łatwy sposób będzie mogło zrównoleglić kod w swojej aplikacji. Jednak nie dajcie się zwieść – to, że API jest łatwe, ładne i przyjemne nie oznacza, że nie można za jego pomocą zrobić sobie krzywdy. Można! Jednak jeśli będziemy uważni, możemy dużo więcej osiągnąć.

Na dziś tyle. Zainteresowani tematem znajdą dużo informacji w linku poniżej – a już niedługo przestanę teoretyzować i zaczniemy bawić się naszym nowym API.

Link: Parallel Computing

Task Parallel Library - nowy kurs

Dawno już nie pisałem na blogu. Nie chcę tłumaczyć się, że zarobiony jestem i nie mam na nic czasu (choć tak jest :)) wiec postanowiłem zamiast tego wyznaczyć sobie temat, o którym będę pisał i starać się pisać przynajmniej raz w tygodniu. Dzięki temu stworzę kurs jak w przypadku WPF oraz będę dość regularnie pojawiały się nowe wpisy na blogu.

O czym więc będzie kurs?

Task Parallel Library (TPL) – bo o tym chcę rozpocząć nowy cykl postów to nowe podejście do programowania równoległego, które pojawiło się (jak na razie beta) wraz z .NET Framework 4.0. Zmienia się API, pojawiają się nowe rzeczy, które my programiści możemy wykorzystać ale także pojawiają się pułapki i zagrożenia, z których czasem możemy nie zdawać sobie sprawy.

Dziś zatem tylko notka informacyjna. Zachęcam do odwiedzania. Już wkrótce postaram się opublikować pierwszy wpis.

WPF Attached Properties - Wideo

Jakiś czas temu nagrałem kilka filmów omawiających tematy poruszane przeze mnie w kursie o WPF. Postanowiłem, że kilka z nich umieszczę na blogu jako, że w chwili obecnej nie mam dla nich lepszego zastosowania a mam mało czasu na pisanie nowych postów :).

Miłego oglądania. Uwagi, jak zawsze, mile widziane.