jarda jirava .net - stránky věnované .net technologii, vývoji software s pomocí .net frameworku, návrhu software a architektuře řešení builder.cz

Ve středu se uskutečnilo již IV. setkání příznivců a přispěvatelů .net fóra na serveru builder.cz. Ten kdo dorazil snad nebyl zklamán a strávil několik málo hodin v přitomnosti kolegů vývojářů.

Hned v úvodu musím poděkovat všem, kteří se zúčastnili za jejich dochvilnost a dobrou náladu. Pro ty, kteří nedorazili a nebo neměli tu možnost se dostavit, přináším krátké shrnutí tak jak jsem byl schopen si probíraná témata zapamatovat.

Rekapitulace

Snad hned na úvod neprozradím nic tajného, když jsme se dozvěděli, že release SQL Server 2008 bude o 14 dní pozdržen, jaké pak bylo mé překvapení, když včera byl proveden release :-). Na podzim se také chystají DevDays a jistě s tím i spousta novinek - co nového se dozvíme, to se dá jen odhadovat. Pokud bych měl ještě chvilku zůstat v .netím světě, tak se probralo něco málo z pracovních záležitostí okolo portálového řešení nebo jak řešit incidenty s MS.

A další témata, která určitě nemohla chybět: dopravní situace, kriminalita - příběhy a historky nejen z čech na toto téma, a také samozřejmě nemohl chybět iPhone a jeho konkurence. Kolegové se též rozpovídali o systému TETRA a TETRAPOL a došlo i na zasíťování obytného domu. Jak si můžete přečíst, témata různorodá a každý si našel své oblíbené. Na ta, na která jsem zapoměl, příště se zkusím polepšit.

Samozřejmě také padl dotaz, jak více podpořit české vývojáře a dát jim k dispozici (nejen) webové aplikace. A já snad vyzkouším Mesh.

Zhodnocení

Doufám, že všichni odcházeli spokojení a s novými informacemi a příště se opět sejdeme. Poděkovat musím i ochotnému a příjemnému personálu restaurace Bílá Vrána.

Co mě osobně mrzelo, že Jakub Blažek, Michal Augustýn, Kirkie a také Tomáš Šmíd se ani nenamáhali dát jakkoli vědět, že jim nemáme držet místo u stolu.

S ostatními se budu těšit na shledanou, a doufám, že to bude ještě tento rok.

A ještě několik fotografií, které pořídil Štěpán Bechyňský.

Ozývají se opět hlasy, které touží po dalším, v pořadí již čtvrtém neformálním setkání přispěvatelů diskuzního fóra o .netu na serveru builder.cz.

Těmto hlasům velice rád vyhovím, i já se již těším, až uvidím známé a snad i neznámé tváře, které se zúčastní.

Jak jsem se minule dozvěděl, lepší je anoncovat toto setkání přímo na blogu, tudíž tak činím. Vaši účast tak prosím potvrďte v komentářích (nezapomeňte na email), případně přímo mě na email jarda @ tato doména.

A kdy se setkání může uskutečnit? Říkám si, že by bylo pěkné, každému nadělit malý dárek, a tak vyhovím přání a vyhlašuji následující termíny.

• 4.8.2008 - pondělí
• 6.8.2008 - středa

Setkání se uskuteční nejspíše na stejném místě jako minule, kde byla velice příjemná obsluha, dobré jídlo a v neposlední řadě i společnost. Předpokládaný začátek 18:30.

Potvrzení termínu a organizační záležitosti pak sdělím v úterý 29.7. do kdy také máte možnost se přihlásit.

Budu rád, pokud uvidím i tváře ještě neznámé, určitě se nemusíte bát přijít, budete vítáni. Těším se na viděnou.

Je to jen pár měsíců, co je na světě .net framework verze 3.5 a s ním spoustu cukrátek, které potěší nejednoho vývojáře na .netím frameworku. Někteří z nás sice vzhlížejí ještě kousek dál - třeba k ADO.NET Entity Frameworku, ale pro ty, kteřím stačí současný stav a pohrávají si s LINQ to SQL, tu mám jeden tip.

Přestože jsme na builderu nedokázali odhalit přesnou příčinu nefunkčnosti nad položenou otázkou LINQ + SQL + datagridview - uložení změn do db, snažil jsem se přijít na důvody, proč u tazatele daná kombinace nebyla funkční. Přiznám se hned na začátku, že jsem na rozumné vysvětlení nepřišel.

Jak propojit data na DataGridView

Vhodnou cestou jak napojit data z datového zdroje, v tomto případě tedy entit vytvořených pomocí LINQ to SQL, na DataGridView je použít objektu BindingSource. Při nastavení vlastnosti DataSource dojde k provázání dat se zobrazovacím prvkem a v případě, že máme povoleno na DataGridView přidávání, případně mazání řádků máme vše hotovo.

Skutečně nám tedy stačí, ve vhodnou chvíli volat událost SubmitChanges nad stejnou instancí DataContextu, jakou jsme naplnily BindingSource a o vše se postará interní logika. Není tak třeba registrovat se k žádným událostem - snad až na jedinou a tou je událost pro přidání nového záznamu AddingNew, a to jen v případě, že požadujeme mít nově přidaný objekt uživatelsky nainicializovaný.

Stejně tak není třeba notifikovat DataContext, lépe řečeno Table<TEntity> kolekci o nově přidaných objektech pomocí metody InsertOnSubmit, stejně tak jako psát kód navíc, abychom zjistili odstraňovanou položku z kolekce a tu mohli předat do metody DeleteOnSubmit.

Ukázka

Jak tedy může taková jednoduchá práce s DataGridView a jeho napojením na data vypadat? Následující část kódu je skutečné minimum:

// metoda pro získání dat z datového zdroje LINQ to SQL
private IEnumerable provideData() {
 var result = from data in _db.TestRows
  select data;
 return result;
}
// metoda pro uložení editovaných dat
private void saveClick(object sender, EventArgs e) {
  _db.SubmitChanges();
}

... // tam kde potrebujeme nahrát data a napojit je na zobrazovací prvek
bindingSource.DataSource = provideData();
...

Včera v podvečer se uskutečnilo již třetí setkání přispěvatelů konference o .net technologii provozované na serveru builder.cz. Tentokrát jsme se všichni sešli v příjemném prostředí restaurace Bílá vrána, kterou doporučil jeden z účastníků Martin Vobr, díky.

Pokud bych se měl poohlédnout po průběhu setkání, tak se všichni bavili, dozvídali se nové věci a sdělovali si historky ze své každodenní práce, a nejen o práci se povídalo. Myslím, že ten, kdo přišel, udělal dobře a strávil příjemný večer se známými nicky a neokoukanými tvářemi. Počet vývojářů, kteří se přišli takto bavit se opět zvýšil a tentokrát nás bylo již deset, ano 10.

A jen tak na okraj, nebo spíše pod čáru. Ani Alt+Enter v Blendu bohužel Properties dialog nevyvolá, ach jo, a já se v tu chvíli tak zaradoval. Přinesl jsem si však i jiné rady, a také několik málo připomínek k setkání. Takže příště o něm budu informovat i tady na stránkách krátkým příspěvkem, aby se k vám dostala tato informace pomocí RSS čtečky. Jen přípomínka pro mě, nezapomenout pozvat i Jirku B.

Závěrem

Jak už jste se nejspíše dovtípili, setkání budou pokračovat, takže se s vámi budu těšit opět za nějaké čtyři měsíce.

Díky všem, kteří se zúčastnili, a příště třeba i s dalšími.

Otázky a odpovědi. Při hledání vhodného řešení si občas člověk užije a prověří svoje schopnosti. Ne vždy je odpovědí optimální řešení, ale jak nás učili na škole, lepší vybírat mezi suboptimálním řešením, než žádným. A právě jedna taková otázka se objevila na builderu, týkala se maximální šířky sloupečku v DataGridView. Jelikož jsem se při odpovědi maličko více rozepsal, rozhodl jsem se odpověď uveřejnit jako příspěvek.

Možné řešení maximální šířky sloupce je celkem prosté a vycházím z toho, že DataGridView publikuje několik událostí při změně šířky sloupečku. Zároveň je však důležité přidat do definice sloupce informaci, zda má sloupec povolenu max. šířku a případně její hodnotu.

SizingDataGridViewTextBoxColumn

Nejdříve jsem si tedy vytvořil potomka po DataGridViewTextBoxColumn a přidal jsem mu vlastnost MaximumWidth, která uchovává hodnotu o maximální šířce sloupečku. Dále bylo nutné přepsat metodu GetPreferredWidth, tak aby tato vracela požadovanou šířku v daných případech.

SizingDataGridView

Dále jsem podědil třídu DataGridView, kde bylo nutné přepsat dvě metody, ke kterým dochází v průběhu změny šířky sloupce. Jedná se o metody OnColumnDividerDoubleClick a OnColumnWidthChanged.

Proto, abych si ulehčil maličko práci a výsledný kód splňoval alespoň nějaké podmínky pro rozšíření jsem dodefinoval ještě interface, který implementují všechny sloupečky, které mají mít nastavenu maximální šířku. Nazval jsem jej ISizingDataGridViewColumn. Na toto rozhraní se odvolávám právě u obou přepsaných metod.

Zdrojové kódy

Ještě zbývá uvést zdrojové kódy jednotlivých, zde zmíněných tříd a interface. Jelikož se jedná o poměrně malé části kódu, uvádím je v plném znění bez komentářů.

ISizingDataGridViewColumn:

public interface ISizingDataGridViewColumn
{
  int MaximumWidth { get; set; }
}

SizingDataGridViewTextBoxColumn:

public class SizingDataGridViewTextBoxColumn : DataGridViewTextBoxColumn, ISizingDataGridViewColumn
{
  private int _maximumWidth;
             
  public int MaximumWidth
  {
    get { return _maximumWidth; }
    set
    {
      if (_maximumWidth != value)
      {
        _maximumWidth = value;
      }
    }
  }

  public override int GetPreferredWidth(DataGridViewAutoSizeColumnMode autoSizeColumnMode, bool fixedHeight)
  {
    int width = base.GetPreferredWidth(autoSizeColumnMode, fixedHeight);
    int currWidth = this.Width;
    if (MaximumWidth < width)
    {
      width = MaximumWidth;
    }
    if (currWidth > width)
    {
      return width;
    }
    return currWidth;
  }
}

SizingDataGridView

public class SizingDataGridView : DataGridView
{
  protected override void OnColumnDividerDoubleClick(DataGridViewColumnDividerDoubleClickEventArgs e)
  {
    if (this.Columns[e.ColumnIndex] is ISizingDataGridViewColumn)
    {
      this.Columns[e.ColumnIndex].Width = ((ISizingDataGridViewColumn)this.Columns[e.ColumnIndex]).MaximumWidth;
    }
    base.OnColumnDividerDoubleClick(e);
  }

  protected override void OnColumnWidthChanged(DataGridViewColumnEventArgs e)
  {
    base.OnColumnWidthChanged(e);
    if (e.Column is ISizingDataGridViewColumn)
    {
      this.AutoResizeColumns();
    }
  }
}

A to je vše. Jak jsem se již zmínil na začátku, určitě se nemusí jednat o řešení optimální, spíše se jedná o nástin možného řešení, které je třeba rozvést a otestovat pro všechny stavy, které mohou u DataGridView nastat.

Ač to může být pro zkušené vývojáře obehraná písnička, ještě stále se najde spousta nováčků, nebo i pokročilejších vývojářů, kteří mají problém s určením, kdy se jejich komponenta, nebo formulář nachází ve vývojovém prostředí designeru.

Malé odbočení na začátek

Dřív než začnu popisovat způsob, jak identifikovat, že se formulář nebo obecnějí komponenta nachází ve vývojovém prostředí v režimu designeru, dovolím si malou odbočku, jak a proč tento příspěvek vlastně vznikl.

Takovouto otázkou se zabýval jeden z přispěvatelů na .net fóru builder.cz - jak jistě víte, mém oblíbeném. V mé odpovědi jsem jej nasměroval na možné řešení. To se však nezdálo býti dostačující a tak se na mě obrátil i soukromě, zda bych mu neposkytl potřebný kód. Nebyl prvním, kdo takto učinil a nejednalo se ani o ojedinělý případ.

Co jsem si však v tu chvíli uvědomil, že za tyto poměrně kvalitní konzultace, bych mohl být odměněn. ;-) Když jsem mu toto navrhl, již nereagoval. Je to myslím škoda, a určitě se nebudu podobným konzultacím bránit, pokud budete mít konkrétní problém.

Jelikož k rozumné dohodě nedošlo a přispěvatel nejspíše problém vyřešil vlastními prostředky, zkusím se podělit o řešení aspoň touto cestou. Můžete to vzít, třeba jako referenci.

Zpátky k DesignMode

Jak jsem již v odpovědi na otázku uvedl, existuje několik možností zjištění, že je komponenta otevřena v designeru Visual Studia.

Testování DesignMode

První možností je testovat vlastnost DesignMode dané komponenty. To je funkční řešení do doby, než umístíme komponentu do nadřazeného kontejneru a pokusíme se tuto vlastnost otestovat. Vrátí nám hodnotu false. Což je nahlášeno jako bug. Samozřejmě jemožné projít všechny nadřezené komponenty a nakonec se správné hodnoty dobrat.

Testování Site

Další možností je také otestovat vlastnost Site, která vrací rozhraní ISite jenž je naplněna právě designerem (zjednodušeně řečeno).

Testování přítomnosti EntryAssembly

Třetí možností v řadě a nikoliv poslední je otestování toho, zda existuje vstupní Assembly. Vychází se z předpokladu, že designer spouští kód pro formulář nebo komponentu "po svém" a tak nedochází k nahrání vstupní assembly.

Zjištění přítomnosti služby IDesignerHost

Určitě ne poslední možností je zjištění přítomnosti konkrétní implementace rozhraní IDesignerHost, jenž zajišťuje služby designeru.

Pro lepší představivost uvedu kód, který určitě vydá za tisíce slov. Kód uvnitř podmínky se provede pouze v případě, že jsme v designeru:

if (Site != null) {
    System.Diagnostics.Debug.WriteLine("site");
}
if (Assembly.GetEntryAssembly() == null) {
    System.Diagnostics.Debug.WriteLine("entry assembly");
}
if (GetService(typeof(IDesignerHost)) != null) {
    System.Diagnostics.Debug.WriteLine("designer host service");
}

Snad to některým pomůže.