MESSAGE, TROIA'da sandığınızdan daha fazlasını yapıyor

Çoğu dilde "kullanıcıya bir şey göster" ile "kullanıcıdan onay al" iki ayrı mekanizmadır. TROIA'da ikisi de tek bir komuta yaslanıyor: MESSAGE. Hangi davranışı göstereceği, verdiğiniz mesaj tipine bağlı — ve bu tipler arasındaki farkı bilmemek, "neden kullanıcının cevabı hep boş geliyor" gibi sorulara yol açabiliyor.

Temel sözdizimi

MESSAGE {modul} {mesajtipi}{mesajid} WITH {mesajmetniicinparametreler};

Mesajlar kod içine gömülmez, SYST02 - System Messages transaction'ında merkezi olarak tanımlanır ve çok dilli olabilir; metin içinde %s (ya da sıralı %s1, %s2) ile parametre yer tutucuları kullanılır. Basit bir çağrı şöyle görünür: MESSAGE BAS C100 WITH;

Altı mesaj tipi

Tip Kod Davranış
INFORMATION I Bilgi ikonu, tek "Tamam"
ERROR E Hata ikonu
WARNING W Uyarı ikonu
CONFIRMATION C Evet/Hayır sorusu
OPTION O Özel seçenekler
PARAMETER P Klavyeden kullanıcı girdisi

Kullanıcının cevabını okumak

CONFIRMATION, OPTION ya da PARAMETER tipi bir mesaj gösterdiyseniz, cevap otomatik olarak sistem değişkenlerine düşer:

  • CONFIRM: Onay mesajlarında 'YES'/'NO'; seçenek mesajlarında seçilen seçeneğin index'i.
  • SYS_CONFIRMTEXT: Seçilen seçeneğin metin karşılığı.
  • SYSMESSAGE: Hesaplanmış (parametreleri yerleşmiş) mesaj metni.

Gerçek bir örnek: silme öncesi onay almak

/* Kullanıcıya onay sorar, evet derse aktif satırı siler. */
MESSAGE BAS C205 WITH SIPARISLER_SIPARISNO;

IF CONFIRM == 'YES' THEN
    CLEAR ROW SIPARISLER;
    MESSAGE BAS I010 WITH;
ELSE
    RETURN;
ENDIF;

Buradaki C205 mesajının, SYST02'de "Sipariş %s'i silmek istediğinize emin misiniz?" gibi tanımlanmış olduğunu ve SIPARISLER_SIPARISNO'nun %s yerine geçtiğini varsayıyorum.

Batch ve database transaction'larda davranış farkı

İki senaryoda MESSAGE'ın davranışı normal (interaktif) kullanımdan farklı işliyor:

  • Batch/INSERVER transaction'lar: Kullanıcı ekranda olmadığı için sistem mesajları otomatik cevaplıyor — tüm onaylar YES kabul edilir, seçenekler varsayılan değerle geçilir, ve mesajlar IASBATCHERR tablosuna kaydedilir. Yani bir batch transaction'da MESSAGE ... TYPE CONFIRMATION yazıp "kullanıcı hayır derse dur" mantığı kurmak işe yaramaz — kimse soruyu görmez, sistem otomatik evet der.
  • BEGINTRAN-COMMITTRAN blokları: Blok içindeki mesajlar transaction kapanana kadar beklemede kalır, transaction bittikten sonra istemciye bilgi mesajı olarak gönderilir ve SYSBATCHMESSAGES tablo tipi değişkende toplanır.

Sık yapılan hatalar

  • Batch transaction'da kullanıcı onayına dayalı akış kurmak — yukarıda belirttiğim gibi, batch modda tüm onaylar otomatik YES döner; kritik bir silme işlemini sadece MESSAGE ... CONFIRMATION ile korumaya çalışmak, batch'te güvenlik sağlamaz. Gerçek bir yetki/durum kontrolü koda ayrıca eklenmelidir.
  • CONFIRM değişkenini bir önceki mesajdan kalan değerle karıştırmak — art arda birden fazla MESSAGE çağırıyorsanız, her çağrıdan hemen sonra CONFIRM'i okuyup ilgili değişkene aktarmadan bir sonraki mesajı göstermek, hangi cevabın hangi soruya ait olduğunu karıştırabilir.
  • Parametre sayısını mesaj tanımıyla eşleştirmemek — SYST02'deki mesaj metninde iki %s varsa ama WITH ile tek parametre gönderilirse, sonuç eksik ya da hatalı görüntülenen bir metindir; yeni bir mesaj tanımlarken WITH listesini mesaj metniyle birlikte gözden geçirin.

Sıradaki adım

MESSAGE'ın interaktif diyalog tarafını gördük; bir sonraki yazıda PUSHNOTIFICATION komutunun bundan tam olarak nasıl ayrıştığına (kullanıcı etkileşimi beklemeyen, arka planda bildirim gönderen bir mekanizma olarak) değineceğim.