Şöyleki;
Başlanğıçta ANAMAKINA değişkeni C:\PROJE iken clint makinalarda bir dbf dosyasından okuyacak ve mesala \\SUNUCU\C\PROJE şeklinde (dbf dosyasını update edecek kodlar mevcut) değiştirmek mümkün. Böylece projede ANAMAKINA değişkeni ile oluşturduğum path ler artık \\SUNUCU\C\PROJE şeklinde çalışmaya başlıyor.
Set Filter'in hiz problemini VFP9'da halletmisler. Gene de kullanmiyorum. Kullanmak icin bir nedenim oldugunda dusunurum:)
]]>2) VFP7 ve sonrasinda eger bir tablo gecerli workarea'da aciksa ve loop varsa performans kotu etkileniyor.
2'yi farketmek zor. 1 ana neden ve oldugunda yeni baslayanlarin yakalamakta cok zorlanacagi bir hata (farkedilmesi bile dert).
hocam loop daki kasdiniz scan all,do while, for next mi?
performs kötüdeki kastiniz hız mı?
birde bir yazınızda okumuştum set filter karşıtıydınız, set filter hız perfonsını kötü yönde etkiler mi?
]]>set filter to (xfilt)
xfilt değişkeninin bulunmadığı procedurelerde hata veriyor.
private data session bir formdaysanız onun yerine şu da olabilir:
set filt to (_screen.activeform.my_filt)
bilmiyorum vfp'de de hala öyle mi. foxpro dos ta & kullanılan satırları foxpro tamamen karakter olarak saklıyordu .EXE içinde.
mesela set talk &xtalk
diye bir satır olsun. o satırı tamamen saklıyordu.
SqlStr="select * from "+YOL+"personel"
gibi
Public tehlikeli. VFP'de event driven bir ortam var. Yukaridan asagi akip giden prosedural kod olmadigindan public degiskeni kimin ne zaman degistirdigini bilemezsin.
Hic public kulanmamak en iyisi ama en azindan sadece oApp'i public yaparak alani sinirliyorsun. Ne yaptigini iyi bilen birisi pekala N tane publicle de calisabilir. Uyari yeni baslayanlar icin. Sonra ona bagli hatalari aranip durmasinlar diye.
use &tbl gibi kodlar cok basit kirilabilir. Ornegin:
yol = 'c:\Benim dosyalar\Data\'
tbl = m.yol + 'personel'
use &tbl
ile Foxpro:
use c:\Benim Dosyalar\Data\personel
seklinde kod algilar ve hataya neden olur. Bu daha dogru olurdu:
use "&tbl"
Hic olmazsa acildiginda:
use "c:\Benim Dosyalar\Data\personel"
olacagindan calisir.
m. Kullanmak foxpro'da zorlanmiyor ama kullanmayinca:
1) Field degiskenler oncelik aldigindan dusundugunden baska bir sey kullaniyor olabilirsin.
2) VFP7 ve sonrasinda eger bir tablo gecerli workarea'da aciksa ve loop varsa performans kotu etkileniyor.
2'yi farketmek zor. 1 ana neden ve oldugunda yeni baslayanlarin yakalamakta cok zorlanacagi bir hata (farkedilmesi bile dert).
]]>tbl = yol+'personel'
Use &tbl
allerjim olan kodlardan bir digeri.
tbl = addbs(m.yol) + 'personel'
use (m.tbl)
Umarim gelir gelmez negatif bir mesaj aliyormus gibi hissetmezsin, oyle bir niyetim yok. Sadece diger kullanimlarla olabileck sorunlardan dersini almis birinin onerisi olarak bak.
Not: Ben de senin gibi foxbase,foxpro ... 'dan geldim:)
Her public ve & gordugumde mudahale etmeme forumdakiler alisti:) Onlarin hosgorusune siginiyorum.
Tekrar hosgeldin.
]]>PUBLIC YOL
YOL="C:\PRGKLS\DATA\"
kullanırken
TBL=YOL+"PERSONEL"
USE &TBL
ile kullanabilirsin.
Böylece değiştirmen gerektiğinde tek bir noktada değiştirmen yeterli olur.
Ayrıca bu yolu bir tabloda tutup proğramı tekrar Compile etmene gerek kalmadan çalışırkende değiştirebilirsin.
]]>Not: Dizini girip elle degistiriyorsan degisken kullanmamissin demektir. Degisken kullan tek bir yerde degistir (degisken derken bir dosyadaki #define da dahil). Ornegin:
* sabitler.h
#define REPORTPATH addbs(oApp.ApplicationPath)+'raporlar'
Ya da:
oApp.RaporDizini
oApp senin main.prg'de yaratilan custom bir class ve public (VFP'de kullanman gereken tek public):
* Main.prg
* ....
public oApp
oApp = createobject("MyApp")
* ...
define class myApp as Custom
RaporDizini = ''
* ...
enddefine
Daha pratik bir öneri var mı ?
sevgiler