03/06/2013 12:46

FireMonkey'de bir tarayıcı bileşeninin bulunmaması nedeniyle büyük sıkıntı çektim. Tanınmış Delphi Chromium Embedded projesi en son yapıda hala FMX desteğini içeriyordu. Ancak üzerinden epey zaman geçmesine rağmen yazarın FMX2 desteğini eklemek için acelesi yok. Sonunda durumu kendi ellerime almak zorunda kaldım.

Resmi derlemedeki TChromiumFMX bileşeni FireMonkey'de (XE2'de) oldukça iyi çalışıyor, ancak FMX2'de bile derlenmiyor. Nasıl çalıştığını biraz çözmem ve düzeltmem gerekiyordu. Neyse ki büyük bir değişikliğe gerek kalmadı.

FMX2'de bileşenin ihtiyaç duyduğu iki şey değişti.

Öncelikle Tbitmap artık ScanLine ve StartLine özelliklerine sahip değil. TBitmap içeriğine doğrudan erişim yeniden tasarlandı (nedenini merak ediyorum) ve artık TBitmap.Map yöntemini döndüren TBitmapData sınıfı aracılığıyla sağlanabiliyor.

İkincisi, daha iyi bilineni - Platform .* artık orada değil, artık gerekli arayüzü TPlatformServices.GetPlatformService aracılığıyla almanız gerekiyor. Burada her şey oldukça basit ve hiçbir sorun yok.

Özellikle yaratıcı bir şekilde test etmedim, ancak benim amaçlarım açısından bileşen oldukça uygun - web sitelerini onun aracılığıyla görüntüleyebilirsiniz. İndir. Muhtemelen düzenlemelerimi, resmi sürüme eklemenin gerekli olduğunu düşünebilecek yazara da göndereceğim.

30.07.2012 02:43

Jason Southwell, yerel Windows/OSX kontrolleri için bir dizi FireMonkey sarmalayıcısı geliştirmeyi öneriyor ve bunun için para topluyor. Başlangıç ​​olarak 20 bin dolar toplamayı planlıyor.

Fikir açık. Mevcut FireMonkey bileşenleri Delphi kullanılarak neredeyse sıfırdan oluşturuluyor ve bu, bir yandan büyük ölçüde platformlar arası işlevsellik sağlıyor, ancak diğer yandan sonuç olarak, şu anda desteklenen her iki işletim sisteminde de pek doğal görünmeyen bileşenler elde ediyoruz. . Ve bu o kadar da kötü değil - hariç dış görünüş, bu bileşenlerin mantığını bağımsız olarak geliştirmelisiniz. Örneğin, RichEdit oldukça karmaşıktır; mantığını FireMonkey'de kendiniz tekrarlamak önemsiz bir iş değildir. Hem VCL hem de CLX tekerleği yeniden icat etmediler, ancak hazır olanı kullandılar.

Ve şimdi kötü haber. Her şey çalışma zamanında çalışıyor ancak yeni sekme türümü Öğe Tasarımcısına eklemenin bir yolunu bulamadım. Görünüşe göre tüm liste kontrollerinde aynı sorun var: TListBox, TGrid, vb. İlk başta onların uygulanmasına yönelik yaklaşımı gerçekten beğendim, ama şimdi bir şekilde bundan şüpheliyim. İnternet araştırması bu sorunla yalnız olmadığımı gösterdi.

Yardım sessiz, kodda da hiçbir şey bulamadım. Gerçekten hiçbir yolu yok mu? Bu son derece tatsız olurdu.

FireMonkey teriminin az çok tanıdık gelmesinden bu yana, tüm geliştiriciler için olmasa da en azından Delphi kullananlar için yeterince zaman geçti. Bu süre zarfında FireMonkey ile ilgili kitaplar, FireMonkey ile ilgili makaleler ve çok sayıda blogda FireMonkey ile ilgili yazılar ortaya çıktı. Bütün bunları okumak çok ilginç. Ancak hiçbir teori pratiğin yerini alamaz. Ve daha önce pek çok kişi gibi ben de FireMonkey'i kullanarak bir şeyler yazmayı denemek için can atıyordum.

Ancak bir sorun ortaya çıktı. Bazı nedenlerden dolayı, çok karmaşık olmayan bir çalışma projesini hayata geçirmem gerektiğine karar verdim.

Bunun benim için neden bir sorun haline geldiğini açıklamak için biraz (içimden yazmak, lirik olmak geliyor) konu dışına çıkmam gerekecek. Bir geliştirici olarak geçmişime bir gezi. Delphi kullanarak programlamaya ilişkin bazı görüşlerimi açıklayın.

Delphi'yi Windows 3.1'de yani ilk versiyondan itibaren kullanmaya başladığımı söylemeliyim. Ve o zamandan beri VCL üzerinde çalışıyorum. Tabiri caizse orijinalinden çalıştım. Kaynaklara baktım, ulaştım, izini sürdüm. Tekrar ve tekrar.

Bilindiği gibi farklı zaman Delphi ile birlikte gönderilen bileşenler seti, VCL'deki boşlukları doldurması beklenen ve muhtemelen dahil edilmeden önce bir tür kalite kontrolünden geçmiş olan üçüncü taraf bileşenleri içeriyordu. Bu bileşenlerin bir kısmı bugün tedarik edilmeye devam etmektedir. Aynı Indy'yi alın. Kimseyi gücendirmek istemiyorum, bu tamamen benim kişisel görüşüm ve bir bileşen geliştiricisi olarak benim için de geçerli: devasa ve çeşitli VCL kadar derinlemesine düşünülmüş ve bu kadar iyi uygulanmamış tek bir set yok. Hayır, nihai gerçekmiş gibi davranmıyorum ve elbette VCL'nin kendisinde yanlış anlaşılmaya neden olan, reddedilmeye neden olan ve katılmamak istediğiniz birçok hata, karar var. Ama her zaman kimsenin olmadığı izlenimine kapıldım üniforma tarzı. Bana göre VCL'de tüm Delphi tasarımını destekleyen ve hem yazılım altyapısının hem de geliştirici topluluğunun etrafında inşa edildiği güzel ve güçlü bir çekirdek var. Delphi'nin ölümüyle ilgili söylentilerin hala söylenti olarak kalması büyük ölçüde VCL sayesindedir bana göre. Ve VCL teslimatı üçüncü taraf geliştiricilerin bileşenlerini içerdiğinde, bunların farklı olduğu hemen fark edildi.

Ama sonra öyle bir an geliyor ki VCL'nin modası geçmiş bir teknoloji olduğunu duyuyorum. Geçmişte kalması gereken bir teknoloji. Geliştiriciler tüm yeni projelerini FireMonkey'de uygulamalı ve eskilerine gelince... onları yeni parçalara aktarmak güzel olurdu. FireMonkey her zaman, her yerdedir. Ve bunu farklı kaynaklardan duyuyorum. Ve oldukça ısrarla. Hayır, kimse VCL'yi öldürmez. bizimle kalıyor. Ama artık bir numara değil. Yedek olmalı. En azından ürünün geleceği hakkında söylenenleri bu şekilde anlıyorum.

Prensip olarak bu durumu anlıyorum. Çoklu platform ve daha da önemlisi çapraz platform için bir rota belirledik. Sonuçta VCL nedir? Görsel Bileşen Kütüphanesi. Görsel bileşenler kütüphanesi. Buna katılmayabilirsiniz. Örneğin, her zaman birçok görsel olmayan bileşenin, bileşenlerin değil, yalnızca sınıfların VCL'nin ayrılmaz bir parçası olduğunu ve çok sayıda üçüncü taraf sınıf ve bileşenin VCL'nin bir devamı, bir uzantısı olduğunu düşündüm. TDataset'in mirasçılarının VCL'nin bir parçası olduğunu düşünemiyorum. Örneğin, DBExpress Kütüphanesi terimi bunun bir VCL olmadığını öne sürüyor. Görünüşe göre Embarcadero, benim bakış açıma göre VCL'yi gerçekten bir dizi ayrı kütüphaneye bölüyor. Hayır elbette tamamen ayrı değil ama yine de. Ve eğer bu bakış açısını kabul edersek, FireMonkey'in tam olarak VCL'nin görsel kısmının yerini alması amaçlanıyor (sınıfların ve bileşenlerin kütüphanesinin tamamını, belki de Borland Bileşen Kütüphanesini nasıl adlandırmalıyım?).

Kütüphanede yer alan görsel bileşenler nelerdir? İşletim sistemi tarafından sağlanan düşük seviyeli temel öğeler etrafında. Pencere tutamaçları, yazı tipleri, pencerelerin kendileri, giriş öğeleri, mesajlar, aygıt bağlamları ve çok daha fazlası - bunlar Delphi ile sağlanan kitaplığın kavramları değil, kavramlardır işletim sistemi. Evet, kesinlikle Windows. Ve eğer platformlar arası bir kütüphane oluşturmak istiyorsanız, o zaman kütüphane kullanılarak yazılan programı çalıştıran işletim sisteminin sunduğu altyapıdan vazgeçmek mantıklı olacaktır.

FireMonkey'in yapmaya çalıştığı şey tam olarak budur. Çeşitli işletim sistemlerinde desteklenen temel mekanizmalara dayalı, işletim sistemlerinin sunduğu hizmetin yerini alabilecek bir altyapı oluşturmaya çalışıyorlar.

Birçok kişi denediğini hatırlıyorplatformlar arası yalnızca kütüphaneyi değil aynı zamanda Delphi'yi de destekler. Delphi 6'ya paralel olarak Kylix ürünü ve CLX kütüphanesi piyasaya sürüldü. Bütün bunlar Linux için geliştirme yapabilmeniz için yapıldı. Ancak Linux, Windows'un sahip olduğu grafiksel pencere arayüzü açısından temel kavramların çoğuna sahip değildir. Linux için pencere arayüzü genellikle yerel bir olgu değildir. Bu isteğe bağlı bir uygulamadır. Ve bir tür sentetik kütüphane yazmam gerekiyordu. Onun yardımıyla hem Windows hem de Linux için bir program yazmak mümkün oldu. Bununla birlikte, CLX'in analog görsel bileşenlerini kullanmaya çalıştığımda yaşadığım hayal kırıklığı değil, daha ziyade rahatsız edici rahatsızlık hissini hâlâ hatırlıyorum. Birçok şeyi kaçırmaya başladım. VCL kullanarak geliştirme yaparken düşünmeden yapmaya alışkın olduğum şeylerin CLX kullanarak yapılmasının zor, tamamen farklı veya imkansız olduğu ortaya çıktı.

BDE'den DBExpress'e geçerken de yaklaşık olarak aynı şeyleri hissettim. Eski, Field Test BDE'den tanıdık (Borland bunu zaten Windows için Quattro Pro'da ve Windows için Paradox'ta kullanıyordu ve buna ODAPI ve ardından IDAPI adı verildi ve bence Microsoft ODBC'nin çok üstündeydi) ilan edildi yerini yeni projelere bırakması gereken eski teknoloji yeni kütüphane. İlk başta DBExpress'te her zaman bir şeyler eksikti, özellikle de bilgi.

Aynı zamanda, ne yukarıda listelenen kütüphaneleri ne de onların ortaya çıkmasına neden olan kararları hiçbir şekilde azarlamak veya eleştirmek istemiyorum. Sadece benim izlenimlerimden, bazen de ilk izlenimlerimden bahsediyoruz.

FireMonkey'i kullanarak küçük bir çalışma projesi yazma kararının neden bir takım sorunlara yol açtığı artık muhtemelen biraz daha netleşiyor. Uzun yıllar boyunca tasarımlar, projeler ve planlar geliştirilirken belirli bir klişe, neyin ve nasıl yapılacağına dair belirli bir şablon geliştirildi. Benim durumumda şablonun değiştirilmesi gerektiği gerçeğiyle yüzleşmek zorunda kaldım. Çünkü VCL kullanmaya alışık olduğunuz her şeyi FireMonkey üzerinde oluşturulmuş bir projeye aktaramazsınız.

Projeye başladığımda belli bir deja vu hissi yaşadım. Yani rahatsızlık hissi. Örneğin alışılagelmiş giriş elemanlarının pek fazla özelliği yoktur. İşletim sisteminin bazı özelliklerine ilişkin bilgilere ilişkin püf noktalarına dayanan, uygulamada sağlam bir şekilde yerleşmiş teknikler, yeni bir bağlamda çalışmaz. Bazı bileşenlerin kökten değiştiğinden bahsetmiyorum bile.

Peki, bir şey daha önemli nüans. Eğer (iş) derleyici yazma, modelleme sistemleri veya son derece bilimsel herhangi bir şeyle ilgili değilse, işyerinde genellikle ne tür projeler yapmak zorundasınız? Çoğu kişi için bunun veritabanlarını kullanmayı içeren bir şey geliştirmek olduğunu düşünüyorum. Üstelik son derece bilimsel olan bir şey de DBMS'nin sağladığı hizmetleri kullanabilir.

Burada beni başka bir pusu bekliyordu. Bazı nedenlerden dolayı, pratikte FireMonkey'in veritabanında depolanan verilerle çalışmaya odaklanan unsurlar içermediği gerçeğiyle karşılaştığınızda, kendinizi buna pek hazır bulmazsınız (en hafif ifadeyle). Bunu zaten birçok kez okudum ve (teorik olarak) ne kullanacağımı biliyorum. Canlı Bağlamalardan bahsediyoruz.

Gerçekten harika programcıların db uyumlu bileşenleri kullanması mı yoksa kullanmaması mı gerektiği konusunda bir tartışmaya dahil olmak istemiyorum. Uygulamada yeni bir projeye başladığımda her ikisine de alışmam gerektiği gerçeğiyle karşı karşıya kaldım. yeni görsel bileşenler ve görüntüleme, düzenleme ve son olarak kaydetme için veri almanın yeni bir yolu. Bu da yine ne kötü ne de iyi. Benim için aynen böyle oldu.

İlk izlenimlerle ilgili yazımı burada bitirmek istiyorum. Sırada proje üzerinde çalışırken nelerin ve nasıl aşıldığına dair hikayeler var.

Üçlü Etki Görsel nesnelerin dokusuna dalga dalgaları uygulayan bir efekt yaratma sınıfı.

Dalgalanmanın merkezi özellikte belirtilmiştir Merkez. Dalgalanmanın diğer yönleri özellikler kullanılarak özelleştirilebilir Genlik(Genlik), En Boy Oranı, Ve Faz(Faz). Dalgalanma dalgalarının sayısı özellik tarafından belirlenir Sıklık(Sıklık).

Aşağıdaki tablo etkinin sonuçlarını göstermektedir Üçlü Etki forma yerleştirilen bir PNG fotoğrafına ( . Dalgalanmanın merkezi görüntünün ortasındadır. Diğer özellikler Üçlü Etki varsayılan değerleriyle kullanılır ( Genlik = 0,1, En Boy Oranı = 1,5, Sıklık = 70, Faz = 0).

Bu eğitimde FireMonkey uygulamasındaki bazı temel görüntü efektlerini kullanacaksınız.

Adım 1: Efekti görüntüye uygulayın.

FireMonkey'de bir görüntüye görüntü efekti uygulamak basit bir işlemdir. Bir görüntüyü içerebilecek bir bileşen oluşturmanız ve ardından görüntü efektlerinden birini uygulamanız yeterlidir.

Yeni bir FireMonkey uygulaması oluşturun ( Dosya> Yeni> FireMonkey Masaüstü Uygulaması> HD FireMonkey Uygulaması).

Bileşeni forma yerleştirin.

Araç çubuğunda bileşeni seçin.

TImage'ı tasarımcıdaki forma yerleştirin.

Bileşenin form tasarımcısının merkezine yerleştirilmediğini görebilirsiniz. Şekilde görüldüğü gibi görüntü alanı boyutunu mümkün olduğu kadar büyük yapmak gerekmektedir. Bunu yapmak için tasarım formunda bileşeni seçin ve ardından özellikleri değiştirin. Hizala V alİstemci Bileşenin boyutu, form alanının istemci boyutuyla aynı olacak şekilde Nesne Denetçisi'nde.

Efekti uygulamak istediğiniz görüntüyü seçin. Bileşen, resmi özellikte saklar Bit eşlem. Mülk seçin Bit eşlem nesne denetçisinde ve kullanarak Düzenlemek... Bir resim seçmek için

1. Artık görüntü için bir efekt seçebilirsiniz. Araçlar paletinden, seçin Üçlü Etki.

Şimdi Dalga etkisi pencerede görüntülenir Yapı.

Bir efektin uygulanabilmesi için başka bir bileşenin alt öğesi olarak tanımlanması gerekir. Bu durumda, Dalgalanma Etkisi1çocuk olarak tanımlanmalıdır Resim1. Bunu yapmak için sürükleyin Dalgalanma Etkisi1 ve üzerine yerleştir Resim1 yapı panelinde.

1. Artık bunu görebilirsin Dalga etkisi zaten Form Designer'da çalışıyor.

1. Özelliği değiştir Sıklık Açık 20 .

Adım 2: RippleEffect'e animasyon efekti uygulayın.

Vurgulamak Dalga etkisi panelde Yapı.

Bir mülk seçin Faz Object Inspector'da ve komutu çalıştırın Yeni TFloatAnimation Oluştur açılır menüden.

Emin olun Kayan Animasyon1 alt öğe olarak tanımlandı Dalgalanma Etkisi1.

Özellikleri değiştir Kayan Animasyon1 aşağıda olduğu gibi:

Ve son olarak bir olay prosedürü ekleyelim OnMouseMoveİle .

Muhtemelen Embarcadero'nun platformlar arası bir GUI oluşturma konusundaki yeni vizyonunu aktif olarak desteklediğinin farkındasınızdır - FireMonkey ( buna çerçeve diyorlar ama şu anki haliyle kulağa çok hoş geliyor). RuNet'te birbiri ardına yarışma duyuruluyor, web seminerleri düzenleniyor ve ikincisinin kalitesi arzulanan çok şey bıraksa da etkinlik cesaret verici. Şimdi aslında konuya geçiyoruz. Son yarışmanın bir parçası olarak öğrenmeye yönelik bir tür uygulamanın geliştirilmesi önerildi. Ve dün Evgeniy Chmel'in yazdığı başka bir çalışma ortaya çıktı ( Bu soyadının eğimli olup olmadığını bilmiyorum). Daha önce görülen basit "tek biçimli" olanlardan farklı olarak, burada maymunu tüm uzuvlarından çekmeye çalışıldı: stilizasyon, 3D, gölgelendirici efektleri ( Embarcadero evangelistleri GPU hızlandırmalı grafikler hakkında konuşmayı severler :))). Bakalım bundan ne çıktı. Webinarları izlememiş olanlar için küçük bir inceleme yapacağım. Web seminerlerinden birinde Embarcadero evanjelisti Vsevolod Leonov, Silverlight SDK ve Windows emülatörü Telefon 7 bilgisayarında “çalışmadı” (bu bir alıntıdır) çünkü... video bağdaştırıcısını veya ayarlarını beğenmediler GPU. Ancak Vsevolod, FireMokey kullanılarak geliştirilen uygulamaların hiçbir şekilde donanım gerektirmediğini sürdürüyor. Bakalım bize nasıl yalan söylemiş. Mark Rusinovich'in Process Explorer v15.05'i tarafsız tanığımız olacak. Öyleyse Evgeniy’in uygulamasını indirin ve başlatın ( Evgeniy’in uygulamasının ekran görüntülerini vermiyorum, çalışmalarının bağlantısında mevcut. Bulanık yazı tiplerine dikkat edin).

Uygulamayı başlattık. Gelelim tüketime:

Utanmazlık ama "ileri teknoloji" affedilebilir. “Dersler” bölümüne gidin ve “Ders 5”i seçin. Sahne hazırlıkları başlıyor. Bu süreç uzundur ( 3,3 GHz frekansa sahip dört çekirdekli Phenom II ile bu işlem bir dakikadan biraz fazla sürdü), sabırlı ol. Sahne inşa ediliyor. Gelelim tüketime:

Maymun iyi beslenmişti. Çok iyi. Şimdi farenizi cevap seçeneği düğmelerinin üzerinde hareket ettirmeyi deneyin. GUI çok yavaş tepki veriyor gibi görünüyor, değil mi? CPU kullanım grafiğine bakın ( Yani kendi bilgisayarında denemelisin) – bu anlarda yükü %100'e yaklaşır ( Dört çekirdekli bir işlemci için ~%21,5'im vardı, bu da tek çekirdekli bir işlemci için %86'ya eşdeğerdi). Ancak birisi bize GPU hızlandırmalı grafiklerden bahsetti. Tamam, devam edelim. Derste tüm soruları cevaplıyoruz. Gelelim tüketime:

Gözlerin genişledi mi? Şimdi karşılaştırma için FarCry'nin 3D nişancı oyununun aktif olarak ne kadar tükettiğine bakın. Oynanış (İlgilenen varsa seviyenin adı Fabrika'dır) 1440x900 tam ekran modunda çalışıyor:

Kendi sonuçlarınızı çıkarın.