Náhodné výkřiky 12 - nejen o FireMonkey

vložil Radek Červinka 26. srpna 2011 22:30

Dneska útržky o FireMonkey, komponentách, Delphi, Anti-Grain Geometry, BDE, Outlooku, DataSnap Mobile, RAD Studio World tour a další efektové.

Z toho co mne zaujalo uvedu útržky. Např. Components4developers.com:

A really simple but very cool thing in FireMonkey is that any control can act 
as a container for other controls. And you can utilize that feature in styling.
So lets say you have lots of TLabels on your form, but you would like those 
labels to be prefixed with a little glyph. In "old days" in the VCL, you 
would have to either find a different control, or manually put small TImage
or similar components in front of the TLabel. 
…
The momentum of .Net have declined and Microsofts focus have been obscured 
by HTML5 to such a degree that many hardcore Silverlight users 
are in serious doubt about if Silverlight will survive.

Mat DeLong má úvod do DataSnap Mobile Connectors, asi přímo jeden z vývojářů.

Danny Thorpe kdysi napsal článek jak Delphi ke svému jménu přišlo, asi to znáte, ale pěkná story - doporučuji přečíst, v našem jazyku to moc nevynikne: Jedním z cílů bylo propojení s Oracle (kromě DB i anglicky věštec) a kde se mluví s věštci?

Oracle

V Delfách, neboli The Oracle at Delphi. If you want to talk to (the) Oracle, go to Delphi.

Znáte Outlook Redemption? Knihovna pro spolupráci s Outlookem, která obchází Outlook Security Patch a umožňuje přístup k dalším věcem v Outlooku.

Pokud stále používáte BDE, zde je instalace BDE pro 64bit Windows.

Lars Fosdal napsal základní porovnání FireMonkey a VCL.

Sprostě ho vykradu:

VCL kód v XE2 (jde to i bez Vcl.):

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, 
  System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;
 
type
  TFormVCL = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    Label1: TLabel;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
var
  FormVCL: TFormVCL;
 
implementation
 
{$R *.dfm}
 
procedure TFormVCL.Button1Click(Sender: TObject);
begin
  Memo1.Lines.Add(Edit1.Text);
  Label1.Caption := IntToStr(Memo1.Lines.Count);
end;

FireMonkey kód:

 
uses
  System.SysUtils, System.Types, System.UITypes, System.Classes,
  System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs, 
  FMX.Edit, FMX.Layouts, FMX.Memo;
 
type
  TFormFM = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    Label1: TLabel;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
var
  FormFM: TFormFM;
 
implementation
 
{$R *.fmx}
 
procedure TFormFM.Button1Click(Sender: TObject);
begin
  Memo1.Lines.Add(Edit1.Text);
  Label1.Text := IntToStr(Memo1.Lines.Count);
end;

Všimněte si, že Label má Text a ne Caption. Osobně to moc nechápu, asi aby .NET developerům nebylo smutno, až budou houfně přecházet.

Dají se míchat formuláře, ale není to doporučováno. A když tak spíše ve VCL aplikaci zobrazit FMX formulář, on pravděpodobně i FMX designer v Delphi IDE je FMX formulář, ale to hádám.

Pokud hledáte Object Pascal parser pro svoje projekty, zkuste Castalia Delphi Parser, používá ho Castalia, takže je celkem aktuální.

Nebo možná potřebujete Delphi gramatiku - můžete zkusit neoficiální Delphi gramatiku.

Když už jsme u těch komponent - Object Pascal native port of the Anti-Grain Geometry library - AGG. Vůbec nevím na co bych to použil, ale udělalo to na mne dojem.

Nezapomeňte, že letošní RAD Studio World tour už běží a ohlasy jsou moc dobré. U nás bude v Praze a Bratislavě, 13. a 14. září. Přednášet bude Paweł Głowacki a Stephen Ball.

RAD Studio World tour

Já osobně pojedu letos do Bratislavy. Chtěl jsem původně do Prahy s tím, že pokud tam bude někdo z lidí, které znám jen přes mail a delphi.cz, tak bych se seznámil (ze Slovenska lidé moc nepíší) - ale teoretická možnost vyzpovídat Pawła vyhrála. Je to velmi technicky vybavený člověk (a navíc mu anglicky i rozumím když přednáší, ale loni to bylo překládáno), tak z něho třeba něco vytáhnu. Myslím, že to letos bude stát za to, ale neváhejte - počet míst je omezen.

Google mi srazil PageRank. To vážně na mne odkazuje tak málo lidí? Stačí textový link na delphi.cz.

Tagy: , , ,

Komponenty | Novinky

Komentáře

27.8.2011 2:27:58 #

Mirda

"...asi aby .NET developerům nebylo smutno, až budou houfně přecházet." - haha :)

Mirda

27.8.2011 2:31:10 #

Mirda

Bohužel, zatím sleduji odklon korporátní i veřejné sférý od řešení založeného na Delphi. V rámci udržení konkurence přeji, aby se to změnilo.

Mirda

27.8.2011 3:57:27 #

Radekc

Povíme si za nějakou dobu. FireMonkey je taková bomba, že to nemá v současném IT světě konkurenci. Zvláště multiplatformnost z hlediska mobilních zařízení a vůbec architektura. A to není zdaleka jen můj názor.

Navíc počet uživatelů Delphi prokazatelně roste.

Radekc

27.8.2011 15:20:28 #

Radekc

Ještě jsem o tom přemýšlel, a tak v dobách D2006 bych ti i bohužel dal za pravdu. Ale nyní ne. Jak jinak chceš vykládat to, že prodeje Delphi poslední 3 roky rostou dvou ciferně? To se podle mne s odklonem vůbec neslučuje.

Radekc

27.8.2011 21:09:07 #

Mirda

Aby jsme se špatně nepochopili, já Delphi přeji, aby rostly a znovu se rozšiřovaly. Když ale sleduji požadavky na trhu práce, tak poptávka po Delphi programátorech není nic moc (aspoň teda u nás). To samé platí o výuce Delphi na technických univerzitách v ČR, preferuje se hlavně Java nebo C#. Myslím, že do vývoje pod .NET firmy hodně investují a nebo investovaly. Proto si myslím, že to budou mít Delphi těžké, ale neříkám, že jim to nepřeju.

Mirda

29.8.2011 10:31:34 #

Martin

Moje zkušenost odpovídá tomu, co píše Mirda. My jsme se od Delphi začli odklánět krátce po roce 2000, když jsme začínali dělat pro web. Dnes dělá většina našich vývojářů v .NETu a nic jiného ani neumí. Máme ještě jedno řešení postavené nad Delphi, ale to asi do nových verzí nebudeme mít sílu přenést kvůli problémům s  Unicode stringy. To už bychom to spíš převedli do .NETu. Takže návrat k Delphi by už byl pro nás hodně těžký.  

Martin

29.8.2011 10:45:48 #

Radekc

>Máme ještě jedno řešení postavené nad Delphi, ale to asi do nových verzí nebudeme mít sílu přenést kvůli problémům s Unicode stringy. To už bychom to spíš převedli do .NETu.

Misto cca 1-3 denní práce s unicode konverzí (vlastní zkušenost cca 400KLOC), přepíšete celý program do .NETu (člověko měsíce až roky).

Zajímavé, že o problémech s unicode vždy píšou lidi co to ještě nemají. Naopak z druhé strany je většinový názor ve smyslu, že to nebyl zas až takový problém. Samozřejmě pokud to nemáte psané v ASM.

Radekc

29.8.2011 12:16:35 #

Martin

Menší aplikaci jsem do unicode převáděl (D2010) a celkem jsem si s tím užil. Byla původně vytvořená v Delphi5 a obsahovala spoustu kódu a komponent pro zpracování dat v různých vstupních formátech (TXT, DBF, XML). Prakticky od žádné komponenty se mi nepovedlo najít verzi pro D2010, takže jsem buďto sháněl alternativy a upravoval aplikaci nebo nebo přepisoval zdrojáky komponent. 1-3 dny to rozhodně nebyly, hrubým odhadem spíš 3 týdny.

Martin

29.8.2011 13:08:40 #

Radekc

OK, v takovém případě (souborové formáty, mnoho cizích komponent, navíc u Delphi 5 přidávání jednotky Variants) uznávám, že to mohlo trvat déle.

Radekc

30.8.2011 9:54:20 #

JaroB

Já osobně jsem začal s tím, že jsem už někdy v roce 2004 naportoval většinu mých programů, které byly napsané pouze v Delphi (verzí 3, 5) bez komponent třetích stran do .NET verze Delphi 2005. V podstatě jsem pak neměl moc potíží při převodu do unicode Delphi 2010/XE (Delphi 2009 jsem tak nějak přeskočil). Pak jsem ale potřeboval přenést projekty, které obsahovaly komponenty třetích stran – speciálně databázi TinyDB a knihovny RXLibrary s VG2Library (souběžně s tím jsem portoval i knihovny jako RALib, AGLib, PolarisLib - z nichž jsem nakonec vysekal jen unikátní komponenty a ostatní zahodil - nebo některé frameworky pro Plugins či PDF). Pikantní bylo, že například podpora pro QuickReport nebyla v unicode úplně dobře udělaná (a dodneška mi to hlásí v expressions hnusná varování). Oproti tomu bylo portování frameworku DelphiX jednodušší, struktury DirectX mají minimum stringů (ale zase mají jiné hnusnosti jako třeba obskurní volání procedur). Každopádně nemohu říct, že portace třeba RxLibrary je sto-pro, poněvadž se vždycky něco vyvalí (kritická místa vidím v datasetech nebo zakuklených voláních shellu). Sice jsem vydal už třetí opravu, ale kdo ví, na co se ještě narazí.
Každopádně nemůžu souhlasit, že lze konvertovat do unicode za 1-3 dny. To prostě není možné u knihoven třetích stran, které jsou používány jako černá skříňka, nebo mají speciální režii na vlastní datovou správu. Už jenom pochopení mnohdy nepochopitelných algoritmů ("sakra, jak to ten autor myslel?" nebo "proboha co tím vlastně chtěl dokázat?" nebo prosté "k čemu to vůbec je?") prodlužuje dobu vlastní konverze (pokud není mechanická, typu jako PChar <> PAnsiChar atp.). Taky z vlastní zkušenosti mohu říct, že vyrazit takovouhle knihovnu z pár projektů je práce na měsíce (dobře vím, o čem mluvím, takhle jsem se zbavoval LMD Tools – více jak 60-ti různých komponent rozlezlých po projektech). Dokonce ani použití JVCL není vítězství, jejich použití není bez závazků, ale spíše se podobá ve vazbě bázových objektů knihovnám od TurboPower např. knihovně Orpheus (vazba všech komponentů na bázový objekt + křížová vazba na jejich resource manažer, což je snad ještě větší hrob). Tím nechci říct, že JVCL je špatná, to ne, ale je lepší nad ní založit nový projekt než se pokoušet vyrazit RXLibrary a nahradit to analogickými komponenty z JVCL.
A rád bych poznamenal, že v komerčních projektech je pro klienta neúnosné, pokud mu při práci aplikace spadne na nesmyslnou chybu v knihovně, která třeba jen zjišťuje systémovou informaci o počítači (protože byla opomenuta nějaká „prostorová maličkost“ při alokaci unicodestringu), pak je jen na toleranci uživatele, má-li alternativu k mému programu, či nikoliv a ve svém důsledku to může mít dopad i na obchodní aktivity třetích stran. Proto bych byl v jistých soudech opatrný.

JaroB

30.8.2011 10:11:07 #

Radekc

Jo, ono je to totiž o těch komponentách. Já použím VirtualTree, JCL, JVCL, FastReport, SynEdit a to je tam ze třetích stran vše. Pak sem tam i jiné, ale mimimálně.
Všechny komponenty co jsem potřeboval už převedl někdo jiný a těch pár dalších nebyl zas takový problém, takže u mne to fakt bylo rychle.

Každopádně díky za info.

Radekc

30.8.2011 10:16:50 #

JaroB

nzc. :)
vždycky je to o komponentech třetích stran a jejich životním cyklu.
ani nedokážu spočítat, kolik že to vlastně komponent v aplikacích používám :(

JaroB

Komentování ukončeno

Naše nabídka

MVP
Ing. Radek Červinka - Embarcadero MVP
profil na linkedin, Twitter:@delphicz

Nabízím placené poradenství a konzultace v oblasti programování a vývoje SW.
Dále nabízíme i vývoj speciálního software na zakázku.

Neváhejte nás kontaktovat (i ohledně reklamy).

love Delphi

O Delphi.cz

Delphi je moderní RAD nástroj podporující tvorbu nativních aplikací pro platformu Win32, Win64, Mac OSX, Linux a na iPhone a Android.

Delphi.cz je nezávislý portál pro uživatele Delphi. Portál není koncipován pro úplné začátečníky, i když i ti se zde nebudou nudit, ale spíše na programátory, kteří již něco znají a chtějí své znalosti dále rozvíjet a sledovat novinky.

Poslední komentáře

Comment RSS

Dle měsíců