Bazične VCL komponente se nisu značajnije menjale (ni u kvalitetu ni u kvantitetu) još od prve verzije, a na žalost izgleda da i neće u skorije vreme. Upravo je brojnost i kvalitet tih komponenti pre više od decenije činio snagu Delphi/C++ Builder-a, koji su "out of box" omogućavali korisniku maltene sve. I mnoge stvari koje su krasile ovaj proizvod i bile njegov zaštitni znak su krenule da se urušavaju. Recimo VCL Help (otkako je krenuo za modernizmom) postao je nedovršeno sra**.

Borland (sada CodeGear) je pre nekoliko godina bio na ivici odustajanja od C++ linije alata i preživeo je teške trenutke. Sada se budi, ali se izgubljeno vreme mora nadoknaditi, pa verovatno po nima postoje i važnije stvari od širenja plate komponenti. Pre svega mislim na unapređenje kompajlera i debuggera, usklađivanje sa standardima i standardnim bibliotekama. Postoji negde na netu onaj upitnik, gde je sažeto data rekapitulacija zahteva dobijenih intervjuima korisnika.

Tragično je recimo da servisne aplikacije (TService) nisu uopšte unapređivane iako je ta tehnologija višestuko unapređivana sa svim novim Windowsima. Otrpike, kod datira od Windowsa 95.

Meni lično, trenutno je najpotrebniji Unicode VCL odnosno UnicodeString pored AnsiStringa (koji bi i sam trebao da bude osavremenjen da pamti CodePage za svaku pojedinačnu stavku).

Ajd' da vidimo šta će biti dalje.

Bez obzira na sve treba paziti i na komponente na paleti. Istina, napokon su redizajnirali gotovo cijeli VCL u C++ Builder-u 2007, Unicode podrška sada dolazi, no čim većeg broja potrebnih komponenti nema cijena razvojnog okruženja je utoliko veća koliko moraš uložiti u dodatne komponente.

Evo, baš navodim za primjer taj TDBGrid. Ovo je zaista bazična komponenta na tom području i zbog nedostatka određenih funkcionalnosti kojima bi se ubrzalo "šetanje" zapisima znam ponekad umjesto C++ Builder-a koristiti C# tj. .NET. Prednosti nisu samo u boljoj funkcionalnosti i više mogućnosti već i sam dizajn komponenti prati izgled OS-a.

Iako ovo baš i nije primarna stvar oko koje se treba brinuti pri izradi razvojnog okruženja u svakom slučaju je jedna od bitnijih. Treba slijediti korak i ostati konkurentan u svim područjima.

Slažem se.

Delphi i C++ Builder se i jesu razlikovali od konkurencije po tome što su od prvog trenutka bili maksimalno friendly prema koderu:

* sve neophodne komponente su bile na dohvat ruke i upravljive kroz Object inspector,
* izuzetno kvalitetan Help sa primerima za 90% situacija.

Trenutno se zaista oseća zastarelost pojedinih bazičnih komponenti kao i Helpa koji nije ni blizu kvaliteta onom prepotopskom *.HLP sistemu (koga ni Vista ne podržava dok se ne instalira poseban dodatak). Ako i to ispuste, mislim da sam alat gubi svoj identitet.

TImage bi trebalo osavremeniti novim formatima, DBGrid čak nema ni glatak (flat) skrol. Wizardi za XP look ne postoje. Ni prodavaca 3rd party komponenti nema kao nekada. Ima tu puno posla.

Ako misle da budu konkurentni, moraće da idu i u "širinu i u vidinu".

Ipak, na osnovu Live Audio chat-a od pre par godina, zaključio sam da im je pre svega prioritet podići funkcionanosti oko samog kompajlera i biblioteka kao temelja svega.

U TImage se mogu dodavati novi formati jednostavnim ubacivanjem odgovarajuceg hedera. Potrazi primer za JPG.
Grid sa sortiranjem, filterima i drugim fancy mogucnostima, kao sto je npr DevExpress, zahteva da se iz baze podataka povuku svi podaci koji se prikazuju u tabeli i da program sam manipulise njima. Zbog manipulacije velikom kolicinom podataka, programi se drasticno usporavaju. Poenta je da postoje razlozi zbog kojih je DBGrid ovakav kakav je.

Da, znam to za JPG, u C++ Builderu dovoljno je dodati:
#include <Jpeg.hpp>
TImage je dizajniran da ima 'Plug-in' arhitekturu.

Ipak, postojala su i neka ogranicenja, mada sad ne mogu da se setim detalja. Neki extended TIFF sam ranije recimo uspeo da upotrebim tek nekim tifflib bibliotekama ali to je bilo vec daleko van VCL-a.

DBGrid je po meni trebao da ima barem aktivan skrol povlacenjem za scrollbar i više funkcionalnosti (tasteri) u ćeliji. To je čini mi se postojalo u verziji 1 i 3, a u 4 je povučeno.

Evo zapravo zbog čega me najviše ljuti DBGrid:



Prije svega, prava je mudrost doći do rješenja da radiš filtriranje već filtrirane tablice, i tako unedogled.. I opet nisam mogao pokriti sve stupce zbog nedostatka radne površine. S druge strane interface je nepotrebno kompliciran zbog filtera (checkbox-ova i edit-a) koje sam naknadno morao staviti, dok i search sam morao realizirati kroz izbornike... I naravno, famozni bug u DBGridu gdje scroller jednostavno nestane u nekim situacijama. Pogotovo ako prikazuje detail tablicu.

Ova komponenta hitno treba redizajn ili treba pronaći neku alternativu jer postoji masa DBGridova za druga razvojna okruženja koja u sebi imaju implementirane ove stvari.

Lista iz naslova je nedavno dopunjena (Updated 23 April 2008):

Ukratko, Unicode support in native C++ and VCL, Faster compiles with precompiled-header tuning, More powerful Project Manager, C++ Class Explorer su stavke koje su bile pod "must have" i evo ih sada na listi...

- Unicode support in native C++ and VCL -

Nije mi jasno kako su se dosad radile multi-language aplikacije u Borlandu bez Unicode support-a?
Pogledao sam itf-ov primer gore.
U TDBGrid-u ima unicode karaktera (latinicna slova) ...dok ih na labelama i meni opcijama nema ...

U MFC postoji odavno unicode support u native C++
al je nije bilo za Resource editor (*.rc) kada hocemo raditi na dijalogu direktno iz IDE okruzenja ..

- Faster compiles with precompiled-header tuning -

Jel ima negde link gde kaze sta mu to tacno dodje ?
Da li to znaci da ne mora da linkuje ceo PCH u *.exe ili u.dll-u vec u zavisnosti kolko je programu potrebno ...

Pozz

Postojale su 3rd party komponente koje su omogucavale Unicode.
A ona šđžčć su radili (Bez Unicodea) ako se podesi kodna strana u Regional Options, ili barem donekle sa SetThreadLocale na pocetku programa.



Dakle to je tehnika koju koriste neki C/C++ kompajleri da se redukuje vreme kompajliranja.
http://support.codegear.com/article/35884

(ovde je Copy/Paste jednog od najboljih tekstova o precompiled headerima u C++ Builderu: Harold Howe)
"Improving C++Builder Build Times With Pre-Compiled Headers."
http://www.tek-tips.com/viewthread.cfm?qid=1255624&page=10

Ok .. jasno mi je
Ako pravimo zasebne resurse (lang.dll) za program da li njegovi string-ovi (tj.labele naslovi , kolone)
mogu da se edituju u Borlandovom VCL-u tj. kroz njegov IDE ili se snimaju samo kao Unicode file ?


Ako jesto to sto sam mislio kako sam shvatio iz linkova (ako nisam nek' neko obrazlozi)
Redukovanje brzine kompajliranja == manji exe fajl ? (deluje mi logicno)
Koliko god danas znacilo to za programe ipak jeste poboljsanje ..
(MFC uglavnom include-uje sve u krajnji exe tako da ne moze da se utice dobijanje na velicini istog) .

pogotovo mi se sviđa ovaj dio:

C++Builder is planned to have a strong commitment to standards based C++ and mixed-mode development with Delphi. The importing of Delphi controls is planned to be much easier and require no special workarounds opening the door to tens of thousands of Delphi controls in C++Builder.