RAD Studio Berlin 10.1 Update 2 Anniversary Edition

21.11.2016 11:37:53 #

"Ale opět se ukazuje, že EMBT začalo výrazněji zase podporovat VCL" a autor FMX(vgscene) odchádza. Divné súvislosti.  http://www.kryukov.org/looking-for-job/

Aj https://www.fmxexpress.com/ len 2 prispevky v novembri.

PS

21.11.2016 14:40:14 #

...aby to neskončilo jako z Kylixem ...komunita kolem Delphi je tak věkově stará (noví nepřibývají, protože si to cenově nemohou dovolit a Visual Studio, co dnes umí defakto to samé, je zadarmo), že prostě nejsou zvědaví na nějaké "novoty" ...sedí si na těch svých místečkách ve firmách co mají z historických důvodů Delphi a tam se nic do FMX přepisovat nebude (a kdo dnes bude začínat projekt v Delphi)
B.

bullhead

21.11.2016 15:50:48 #

defakto = sáňky a Camaro umí defakto to samé, ale radši bych jel v Camaru (a ne na sáňkách s báglem .NET šrotu pod zadkem)... A VS C++ s MFC nelze asi zcela srovnávat s Delphi/C++Builder co do produktivity práce.

MartyK

21.11.2016 17:06:03 #

@radekc
....asi mi něco ušlo:
"Co kdyby se někdy napsal komentář i na pozitivní zprávu?"
...zcela vážně, co tím myslíš, jaká pozitivní zpráva? Jestli myslíš Update 2, tak tobychom se asi pohádali (a to bych byl opravdu nerad:-)). Já jsem příznivec delphi, ale tento update já za nic pozitivního nepovažuji, osobně ty změny nejsou na tak velký update. Opravdu celá komunita čeká na novou komponentu kalendáře? A ještě VCL? Opravdu bude hodně lidí používat QuickEdit? Když jsem viděl úvodní předváděčky a polovina se točila kolem JEDNE nové komponnety (a ještě VCL) tak jsem se musel smát. :-(.

@MartyK
...ale "a ne na sáňkách s báglem .NET šrotu pod zadkem" - zaprvé existuje .NET native a za druhé normálním developrům to evidentně nějak moc nevadí ..."A VS C++ s MFC nelze asi zcela srovnávat s Delphi/C++Builder co do produktivity práce" ...naprostý souhlas ...ALE aplikace co se píší v Delphi se nepíši (v naprosté většině) v C++ ale v C# ...a naopak drivery a nízkoúrovňové aplikace se nepíší v Delphi

bullhead

21.11.2016 17:47:40 #

@bullhead
Já píšu v C++ kromě jiného i takové aplikace, co se píší v Delphi a nevidím důvod v tom nepokračovat, žádný zákon to (naštěstí) neurčuje, co se v čem smí nebo může psát.

Na Upd2 mám stejný názor jako ty a když si vzpomenu a prohlášení M. Cantú o zvláštní pozornosti , kterou budou věnovat kvalitě a ohromném množství bug fixů, které se na uživatele vyvalí při dalších vydáních, tak se mi zdá, že seznam oprav při tomto vydání byl dosti hubený, nakonec stáhli i již ohlášený refactoring pro C++ (bez něj se dá samozřejmě v pohodě žít stejně jako do teď :-).

MartyK

22.11.2016 10:25:32 #

No, pánové, když čtu ty komentáře, tak opravdu Radka Červinku obdivuji, že ještě tyto stránky provozuje, já už bych seděl v Kateřinkách nebo v horším případě na Borech :-)

Takže takhle - znovu to sem napíši, abych Delphi podpořil. Myslíte si, že firma Alza je nějaký zastaralý dinosaurus ? Proč hledá ty nejlepší programátory ? Proč vyvíjí svůj stěžejní informační systém v Delphi ? Otevřete oči. Podívejte se do světa. Rozsáhlé ERP systémy, medicínský software, řídící systémy a další a další jsou programovány s využitím nástrojů od Embarcadera. Helios, Abra, Alza a další u nás, to jsou sakra nějaké neschopné firmy ? Jejich ERP tady využívá nejvíce zákazníků. V čem myslíte, že programují ? V Delphi ! Když jdete k doktorovi, většina z nich má Medicus. V čem se programuje ? V Delphi ! Další si snadno zjistíte.

A milý uživateli bullhead, urazil jsi mě - neznám moc věkově starých programátorů Delphi, kteří by si seděli na teplých místečkách. Naopak jsou to dost kvalitní a progresivní lidé a programování opravdu rozumějí. A hlavně tvrdě dřou. A že nejsou zvědavý na "novoty" ? Co to je za pitomost ? Kolik jich znáš, že se takto vyjadřuješ ? Což takhle si třeba udělat exkurzi do Alzy ?

Marek

22.11.2016 11:42:55 #

Souhlasím, veďme konstruktivní diskuzi, ale prostě musel jsem reagovat na toto:

komunita kolem Delphi je tak věkově stará ... noví nepřibývají ... nejsou zvědaví na nějaké "novoty" ... sedí si na těch svých místečkách ve firmách co mají z historických důvodů Delphi ...

To prostě není pravda. A nemůžeme zavírat oči nad tím, jak se teď Idera opravdu snaží. Nic není ideální - a také nikdy nebude. Ale prostě ta snaha je velká a jsem přesvědčený, že to jde správným směrem.

A trochu by také stálo zato ocenit Radka, že tento server provozuje a snaží se na kritiku odpovídat.

Jenom nápad - pro ty, co se současnou situací kolem Delphi (nebo celého RAD Studia) nejsou spokojený. Což takhle napsat konstruktivní kritický článek o Delphi, o RAD Studiu, kde budou opravdu pravdivé a ověřené informace ? Myslím si, že Radek by ho zveřejnil.

Marek

22.11.2016 15:56:14 #

@Marek
Nic ve zlým, ale oslavné články nic neřeší. Clang kompilátory + debugger v C++Builderu je nekonečný příběh zřejmě až do druhého funkčního období Trumpa (pokud tedy k němu dojde).
Já končím diskuzi, nebudu narušovat idylku Delphi - tam je asi většina věcí v pořádku, nemůžu to posoudit...
Ještě 1x omluva za názor.  

MartyK

22.11.2016 19:07:50 #

@Marek
:-) ...nic z toho co jste napsal nerozporuje mou větu ...co mají z historických důvodů Delphi ...plácání po zádech opravdu nic nevyřeší ...a pokud si např. člověk musí dokupovat podporu DB v nižších edicích, přičemž DB jsou základem většiny applikací, a dokonce ani v EDICI STARTER (která by mohla nalákat mladé ať se učí v Delphi) NEJSOU DB KOMPONENTY(!), trvám na tom, že Embarcaderu ujíždí vlak.

tím za mne v tomto vlákně končím howgh
B.
p.s. ...že jsem rád, že Radek provozuje tento server, jsem snad dal dost najevo tím, že jsem napsal, že se sním nechci pohádat a také tím, že zde chodím:-) ...a možná pohled zvenku (v mém případě bývalého Delphi developra) by některým prospěl

bullhead

22.11.2016 23:17:07 #

No, ono vždycky bylo nějaké období Borland-Codegear-Embarcadero... kdy se kapku pozměnily objekty a funkce hluboko v subsystému (jasně, vše podřizovali .net, pak 64bit, pak android super-multi-kulti-platformovosti atp.) a sem tam něco vypadlo, namátkou stále doupravované datasety v XE3 (tam do toho sáhli), ale pořád se to dalo nějak dohnat, obejít, nahradit. Každopádně nějaký pokrok mezi verzemi je v posledních pár verzích zpět menší a menší, řeší se spíš mobilní vývoj a tlačí se opička (tam je pokrok možná největší). Dvě komponenty pro VCL jsou jako dvě vlaštovky, jaro to neudělá.

Očekával bych, že třeba modernizují together a refactoring, vylepší uml a třeba i linker, přidají nějakou nativnější analýzu kódu, poučí se třeba u CnWizards, a především odstraní drobné chronické chyby ve VCL, které tam jsou léta. Mám pořád dvě historické aplikace v .NET, kvůli nimž udržuji Delphi 2007, které umí přeložit exe pro .NET 2.0 (ale mám i verzi pro Win32), a když jsem se pokoušel převést jeden projekt do Prizm, narážel jsem na významné změny v pascalu, protože je jen "Delphi like". To jsou drobnosti, které ale dokážou zbytečně na*rat.

O třetí strany bych se zas tak moc nebál, jsou mnohdy lépěji informované než my, prostí nekorporátní uživatelé :-)

Radek je pln pozitivní víry, což je sqělé, prože bez víry v lepší budoucnost se nedá udržet ani tenhle web. Já zase věřím (ale jen lehce skepticky), že embt jednou přihodí nějaké další kompilátory k jednomu vylepšenému IDE - do verze professional ;-) a jenom za jedny peníze ;-)

JaroB.

23.11.2016 11:34:21 #

Alzou uz bych se moc nechlubil. Od noveho roku chystaji prepis sveho IS a v Delphi uz nebude.

Petr

23.11.2016 12:27:11 #

Ano, je to pekny kus SW. O prepisu jsem neco zaslechl ve videu na mladem podnikateli a prislo mi, ze Delphi to uz nebude. Alespon podle kontextu.

Nemam nic proti Delphi, stale ve verzi XE obcas programuju. Zkusil jsem si nainstalovat verzi Starter Delphi Berlin a je tam videt skok vpred. Hlavne se mi libil editor kodu, doplnili tam nejake vlastnosti, ktere ma treba Lazarus, ale v XE nejsou.

Co mi vadi velice je cena. Obcas potrebuju neco naprogramovat jen tak pro zabavu nebo za par korun, ale kdybych na to mel pouzit Delphi Professional (kvuli DB), vydelaval bych na licenci dva roky :). A to nepotrebuji mobilni vyvoj i kdyz bych rad neco take zkusil napsat v Delphi. Pro mobil zatim bojuju s Javou a Android studiem. Na hrani si DelphiPro+mobilni balicek fakt koupit nemohu.

Dale mi vadi, ze se nevenuji VCL. Minimalne takovy DBGrid by si zaslouzil vylepsit. Ano, vim ze existuje hromada externich komponent, ale radeji se snazim vyuzivat ty nativni.

Pomohla by nejaka edice, kde by slo vyvijet vse ale s podminkou, ze vytvor musi byt OpenSource a   v About dialogu byt info o Delphi.  To by mohlo pritahnout vyvojare a potencialni zakazniky. Z meho pohledu, v korporatni sfere se nepohybuji.

Petr

24.11.2016 3:54:29 #

Normální člověk by už asi 20 let uvítal větší podporu multithreadingu skrz nativní objekty a komponenty Delphi bez potřeby roubovat cizí OmniThreadLibrary nebo nejlépe si dělat lepší vlastní a roky studovat různá šílená API pro podporu free-apartment-booth-threaded a servisních aplikací včetně vizuálních komponent v různých vláknech, ani nemluvě o databázích.  Tím reaguji na zmínku, že ŘS jsou programovány v Delphi - ano, v ČR jsou - ale za cenu nejméně 10x větší programátorské práce (asi 1/10 produktivita) + většina ŘS ani raději multithreading a různé mechanismy zamykání raději nakonec nevyužije - aplikace jsou pak časově a událostně neresponsivní - vznikají různé non-realtime bastly (o samotných WIN nemluvě) - s ohledem na efektivitu a produktivitu versus  trh/žebrácká hůl.  Každopádně náklady na vývoj ŘS v Delphi představují částku od 20M Kč + nad 5 let 16h každodenního vývoje týmu několika lidí.   Takže podporou Delphi pro vývoj ŘS - bych se zrovna moc nechlubil.  Lze to - pro pseoudo-realtime-bastly - ale dře to.  Na druhou stranu chápu, kdyby se kód Delphi měl už od počátku napsat s podporou multithreadingu - tým Delphi vývojářů by musel mít IQ od 160+ ...

Tomts

24.11.2016 4:29:44 #

A samozřejmě z pohledu vývoje ŘS - kromě do oblasti průmyslu - tak ŘS pro domácí automatizaci = dnes pro miliardovou masovku do moderních IQ a nízkoenergetických domů = "do každé domácnosti hlavně za pár šupů" by mnoho programátorů už dávno uvítalo Delphi překlad pro Linux ARM (hlavně pro R.Pi a jeho klony) právě s větší podporou multithreadingu (nebo aspoň OmniThreadLibrary - ta je zatím pouze pro WIN a pouze pro Delphi - není pro FreePascal/Lazarus  - natož pro Linux desktop target),  protože Delphi Android ARM vývoj není pro oblast SoHo ŘS krabiček nijak využitelný (absolutní nespolehlivost).   Linux pro Intel server bude sice +1 malý krůček kupředu ... ale pro miliardovou masovku by to chtělo Linux pro ARM včetně hlavně podpory Linux DESKTOPU - což MS + jeho VS díky jeho dohodám s Intelem jen tak nenabídne a R.Pi pod WIN zjevně navždy pojede bez desktopu jen jako IoT "jednoúčelovka" (ala DOS).  Delphi tedy už asi 3 roky bůhvíproč zcela ignoruje potřeby tisíců vývojářů ŘS pro oblast domácí automatizace  - přitom Lazarus dtto dávno umí (ovšem bez většího počtu komponent, knihoven, multithreadingu atd...).  

Tomts

24.11.2016 11:51:31 #

Tomts:  https://github.com/BeRo1985/pasmp (mutlithreading delphi/fpc).

No problém bol/je v tom, že EMBT veľmi tlačilo FMX na desktop čo je podľa mňa úplne mimo (ale inú možnosť ako dostať Delphi na MacOS nemali). Ja som si teraz kúpil Delphi len na Android/iOS a to len kvôli iOS. Inak hlavný vývoj je v Lazaruse.

Úplne super je, že vzniká(existuje) väčšina zaujímavých komponent (knižníc) pre FPC/Delphi takže budúcnosť je ružová.

PS

25.11.2016 15:33:40 #

Ad Alza: Na jejich náborových stránkách se o Delphi nikde už nezmiňují. Za to C# a s ním spojené technologie tam jsou.

Jan Brandt

26.11.2016 19:16:48 #

PS:  No právě, že si pár lidí složitě (s vyplazeným jazykem po mnohaletém studiu a pochopení vláken a objektů synchronizace + miliónu vlastních pokusů) dodělá aspoň nějaké základní nevizuální struktury pro multithreading (co kdo sám životně nejnutněji potřebuje) a locking ... ale zbytek objektů a komponent se musí složitě "doroubovat" bez podpory více vláken ... např. posíláním zpráv mezi vlákny, zamykáním dat globální kritickou sekcí (znehodnocení) ... a okna (handle + systém okenních zpráv) musí být vytvořena v jiném vlákně než mainthreadu a dojde s k jednoduše neřešitelným věcem ... než kdyby tvůrci Delphi, FPC, Lazarusu atd. už od počátku na tom nechali 10x více vlastního sádla (než nažraní a spokojení vstanou od stolu a vystřídá je další nadržená mladá parta vývojářů) ... a navrhli vše od počátku s podporou více vláken ... a totéž by museli dělat i tvůrci 3-party komponent.  Ale pravděpodobně by dodnes nebyla na trhu ani Delphi v.1 ...

Tomts

28.11.2016 20:07:42 #

U nás v Alze jede opravdu vývoj celého informačního systému v Delphi (+ v MSSQL, kde je business logika v podobě uložených procedur, ...) a rozhodně nemálo dalších let pojede. I kvůli tomu jsme si Radka k nám pozvali a chtěli se nachytřit s nějakými fintami + některé už jsme i zapracovali (Díky Radku! ;D).

Je pravda, že i něco málo už teď máme v IS v .NETu (např. SW v chytrých čtečkách čárových kódů, které používá logistika), ale proti ostatním aplikacím to jsou drobečky.

Kolega Vláďa Dědek v rozhovoru pro mladypodnikatel.cz zmiňoval přepis IS, kde půjde primárně o rozmělnění architektury (teď jde zjednodušeně jen o klasický klient-server) a některé části (primárně v BL) se opravdu budou přepisovat do C#, aby byly blíže webovému systému, který máme z většiny také v C#. Drtivá většina aplikací IS ale zůstane opravdu nemálo dalších let v Delphi.

Co se náborů týče, tak už několik let nezmiňujeme (v pozicích do IS) žádný konkrétní programovací jazyk (tedy ani Delphi/Object Pascal). Ano, je to i kvůli aktuální neatraktivnosti Delphi mezi většinou vývjářů, což nás mrzí :( Zkoušíme kandidáty z obecných programátorských znalostí - OOP, algoritmizace, znalosti DB a obecného SQL. Ti, co se dostanou až do finálního kola pohovorů, tak mají možnost se podívat pod kapotu našeho vývoje (ukazovali jsme i Radkovi :)) a tady nám zatím nikdo neutekl na tom, že by mu vadilo, že to máme v Delphi. Reálně už cca polovina týmu k nám nastoupila bez jakékoli znalosti Delphi a Object Pascalu.

Sezóna nám běží naplno a tak se nám díky jiným prioritám ještě nepodařilo dotáhnout ten zmiňovaný článek o našem vývoji :(, kde bude vše ještě detailněji popsané. Slibuju, že brzo doplníme... ;)

Jiří Schejbal

29.11.2016 9:00:41 #

Díky moc panu Schejbalovi za super interní informace z Alzy.

Jenom malá poznámka pro ty, co tady neustále šíří "zaručené" zprávy. Ověřujte, ověřujte, ověřujte. Programátor je tvor inteligentní a myslím, že ten dobrý to zvládne.

Pevně věřím, že na tomto webu bude v budoucnu daleko více článků, zpráv a diskuzí od lidí ze současné skutečné Delphi a C++ praxe, že ubyde komentářů, které šíří nepravdivé informace, jsou zatrpklé, negativní, kritické bez návrhů konstruktivního řešení. Kritizovat ano, ale ne po vzoru příznivců různých politiků šít do druhého bezhlavě a naprosto mimo realitu.

Takže ještě jednou díky panu Schejbalovi za pro mě (a určitě nejenom pro mě) velice přínosné informace z Alzy, kterou považuji opravdu za výbornou firmu se skvělým vývojovým týmem. Hodně zdaru !

Marek Weyda

29.11.2016 9:33:27 #

Též děkuji panu Schejbalovi za velmi pozitivní informace.
Z mého předchozího komentáře nejspíš vyplynulo, že Delphi nefandím, ale opak je pravdou. K Delphi jsem přišel tak trochu náhodou před pár lety a mile mě překvapilo nakolik se od verze 7, ve které jsem dělal na střední škole, posunuly vpřed. Vždycky mi je líto, když se někdo odkloní po dlouhých letech od Delphi (aktuální osobní zkušenost).

Jan Brandt

6.12.2016 9:41:38 #

Embt v minulosti udělalo/převzalo pár chyb v Delphi či VCL, které nikdy neopravili, resp. opravili až následující verzí (typická je chyba v menu styles v XE6 s opravou v XE7), ale už nikdy opravu nesnížili na verzi zpět (na XE6), ve které vznikla. Letitou chybu ve Vcl.Grids neopravili nikdy. Je otázka, jak donutit dodavatele – a pohybuji, že naše zákony v tomto něco zmohou – aby opravil svoje chyby (obvykle drobné ale obtěžující chyby v kódu, např. VCL) ve svém poměrně drahém produktu. Pokud opravují tak, že vydají novou verzi, anebo tak, že rozšíří features (ale ne primárně opravy) z vyšší verze na nižší, avšak jen pro předplatitele, tak je dobré se zeptat, jaký to má v posledních verzích smysl? Když už mám poslední verzi, proč bych měl dělat „update“ na předchozí, ne?

A teď z jiného soudku, byť se jedná spíš o SW na míru. Programátoři a la konzultanti různých „poradenských“ firem (spíš zakuklených zaměstnaneckých agentur) vytvářejí pro různé instituce a korporace různý SW. Jejich management se zajímá o zakázky od cca 1 mil. Kč výš a jen u těch potencionálních odběratelů, kde jsou hotové peníze (banky, pojišťovny, dceřinky zahraničních firem). Pro SW, dodaný nějakou takovouto společností, platí v chování bezezbytku totéž, co pro Embt.
To, že si uživatelé stěžují, že jejich SW vykazuje chyby, to nikoho netankuje… a zaměstnanec, SW používající, po čase už ani necekne neb nechce být úplně nezaměstnaný, případně nechce přijít o část vázané výplaty už s ohledem na jiné formy finančního otroctví.
Viděl jsem zdokumentované chyby (v poslední době spíš logické než tvrdé), které existují v různém SW už léta. Ale nikdo je neopraví. Důvod je jednoduchý, jednak existují super-duper detailní smlouvy na základě tzv. funkčních designů a jednak si opravu svojí chyby dodavatelé nechávají ve vícenákladech pořádně zaplatit (důležité je důkazní řízení, že za to může někdo jiný, obvykle ten, kdo za odběratele smluvně nepokryl všechny aspekty dodávky). A tak si to odběratel rozmyslí a nakonec se to neopraví (a může to být opravdu jednoduchá chyba, s opravou na jednu minutu). A neopraví to ani nikdo od odběratele – a že by svépomocí mohli – prostě proto, že smlouva nedovoluje úpravu dodaného SW. Vícenáklady nebo nová verze, je to prašť jako uhoď, všichni chtějí paušál, ať se tomu říká jakkoliv.

JaroB

6.12.2016 10:32:32 #

Omlouvám se Radku, rozumím non-breakingu, ale pokud mají chybu pod interfacem v nepřístupné vnitřní metodě, kterou nedokážu překrýt, tak toto prostě opravit musí (já to teď dělám tak, že zkopíruju např. jednotku Printers.pas rovnou do projektu, v ní opravím chyby a překompiluju s projektem). A pak je otázka výběru chyb, zřejmě tickets tahají z klobouku jako králíky za uši...

Asi je jejich benefit, že mají dost neprůstřelný support, který neodpovídá na to, co je poptáváno, odpoví-li vůbec :)

JaroB

6.12.2016 13:44:44 #

No tak jistě, žijeme v rozvojové zemi s dlouhodobým (stovky let) maximem asi 70% ekonomických a intelektuálních výkonů ve srovnání se SRN a Rakouskem a s výrazně nižšími mzdami (jediná naše konkurenční schopnost pro montáž západních technologií zde), o živnostnících a firmách ani nemluvě, kde asi jen 10% těch "reálně schopných" je už dávno konexemi navázáno na státní a obecní rozpočet a jejich velké korporace, ale ani u malé soukromé firmy s řádově 50M obratem díky státním zakázkám nebylo u nás vůbec zanedbatelné si každoročně dokoupit nějaké Delphi licence pro 4 vývojáře za statisíce ... to je prostě kromě Alzy a cca desítky dvou dalších skutečně u nás schopných firem - prostě v ČR nereálné.  Dokonce neexistují ani licence Delphi pro školství zdarma - výsledek je ten, že na elektro průmyslovkách a IT VŠ se bere zpočátku C# a C++ a java (viz. moje děti) a o Delphi jaktěživo žádný kantor ani IT dorost nikdy neslyšeli ... a nikdy v životě se Delphi učit nebudou.  V podstatě uživatelé Delphi jsou dnes ročníky 40+ časově a intelektuálně neschopní se naučit ostatní jazyky ... naprosto nechápu obchodní strategii vlastníků majetkových autorských práv k Delphi ... jedině, že by se aktivně podíleli na výzkumu Alzheimerovské společnosti ... do kdy je senilní člověk schopen programovat v Delphi ... což je s ohledem k vysoké úrovni Delphi a jazyka Pascal obrovská škoda + katastrofa....

Tomts

7.12.2016 9:02:34 #

Pro uživatele Tomts:

To je přesně to, o čem jsem už tady v diskuzi psal. Přestaň šířit lži a nesmysly. Píšeš:

V podstatě uživatelé Delphi jsou dnes ročníky 40+ časově a intelektuálně neschopní se naučit ostatní jazyky ...

To jako má být co ? Urazil jsi celé vývojové oddělení našeho ERP. Zajdi na exkurzi a rád Ti podle Tebe "40+ a intelektuálně neschopné" programátory představím. 40 mám jenom já, ostatní jí dosáhnou až za hodně dlouho a intelektuálně neschopní ? Používáme všechny možné technologie - od Delphi 2007 po Berlin, výroba jede na .NET a C#, e-shopy různě podle potřeby zákazníků - PHP, ASP a další, sám programuji v případě potřeby zákazníka v Javě, PHP, Lazarusu, projekt jsem dělal v Pythonu i C, když bylo potřeba a tak dále a tak dále.

Takže laskavě přestaň šířit bludy. Navíc znám spoustu programátorů 40+, jak píšeš, ale intelektuálně neschopní rozhodně nejsou.

S tím školstvím jsi také úplně mimo - Embarcadero teď do škol naopak cílí.

A když už jsme i toho - nejhorší zkušenost mám s programátory vylezlými ze škol, kteří sice Delphi neznají, v životopise mají Javu, .NET a podobně a když po nich chceme reálně výsledky, vyrážím je tady dveřmi, protože něco tak příšerného jsem neviděl. Takže intelektuálně neschopný je někdo úplně jiný než uživatelé Delphi.

Přestaňte už tady prostě šířit ty lži a nesmysly, založte si třeba někde fórum, kde si kritizujte. Tento server je velice kvalitní, Radek Červinka ho skvěle řídí, přispívají sem opravdu velmi schopní lidé, ale nebaví už mě číst tyhle vaše lživé a nenávistné komentáře.

Marek Weyda

7.12.2016 10:43:55 #

Zrovna nedávno jsem se Radku pral se zmiňovaným printers.pas unit. Je tam nějaká chyba v metodě Abort, kolabuje na určitých tiskárnách při pokusu o CheckPrinting. Dále v EndDoc se tak nějak netestuje Abort. Taky jsem musel upravit SetPrinter podle doporučení, a to kvůli zámku v DeviceMode. V metodě SendPrinterIndex jsem zvětšil cesty na driver a device. A taky musel odejmout RaiseError v proceduře TPrinter.SetToDefaultPrinter (vysoce nepříjemné pro síťové tiskárny, avšak :( ne všechny). To je asi ve zkratce pár oprav nad originální unitou printers v Seattle. A díky tomu se zlepšilo i chování QuickReports vůči přepínání tiskáren - to je ale jiná kapitola sama pro sebe.

No a pro další uživatele u nás, kteří nepoužívají aktuální verze Delphi, jsem to backportoval až k Delphi 2010,  ty chybky jsou fakt věčné. Úpravy pro Delphi 2009 a nižší jsem už nedělal, Berlin nemám, nemohu posoudit, zdali něco opravili.

JaroB

7.12.2016 11:18:04 #

Chyby nad printers jsou reportované zřejmě v různých QC - já to nepsal - a některé asi budou už z dob Tiburonu, speciálně ten default.

JaroB

7.12.2016 18:24:28 #

Zdravím,
verzia C++Builder 10.1 Berlin Starter po inštalácii bude fungovať aj offline bez trvalého pripojenia? Pri inštalácii som mal sieť a po odpojení to funguje, ale platí to nastálo? Alebo raz napr. za mesiac treba pripojiť? Vďaka Radku.

Radim

16.12.2016 13:17:31 #

Jsem rád za info o školních verzích od léta 2016 zdarma (po 10+ letech) - mělo by se to ale někdy promítnout i do ceníků (tuším zatím jen zpráva u Kubáta na hlavní stránce vpravo dole) - IDERA si neúnosný stav zřejmě konečně uvědomila - tak jen tak dál !!!  Programátoři vylezlí ze škol (co od spolužáků nebo učitele opsali pár programů a prolezli cca 10h výuky C#, Java, C++) nejsou programátoři.  Ale existuje pár mladých lidí s DNA touhou něco "tvořit", kteří zavčasu okolo 15 let pochopili, že jediná cesta je samostudium + testy horem-dolem + hlavně praxe (dělat na konkrétních projektech) ... zbytek hodně přes 90% (měřítka = hmota/spotřeba/zábava/koryto/ego...) nabízí akorát ta jména-pojmy-dojmy a lepší to u nich prostě nikdy nebude - převzali od rodičů/školy/státních_médií tenhle v ČR dnes většinový přístup k životu.  A kantoři na SŠ (hlavně průmyslovky elektro a IT) jsou spíše v před-důchodovém věku nebo vyhození ze soukromých projektů (na výběr - pracák nebo školství) ... takže před Delphi je hóóódně dlouhá cesta právě do škol a ke studentům - bohužel nevidím, kdo by si to tam - i teď zdarma - ve velkém pořizoval.  Kdo zůstal malou chvíli stát - už dnes stojí opodál.  Jinak Delphi + hlavně Radkovi už roky a moc fandím + nenechat se otrávit ... Pozitivní myšlenky jediné mají energii tvořit lepší produkty i budoucnost.

Tomts

16.12.2016 13:49:27 #

To Marek Weyda
Sis akorát vytrhl z kontextu "intelektuálně neschopní" a "40+ let" a sám sis to už doplnil ... proboha nikde nepíšu, že Delphi programátoři jsou intelektuálně neschopní.  Jedině jsem (možná až moc stručně) konstatoval všem asi známý fakt, že lidi odkojení 1995+ na krásné + jednoduché + tehdy i bezkonkurenční Delphi pro WIN32 (a před tím obvykle na Turbo + Borland Pascalu), kterým je dnes typicky 40-60, prostě typicky nemají akční rádius studovat desítku ostatních jazyků a technologií a jsou proto velmi "nasraní" na cenovou a technologickou politiku majitelů Delphi za zhruba posledních 15 let.  Jestli děláš ve firmě, která má prostředky na každoroční licence Delphi Architect pro tým XY vývojářů + máte tam vybrané schopné mladé lidi atd... no tak děláš v jedné z těch asi 20-ti reálně schopných SW ČR firem, která si to může dovolit a gratuluju, jen tak dál !!!  Pro nás = relativně malou firmu s obratem jen okolo 50M (HV jen okolo 30% z obratu) s vývojem  vlastních prostředků MaR + vlastní SCADA ŘS pro průmyslovou automatizaci prostě byla cenová a technologická politika EMBD dost velký problém pro našich 4-5 vývojářů.

Tomts

16.12.2016 15:24:48 #

To Radek, cituji: "Viděl jsem statistiky jak se rapidně zvedají počty členů různých skupin na internetu ohledně Delphi nebo Rad Studia (mají to hodně plánované a celkem ambiciozně), jak se zvedá čtenost a klikání na obsah newsletteru co se posílá o aktualitách v Delphi. Z toho všeho mám obrovskou radost. IDERA velmi masíruje různé komunity o povědomí o Delphi. "

Jako vlastník portálu Torry.net mohu potvrdit, že se pomalu ale stále zvyšují počty nových nebo aktualizovaných komponent a konstantně roste i počet návštěvníků (za posledních 5 měsíců měsíčně o 1000, což je myslím velmi slušné). Takže já nemyslím, že by se Delphi nemělo do budoucna dařit.

Jinak přeji všem klidné Vánoce a do nového roku čistý kód bez AV exceptions :-)

A380

16.12.2016 19:01:24 #

Je potrebne tiez brat v uvahu v akej kraine s akou zivotnou urovnou zijeme. My tu vo velkom hromzime nad cenou licencie pretoze nase ekonomiky a nas trh je taky aky je. Programatori zarabaju v cistom povacsinou okolo 1000-2000€, v tych lukrativnejsich poziciach to moze byt este o nejaku tu tisicku viac. Ale produkty ktore nase firmy vyrabaju su urcene pre beznych ludi horko tazko zarabajucich 1000€, navyse nase trhy poskytuju max len niekolko milionov zakaznikov. Ale zoberte si take nemecko, rakusko a ine vyspele krajiny kde platy programatorov su 4000+ a zamestnavatel v hrubom kazdy mesiac musi platit vyse 7 tisic a viac euro mesacne na zamestnanca. Ich trhy ponukaju desiatky az stovky milionov kupyschopnych obyvatelov. V takom pripade nie je az taky problem si zakalkulovat kazde dva roky na upgrade 2000 euro.

To Tomts:
A co za SCADU to vyvyjate? Zvedavost mi neda, tiez posobim v priemyselnej automatizacii.

Daniel Andraščík

17.12.2016 8:36:03 #

Daniel Andraščík: 2000 EUR v čístom je(len) mzdový náklad pre zamestnávateľa cca 48000 EUR ročne, výdaj napr. 700 EUR za ročný subscription nie je nič. Problém je, že nie sú ľudia, pretože žiadny hobby si to nekúpi. A to čo sa zanedbalo pred 10 rokmi už nedoženieš tak ľahko. Zohnať ľudí na nové technológie a Pascal je proste problém.

ps

19.12.2016 9:32:17 #

Hlavní problém slabosti Delphi vidím v server-side. Poslední Kylix 3 vyšel pře čtrnácti lety. Delphi není schopno konkurovat jiným platformám s jinými jazyky (JAVA, PL/SQL), potřebovalo by silný framework, něco jako je uniGUI (s plně integrovaným JavaScript library Sencha Ext JS), a to tak, aby vše bylo součástí Delphi a dalo se s tím rovnou, bez nějakých mezistupínků, instantně pracovat. A možnost deploy binu rovnou na některý Unix…
Na embedded zařízení to taky není, skleníky, výtahy i myčky jsou programovány jinak :) a v některých tiskárnách a měřácích ještě tepe Z280… :)

JaroB.