czwartek, 13 listopada 2008

Explorer View w Sharepoint

Co jesli nie Sharepoint 2007 nie chce wyswietlać struktury katalagów w Explorer View?
Ja poza doinstalowaniem sp1 :) dołożyłem jeszcze:
- webdav w IIS na serwerze,
- IE7 na maszynie klienckiej,
- i najważniejsze ze wszystkich: Software Update for Web Folders (KB907306)

Ten ostatni dodatek powinien być na każdej maszynie klienckiej. Explorer View włącza nam opcję przeglądania struktury np. Document Library w oknie przeglądarki tak jak "ulubiony" explorer w windows. Niestety explorer view nie zachowuje się tak dobrze jak jego formsowy brat. Problemy objawiają się tym że explorer view nie wszystko sobie odświeża w odpowiednim czasie. I tak po przeniesieniu katalogu w nowe miejsce i odświeżeniu nowego miejsca okazuje się że tego katalogu wcale tam nie ma. Choć w Columns View faktycznie istnieje, najfajnieszje jest to że to zachowanie jest niedeterministyczne. Jak do tej pory nie udało mi się znaleźć odpowiedniej poprawki.
Jeśli potrzebuje kopiować przenosić z Explorer view to używam go zamiennie z Columns View.

piątek, 7 listopada 2008

Aktualny katalog aplikacji

Zazwyczaj do tej pory aby pobrać aktualną ścieżkę do programu zawsze używałem:
Environment.CurrentDirectory, ostatnio okazało się że nie zawsze dostaje ścieżkę której oczekuje :)
Przykładowo jeśli utworzymy szybką konsolową aplikację taką jak:

using System;
using System.Windows.Forms;

namespace ConsoleApplication3
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Environment.CurrentDirectory);
Console.WriteLine(Application.StartupPath);
Console.ReadLine();
}
}
}


a następnie utworzymy do niej defultowy skrót na pulpicie to co nam wyświetli aplikacja po uruchomieniu?:

C:\Documents and Settings\mak\My Documents\Visual Studio 2005\Projects\testPath\
ConsoleApplication3\bin\Debug
C:\Documents and Settings\mak\My Documents\Visual Studio 2005\Projects\testPath\
ConsoleApplication3\bin\Debug

ok, a teraz jeśli usuniemy z propertisów skrótu opcję: "Start in" ?:

C:\Documents and Settings\mak\Desktop
C:\Documents and Settings\mak\My Documents\Visual Studio 2005\Projects\testPath\
ConsoleApplication3\bin\Debug

Wyników komentować nie trzeba:)

czwartek, 6 listopada 2008

IV Seminarium Krakowskiej Grupy Regionalnej SPMP

Miałem okazję ostatnio uczestniczyć w seminarium KGR na WSE w Krakowie.
Były to dwa około godzinne wykłady:
W1: Motywowanie członków zespołów projektowych - GRZEGORZ SIKORA
W2: "Mocne i słabe strony oprogramowań wspomagających zarządzanie projektami typu open source" - KRZYSZTOF CZOBA

Jeśli chodzi o W1 to był to wykład bardziej poświęcony tematyce Przywództwa niż motywowania. Wykład był podzielony logicznie na dwa tematy: skuteczne działanie(jak dla mnie autor streścił w pół godziny książkę Coveya swoimi słowami) i przywództwo. W drugiej częsci też wydaje mi się że wykład był poprowadzony na podstawie jakiejś książki. Z której między innymi zapamietałem fajny cytat:
"Lider za którym nikt nie podąża to spacerowicz"

Drugi wykład W2 prowadzony przez Krzystofa Czobe(kierownika działu IT jednej ze śląskich firm) dotyczył głównie programu dotproject. Od razu wiadomo było że autor nie ma wykształcenia informatycznego i jest bardziej domorosłym informatykiem, ale ta wiedza całkowicie mu wystarcza do zarządzania działem IT. Z tego wykładu najbardziej spodobała mi się jedna z ekonomicznych zasad o której pierwszy raz usłyszałem - Zasada ABC.

Jeśli chodzi o samą organizacje seminarium to wszystko było jak najbardziej wporządku i myślę że przy każdym takim evencie będę chciał w nim uczestniczyć.

ContextMenu, ToolStripMenuItem, Checked

Defaultowe zachowanie ContextMenu polega na tym że po wybraniu konkretnego elementu, context menu sie chowa. A co w przypadku kiedy nie chcemy żeby się chowało ? Przykładowo mamy Context Menu które oczywiście się otwiera po przyciśnięciu prawym klawiszem myszy i jest generowane dynamicznie. Zazwyczaj niech zawiera 2-3 stałe przyciski(ToolStripMenuItem) i do kilkunastu ToolStripMenuItem z włączaną opcją Checked. Ktoś odpowie ale to już nie jest defaultowe context menu i w tym celu należy użyć customowej kontrolki i pewnie ma rację. Ale ContextMenu supportuje nam bardzo fajny propertis:

m_ContextMenuStrip.AutoClose = false;

AutoClose pozwala nam po zdarzeniu kliknieciu na Item w ContextMenu nie zamykać go.
Nie ma róży bez kolców :) ContextMenu będzie teraz wisieć nam wiecznie, i niestety trzeba wygenerować jego zamknięcie przy zdarzeniach generowania samego ContextMenu.
Czyli jeśli wyłączamy AutoClose to automatycznie kliknięcie poza obszar ContextMenu nie spowoduje jego zamknięcia.

W moim przypadku było akurat drzewo(TreeView) które dla każdej gałęzi(node) i korzenia(root) mogło wygenerować inne Context Menu i odbywało się to na zdarzeniu MouseUp.

Więc rozwiązaniem problemu wiszącego ContextMenu jest:

protected override void StructureTreeView_MouseUp(object sender, MouseEventArgs e)
{
if (m_ContextMenuStrip.Visible)
{
m_ContextMenuStrip.Visible = false;
m_ContextMenuStrip.Close();
}

if (e.Button != MouseButtons.Right)
return;

m_ContextMenuStrip.Items.Clear();
...
m_ContextMenuStrip.AutoClose = false;
m_StructureTreeView.SelectedNode = node;
m_ContextMenuStrip.Show(m_StructureTreeView, new Point(e.X, e.Y));

}


Tak więc w przypadku jakimkolwiek kliknięciu poza obszar ContextMenu, pierwszy if sprawdzi czy jest ono otwarte(Visible) i je sobie zamknie :)

Ma to jednak jeszcze jeden bug którego nie udało mi się rozwiązać ale który nie jest aż tak strasznie dokuczliwy. Otóż jeśli otworzymy ContextMenu i uruchomimy InternetExplorera to ContextMenu będzie przez niego prześwietlać :)