Auzef Görsel Programlama 2024-2025 Vize Soruları
https://lolonolo.com/2026/03/07/gorsel-programlama-2024-2025-vize-sorulari/
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Selamlar. Hiç merak ettiniz mi o
0:02
kullandığımız masaüstü uygulamaları
0:04
nasıl oluyor da sadece birkaç tıklamayla
0:07
böyle sihirli bir şekilde ortaya
0:08
çıkıyor? İşte bugün Windows Forms'un
0:11
temellerine dalarak bu sihrin
0:13
arkasındaki sır perdesini aralayacağız.
0:15
Peki her bir düğmeyi, her bir pencereyi
0:18
tek kodlamadan bunu nasıl başarıyoruz?
0:21
İşte cevap görsel programlama dediğimiz
0:23
müthiş bir konsepte yatıyor. Özellikle
0:26
Winforms gibi sistemler sayesinde hazır
0:29
yapı taşlarını kullanarak o sıkıcı kod
0:31
yazma yükünden kurtuluyoruz. Yani bir
0:34
yanda satır satır kod yazmanın o yavaş
0:36
ve karmaşık dünyası var. Diğer yandaysa
0:39
işte Winforms'ın en büyük gücü sezgisel
0:42
sürükle bırak yaklaşımı. Bu sayede o
0:45
karmaşık kodlarla boğuşmak yerine
0:47
tamamen yaratıcılığınıza
0:48
odaklanabiliyorsunuz.
0:50
Gelin şimdi bu yaklaşımın detaylarına
0:52
birlikte bakalım. Bu yolculuğumuzda
0:55
Winforms'u beş ana başlıkta ele
0:57
alacağız. Önce temel kavramlar, sonra
0:59
form tasarımı ve kontroller, ardından
1:02
kullanıcı etkileşimi ve olaylar, veri
1:04
yönetimi ve son olarak da sistem
1:07
işlemleri ile bitireceğiz. Evet, ilk
1:09
durağımız temel kavramlar. Her şeyin
1:12
başladığı yer burası. Bir Winforms
1:14
uygulaması o gördüğümüz arayüzün
1:16
arkasında aslında nasıl bir mimariye
1:19
sahip? Gelin bu planı bir inceleyelim.
1:22
İşte WinForms'un en zekice
1:24
numaralarından biriyle tanışın. Partial
1:26
anahtar kelimesi. Peki bu ne işe
1:28
yarıyor? Aslında çok basit bir görevi
1:31
var. Uygulamanızın görünümünü oluşturan
1:33
kodlarla o görünüme hayat veren mantık
1:35
kodlarını birbirinden ayırıyor.
1:37
Düşünsenize bu sayede tasarımcı arayüzle
1:40
uğraşırken yazılımcı da arka plandaki
1:42
mantıkla ilgilenebiliyor. Kimse kimsenin
1:45
ayağına basmıyor. Oldukça akıllıca değil
1:47
mi? Bu ayrım pratikte tam olarak şöyle
1:50
görünüyor. İki ayrı dosyamız var ama
1:52
aslında tek bir form oluşturuyorlar.
1:55
Biri yani designer dosyası uygulamanızın
1:58
neye benzediğini söylüyor. Diğeri ise
2:00
sizin kod yazdığınız yer yani ne
2:03
yaptığını anlattığınız kısım. Program
2:05
derlendiğinde bu iki dosya sihirli bir
2:07
şekilde birleşip o gördüğümüz tek ve
2:09
bütün formu meydana getiriyor. Tıpkı bir
2:12
yapbuzun parçaları gibi. Peki teoriyi
2:14
biraz kenara bırakalım ve işin en
2:16
eğlenceli kısmına geçelim. Form tasarımı
2:18
ve kontroller yani arayüzümüzü
2:21
oluşturacağımız o yapı taşlarının olduğu
2:23
yere bizim meşhur araç kutumuza bir göz
2:25
atalım. Formunuza butonları, kutuları
2:29
rastgele serpiştirmek istemezsiniz,
2:31
değil mi? İşte burada table layout
2:33
panel, tool strip container gibi akıllı
2:36
düzen kontrolleri devreye giriyor.
2:38
Bunları birer konteyner gibi düşünün.
2:41
Görevleri içine koyduğunuz diğer
2:43
kontrolleri sizin için otomatik olarak
2:45
hizalamak, düzenlemek. Yani adeta
2:48
uygulamanızın iç mimarları gibi
2:49
çalışıyorlar ve her şeyin derli toplu
2:52
görünmesini sağlıyorlar. Tabii ki bir
2:54
arayüz sadece düzenden ibaret değil.
2:57
Asıl olay kullanıcıyla etkileşime
2:59
geçmekte. İşte Combox gibi açılır
3:02
listeler, statüs, trip gibi durum
3:04
çubukları veya listbox gibi listeler tam
3:07
da bu işe yarıyor. Bu temel kontroller
3:10
sayesinde uygulamanız artık sadece
3:12
statik bir resim olmaktan çıkıp yaşayan,
3:15
nefes alan interaktif bir deneyime
3:17
dönüşüyor. Harika bir tasarım yaptık
3:19
diyelim. Peki kullanıcı o butona
3:21
tıkladığında ne olacak? İşte bu noktada
3:24
kullanıcı etkileşimi ve olaylar konusuna
3:26
geliyoruz. Çünkü bir uygulama
3:28
kullanıcının hareketlerine tepki vermeye
3:30
başladığı an gerçekten canlanır. Bu
3:32
tepkileri yöneten şeye de olaylar
3:34
diyoruz. Mesela klavyede bir tuşa basmak
3:37
ne kadar basit bir eylem gibi görünüyor
3:39
değil mi? Ama aslında arka planda tam üç
3:42
aşamalı bir süreç işliyor. Önce tuşa
3:44
basıldığı an key down olayı
3:46
tetikleniyor. Eğer o tuş bir karakter
3:49
üretiyorsa ardından key press geliyor ve
3:51
son olarak parmağınızı tuştan
3:53
çektiğinizde keyup olayı gerçekleşiyor.
3:56
İşte bu sıralama hassas klavye
3:58
kontrolleri oluşturmak için hayati önem
4:00
taşıyor. Kullanıcı deneyimini
4:02
iyileştiren küçük ama çok güçlü bir
4:04
özellikten bahsedelim. Accept button.
4:07
Bir forma bir sürü bilgi girdikten sonra
4:09
fareyi bulup kaydet butonuna tıklamak
4:12
yerine sadece enter'a basıp geçmek ne
4:14
kadar pratik olurdu değil mi? İşte bu
4:16
özellik tam olarak bunu yapıyor. Formun
4:19
accept buttonına bir düğmeyi
4:20
atadığınızda enter tuşu artık o düğmenin
4:23
sihirli bir kısa yolu haline geliyor.
4:25
Şimdi de kodun nasıl karar verdiğine
4:28
bakalım. If yapısının çok temel bir
4:31
kuralı vardır. İlk doğru koşulu bulduğu
4:33
an durur. Bakın diyelim ki kullanıcı hem
4:36
kemanı hem gitarı hem de piyanoyu seçti.
4:39
Kod ilk koşulu kontrol ediyor. Keman ve
4:42
piyano mu seçili? Hayır. İkinci koşula
4:44
geçiyor. Keman ve gitar mı seçili? Evet.
4:48
İşte bu noktada ekrana dolar işaretini
4:50
basar ve anında durur. Piyanonun da
4:52
seçili olup olmadığıyla artık hiç
4:53
ilgilenmez. Bu kodun gereksiz kontroller
4:56
yapmasını önleyerek daha verimli
4:58
çalışmasını sağlar. Arayüzümüzü kurduk.
5:01
Kullanıcıyla etkileşime de geçtik. Şimdi
5:03
sırada ne var? Perde arkasına geçip veri
5:06
ve kaynak yönetimine bakma zamanı. Yani
5:09
kontrollerdeki verileri nasıl
5:11
alacağımıza ve daha da önemlisi işimiz
5:13
bittiğinde arkamızı nasıl
5:15
toplayacağımıza bakalım. Diyelim ki bir
5:18
açılır listeden yani Kamba Box'tan
5:20
kullanıcının ne seçtiğini öğrenmek
5:22
istiyoruz. Bu aslında üç adımlı bir
5:24
süreç. İlk olarak selected index'le
5:27
seçilen öğenin listedeki sırasını yani
5:30
index numarasını öğreniyoruz. Sonra bu
5:32
sıra numarasını kullanarak items
5:34
koleksiyonundan o öğenin kendisine
5:36
ulaşıyoruz ve son adımda da elde
5:39
ettiğimiz bu nesneyi dat to string ile
5:41
okunabilir bir metne çeviriyoruz. İşte
5:43
bu kadar. Bir metin kutusunu temizlemek
5:46
için iki komutumuz var ama aralarında
5:49
ince ama çok önemli bir fark var. Clear
5:52
komutu kutunun içindeki her şeyi siler
5:54
ve onu bomboş bırakır. Reset text ise
5:58
metni tasarım aşamasında ne
5:59
ayarladıysanız o ilk varsayılan haline
6:02
geri döndürür. Yani biri tamamen
6:04
sıfırlarken diğeri fabrika ayarlarına
6:06
dönüyor diyebiliriz. Bir formu
6:09
kapatmakla yok etmek arasında dağlar
6:11
kadar fark var. Close metodunu
6:13
çağırdığınızda form sadece gözden
6:15
kaybolur ama bellekte yaşamaya devam
6:17
edebilir. Tıpkı bir odanın ışığını
6:19
kapatmak gibi. Ama dispose ise çok daha
6:22
kesin bir işlem. O formun kullandığı
6:24
bütün sistem kaynaklarını yani bellek,
6:26
grafikler, ne varsa hepsini serbest
6:29
bırakır. Bu da ışığı kapatmak değil,
6:31
ampulü duvayla birlikte söküp atmak
6:33
gibi. İşte bu kaynak sızıntılarını
6:35
önlemek için yapmamız gereken en önemli
6:37
şey. Geldik son bölüme. Peki uygulamamız
6:41
kendi küçük dünyasından çıkıp dosya
6:43
açmak veya bir şeyler yazdırmak gibi
6:45
daha büyük işler için işletim sistemi
6:48
ile nasıl konuşur? İşte şimdi sistem
6:50
işlemlerine yani diyaloglara ve yazdırma
6:53
işlemlerine bakacağız. Bir dosya aç
6:56
penceresi veya bir renk seçici gibi
6:58
pencereleri show dialog komutuyla
7:00
gösteririz. Buradaki kilit kelime modal.
7:03
Modal demek şu anlama geliyor. Bu
7:06
diyalog penceresi açıldığında siz onu
7:08
kapatana kadar arkadaki ana uygulamaya
7:10
geri dönemezsiniz. Sizi bir seçim
7:13
yapmaya zorlar. Evet, hayır ya da iptal
7:15
demeden başka bir yere tıklayamazsınız.
7:18
İşte bu modal davranışın ta kendisi.
7:21
Yazdırma işlemi de benzer bir mantıkla
7:23
çalışır. Yazıcı seçme veya sayfa ayarı
7:25
yapma gibi pencereler olabilir ama asıl
7:27
işi yapan yani içeriği hazırlayıp sayfa
7:30
sayfa fiziksel yazıcıya gönderen temel
7:32
bir bileşen var. Print document.
7:34
Diğerleri sadece hazırlık yapar ama
7:36
gerçek yazdırma eyleminin kalbinde hep
7:38
bu bileşen yatar. Şöyle bir toparlayacak
7:41
olursak bugün ne gördük? WinForms'un
7:43
sürükle bırak modeliyle ne kadar hızlı
7:46
arayüz geliştirildiğini. partial
7:48
kelimesiyle tasarım ve mantık kodunun
7:50
nasıl ayırdığını, klavye olaylarının o
7:53
belirli sırasını ve belki de en önemlisi
7:56
dispose gibi komutlarla kaynak
7:58
yönetiminin ne kadar kritik olduğunu ve
8:00
print document gibi bileşenlerle
8:02
sistemle nasıl konuştuğunu öğrendik.
8:04
Bütün bunlar sağlam bir uygulamanın
8:06
temel taşları. Bütün bu yapı taşlarını
8:09
anladıktan sonra akla şu soru geliyor.
8:11
Görsel tasarım programlamayı gerçekten
8:14
de herkes için daha erişilebilir hale
8:16
getirmenin anahtarı mı? Winforms gibi
8:18
araçlar bu yolda büyük bir adımdı.
8:21
Girişteki o yüksek engelleri epey bir
8:23
aşağı çektiler. Peki sizce geleceğin
8:25
geliştirme araçları nasıl olacak? Belki
8:28
de bir gün kod yazmak sadece blokları
8:30
birleştirmek kadar basit bir hale gelir.
8:32
Ne dersiniz? Bu konu üzerine
8:34
düşündüğünüz için teşekkürler.

