JBuilder 2005 Gotchas!

4 05 2006

Evet Visual Studio 2005 hakkında yazdıklarımı tekrar okuyunca durumu dengelemek gerektiğini düşündüm :). Sonuçta kıyaslayınca VS hala çok başarılı ama bazı hataları olacak tabi ;). Neyse yine VS’yi çekiştirmeden konumuz JBuilder’a geçelim :).

  • VS2005 ile gelen (bak yine!) main()‘in ayrı bir Program.cs gibi bir dosyada olması zaten uzun süredir Java’cıların standart şekliydi. JBuilder’da da bu bağlamda bir MyApplication.java bir de MyFame.java gibi iki dosya oluşturur. MyFrame.java’da JFrame veya Frame’den türeyen sınıfın kaynak kodu bulunurken, tahmin edilebileceği gibi MyApplication.java’da bu frame’i SwingUtilities.invokeLater() ile veya direk show() diyerek mesaj döngüsünü başlatan main()‘in kaynak kodu bulunur. Bu şekilde herşey sağlıklı giderken siz eski .NET alışkanlığı ile gelip Frame’in içine kendini invoke eden main()‘yazarsanız o zaman JBuilder işleri biraz karıştırıyor… Frame’in kod görünümünden tasarım görünümüne geçerken bir anda içi boş başlıksız ve daha kötüsü windowClosing() WindowEvent’i (siz gerekli kodu yazmış olsanız bile) handle edilmemiş bir hayalet pencere beliriyor. Bu pencereyi (neyseki) iconify edip işinize devam ettikten sonra her kod görünümünden tasarım görünümüne geçişte yeni bir hayalet pencere beliriyor. 🙂 Dolayısıyla görev çubuğunuz dolunca JBuilder’ı kapatıp tekrar açmanız gerekiyor… Aslında hiç kasmadan o main()‘i oradan çıkarmak en iyisi ama yine de bu bir bug…
  • Uzun süre inaktivitede mesala gorev çubuğuna indirip bir süre geçtkten sonra tekrar kendine gelmesi uzun süre alabiliyor hatta gelemeyebiliyor. Program muadili Oracle JDeveloper gibi Java ile yazıldığı için ve sağ alt köşede heap bellek miktari ile GarbageCollector simgesini görünce insan JBuilder’ın kendini topladığını düşünüyor :).




Visual Studio 2005 Gotchas!

4 05 2006

Her ne kadar piyasadaki (Java IDE leri dahil) en sağlam IDE’lerden biri olduğunu düşünsem de Visual Studio’nun yeni sürümü, eski sürüm Visual Studio 2003’e göre kesinlikle daha az stabil. Etrafımdaki bir çok kişi C# editörünün background compiling ile daha başarılı hale geldiğini söylese de genel IDE deneyimi olarak daha az verim alındığını düşünüyorum. Şimdiye kadar beni en çok rahatsız eden kusurları sıralamak gerekirse :

  • Hiding Panel’lerin hide etmemesi, daha çok sol tarafta bulunan “Solution Explorer” ve “Properties” panellerinde karşılaştığım bu sorun beni gerçekten çileden çıkarıyor. Sabitleme raptiyesi basılı değilken panel kendiliğinden kayarak hide etmesi gerekirken donup öylece kodunuzun üzerinde kalıyor. Paneli sabitleyip (raptiyeye tıklayarak) tekrar auto-hide moduna sokmak (raptiye ye bir daha tıklayarak) zorunda kalıyorsunuz. Brrr!
  • IDE’nin Bir anda kapanması, uzun süredir bir tik haline gelen CTRL+S hareketim yüzünden şimdiye kadar bir veri kaybına yol açmadı ama gerçekten rahatsız edici.
  • Toolbox’ın resetlenmesi, özellikle önceki maddede söylediğim olaydan sonra gereçekleşen ve 3rd party component kurulumları ile gelen tabların, (componentleri uninstall edip tekrar kurmaya üşenme sonucu) dandik versiyonlarının oluşturulması için gerekli .dll(ler)i bulup refere edilmesini gerektiren gerçekten rahatsız edici bir şey. Tek kaybettiğiniz 3rd party controllerin kısayolları değil ama kendi türemiş veya UserControl’lerinizin kısa yolları da ki bu bir tane daha madde demek bz. aşağı 🙂
  • Diyelim ki bir sebepten dolayı Toolbox’ınız resetlendi (!), veya yeni bir UserControl yaptınız ve bunu Toolbox’ınıza koymak istiyorsunuz. Eğer UserControl’ünüz programınızın .exe’sinin olduğu projede ise Toolbox’dan “Choose Items…” deyip kendi projenizi yine kendi projenize “Browse…” diyerek refere etmeniz gerekiyor. Ve bu işlemde gayet çalışıyor :). Yalnız ugulamayı derlerken warning almanız olası. Çünkü UserControl’ü kullandığınız yerde derleyici iki tane referansla karşılaşıyor biri yerel assemble içindeki diğeri ise refere edilmiş. Dolayısıyla birini seçiyor (hangisini diye sormayın :)). Bunu daha sonra o referası silerek düzeltebiliyorsunuz ama UserControl, Toolbox’ınızda kalmaya devam ediyor… evet kabul ediyorum uzundu…
  • Form’dan türeyen (yada designer.cs ve resx alt dosyalarına sahip diyelim) .cs dosyalarınızı kopyalayıp isimlendirirken dikkatli olun!




Convert mi? Parse mı?

3 05 2006

.Net Framework 2.0 da C# ile object tipi bir nesneyi alıp bunu integer bir değere dönüştürürken acaba hangisi daha performanslıdır :


object deger = 1492;
int.Parse(deger.ToString()); // Bu mudur?
Convert.ToInt32(deger); // Yoksa bu mu?

Lutz'un Reflector'ü ile mscorlib.dll'i açıp kodları incelediğimizde kesin yargıya ulaşamıyoruz. En iyisi gözlerimizle görmek diyerek konu hakkında minik bir uygulama yazdım.

Tester Uygulaması

public partial class Form1 : Form   
{   
object kurban = 1492;   
int sonuc;      

private void btnConvertTo_Click(object sender, 
    EventArgs e)   
{   
    for (int i = 0; i < 9000000; i++)   
    {   
        sonuc = Convert.ToInt32(kurban);   
    }   
    MessageBox.Show("Bitti!");   
}      

private void btnIntParse_Click(object sender, 
    EventArgs e)   
{   
    for (int i = 0; i < 9000000; i++)   
    {   
        sonuc = int.Parse(kurban.ToString());   
    }   
    MessageBox.Show("Bitti!");   
}  

}


Sonuçlara baktığımızda "ToString + int.Parse" butonuna tıkladığımızda 6sn sonra "Bitti!" mesajını görürken, "Convert.ToInt32" butonu 1sn içinde bize "Bitti!" mesajını gösterebiliyor.

Sizce hangisi daha performanslı?