Régi probléma: a módosított rekord kiírásának kikényszerítése. Megoldás?

[Tisch Dávid]

Sziasztok!

A minap ismét belefutottam egy régóta ismert problémába és néhány órát
elszórakoztam vele, azt feladtam. Ez a probléma pedig a módosított
rekord kikényszerített kiírása volt. Ebben kérném a segítségeteket!

Régen, ha egy rekordon álltunk, amit pl. ki kellett volna nyomtatni,
akkor kiadtunk egy KbPut CTRL+M-et, aztán nyomtattunk. Ma, ebben a szép,
új, event központú világban ez egy megoldhatatlan probléma. Mert ugyan
van egy Fetch Record event, amit ki lehet váltani a nyomtatás előtt, de
akár Wait:yes-szel, akár Wait:no-val hívjuk ezt meg, a hatása nem
érvényesül az altaszk hívása előtt. Ugyanez igaz a View refresh, Modify
records, ... eseményekre is.

A valódi, korrekt megoldás egy callback függvény vagy egy "Event
completed" event lenne, ami esetleg azt is megmondhatná, hogy melyik
kontrolon kiváltott melyik esemény terminált éppen, és azt lehetne ilyen
dolgokra használni. Ennek hiányában most megy a gányolás: kilépés előtét
taszkba, aztán újra visszalépés, stb.

Nektek van erre valami bevett megoldásotok? Esetleg MSE nem tervezi a
fent említett megoldás implementálását? C#, JavaScript környezetben
bevált. Nem szégyen tanulni a konkurenciától. ;)

Előre is köszi a választ!
Üdv:

Dávid

[Bakos Gyula]

Szia Dávid,

Ctrl+U User events-ben nézd meg a Force Exit=Post Record Update-et!
Az pont erre való!

Üdv: Gyula

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok szolgáltatásbeli Magic Support Levelezőlista csoportra.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) magic-suppor...@googlegroups.com címre.
Ha üzenetet szeretne küldeni ebbe a csoportba, küldjön egy e-mailt a(z) magic-...@googlegroups.com címre.
A csoportot a(z) https://groups.google.com/group/magic-support címen keresheti fel.
További lehetőségekért látogasson el a(z) https://groups.google.com/d/optout címre.

[Tisch Dávid]

Szia Gyula!

Köszönöm a választ! Megnéztem ezt a Force Exit-es dolgot és ki is fogom
próbálni. Ennek valóban működnie kéne. Annak mi az oka vajon, hogy belső
eseményeknél nincsen ez a Force Exit tulajdonság?

Belső eseményekkel egyébként megoldható ez a probléma? Ha nem, akkor mi
a fenének van ez a Record Flush esemény? A helpben ez van: "Instead of
explicitly calling Record Flush, you can also use a User Event with a
Force Exit of “Post Record Update”. This forces the current record to be
written before the event is executed." Nekem ez az "explicitly calling
Record Flush" nem jön sehogy se össze.

Előre is köszi a választ! Üdv:

Dávid

[Bakos Gyula]

Szia!

A Record Flush egy + esemény küldésével oldja meg (próbálja megoldani) a problémát, míg a Force Exit nem jár + esemény küldésével. Ez szerintem egy nagy előny a Force Exit javára, így én ha csak lehet ezt használom.
Az a tapasztalatom ugyanis, hogy a sok esemény egymás utáni küldözgetése kicsit bizonytalanná teszi a végrehajtást. Pl. nem világos, hogy a Raise Event Wait=Yes -el mikor hajtódik végre és mikor nem. Nekem általában nem. De ugyanígy előfordult, hogy ha RIA taszk hívása is volt egy eseménykezelőben, akkor a Raise Event-tel küldött esemény a RIA taszkban került feldolgozásra, holott nem ott kellett volna.
Próbáld ki a Force Exit-et, és ha csak lehet, használd azt!

Üdv: Gyula


-----Original Message-----
From: magic-...@googlegroups.com [mailto:magic-...@googlegroups.com] On Behalf Of Tisch Dávid

[Tisch Dávid]

Szia Gyula!

Köszönöm, mindenképpen ezt a Force Exit-et fogom ezentúl használni!

Örülök, hogy lett egyáltalán megoldás a problémára, de - Hozzád
hasonlóan - továbbra is fenntartom az első levelemben írt véleményemet,
miszerint ez az esemény vezérelt működés Magicben nagyon felemásan lett
megvalósítva. Az Általad is említett "wait" tulajdonság - értelmezésem
szerint - a szinkron (yes) és aszinkron (no) végrehajtást lenne hivatott
szabályozni, de ez egyáltalán nincs így. Wait=yes esetben éppúgy
"valamikor" hajtódik végre az esemény, mint Wait=no esetén. Ennek
rendesen kéne működnie. Ezen kívül pedig mindenképpen szükség lenne
olyan meta eseményekre, amiket korábban már említettem (pl. egy belső
(internal) esemény kezelése befejeződött), valamint plusz belső
eseményekre (pl. "subformhoz tartozó program/taszk meghívása").

Ez 3-asban pont ilyen, mint uniPaaS 1.9-ben?

Üdv:

Dávid

[Bakos Gyula]

Szia,

A Wait = Yes nekem általában nem is hajtódik végre, így nem is bosszantom vele magamat, nem használom...

xpa 3.x-ben még nem próbáltuk, de remélem, jobb lesz...

Üdv : Gyula

-----Original Message-----
From: magic-...@googlegroups.com [mailto:magic-...@googlegroups.com] On Behalf Of Tisch Dávid
Sent: Monday, January 18, 2016 10:55 AM
To: magic-...@googlegroups.com
Subject: Re: [Magic Support] Régi probléma: a módosított rekord kiírásának kikényszerítése. Megoldás?

[sws...@anonym.hu]

Sziasztok!

Bocsánat, hogy ezt mondom, de véleményem szerint az esetek 99%-ában, ha
mentés kikényszerítésére van szükség, akkor nincs jól szervezve a program.
Mi az a folyamat, aminek az a következménye, hogy ugyanazon a fizikai
rekordon állok, amit a felhasználó módosított, és anélkül, hogy elhagynám
el kell mentsem (termináljam a rekordot), és még egy plusz műveletet végre
kell hajtsak? Nem azt mondom, hogy nincs ilyen hanem, hogy alapvetően
ritka. Na most akkor erre a ritkaságra koncentráljunk:
1, Kezdő magic-esként én is mindig megpróbáltam a felvitelt, módosítást,
lekérdezést egy taszkban megcsinálni, fizikai mezőkkel. A hosszú évek során
be kellett, hogy lássam, hogy - akármennyire is kevesebb munkának tűnik az
elején - nem igazán járható út, és a végén sokkal több munkával jár.
Egyrészt mivel sajnos a Magic hibásan működik több adatbázis kezelő
esetében (hiba leadva az MSE-nek és javításra vár). Bizonyos esetekben
akkor is nyit tranzakciót és lockol, amikor egy bevitel/módosító taszkot
lekérdezésre használunk. Ez nagy rendszer esetén óriási gond. Ezért
túlnyomó többségben külön módosító és külön megtekintő programokat kezdtünk
írni. A másik kapcsolódó probléma, hogy Marika néni el kezd módosítani
valamilyen alapadatot, majd elmegy kávézni. A harmadik a RIA-s és mobilos
alkalmazások alapvető működési különbsége, hogy nem a kliens nyúl el az
adatbáziskezelőhöz, hanem az alkalmazás szerver. Mindhárom abba az irányba
nyom minket, hogy a lekérdező programok maradjanak fizikaiak, de a
módosítóknál külön (pl. altaszkban) lekérdezzük az adatokat, feltöltsünk
virtuálisokat, majd módosításkor (pl. altaszkban) mentsük az eredményt.
Ráadásul ha így csináljuk, akkor nincs is szükség módosítás
kényszerítésére.
2, View Refresh event. Ha ezt kiadjuk, a módosítások (ha érintették az
adatnézetet) elmentésre kerülnek, majd az adatnézet újraolvasásra kerül.
Ráadásul van egy nagyon használható paramétere, érdemes átböngészni.
Szerintem ez az egyik legjobb megoldás.
3, Exit event. Ha lehet a programot úgy szervezni, akkor megcsinálhatjuk,
hogy a módosítás után kiadunk egy Exit parancsot. Ez biztosan menti a
módosítást. Persze kilép a taszkból, amit úgy tudunk kivédeni, hogy van
fölötte egy másik és visszazavarjuk. Ha az ablak nyitva marad, vagy
subformot haszálunk és visszaállunk ugyanarra a rekordra, fent előre
nyitunk minden táblát, és rezidens az altaszk, akkor ez általában nem is
zavaró. Ez is egy elég tiszta megoldás.
4, Force Exit event. Gyula szépen leírta, csak annyit akarok hozzáfűzni,
hogy a hangsúly az események láncolásán van, lásd később. Ritkán
használjuk. A fenti három biztosabb.
5, Record Flush event. Elvben pont azt csinálja amit szeretnénk.
Gyakorlatilag hibás volt még az 1.9-ben is, valahol a 2.x környékén lett
egy kicsit jobb, de időnként nem működik, pl. eseményből hívva bizonyos
esetekben, ha altaszkból is módosítottunk a felette levő taszkból valamit,
meg valami bizonytalan, számomra nem körülhatárolható esetekben. Kerüljük
ahol csak lehet.

Események:
1, A Wait=Yes valójában úgy működik mint a Call. Azt jelenti, hogy a
végrehajtás ott megáll, végrehajtja az eseményt (mint egy szubrutint) és
visszatér. Belső (internal) esemény nem lehet ilyen!!!
2, A Wait=No azt jelenti, hogy az Event Queue-ba bekerül az esemény és
majd ha odakerül a feldolgozás, akkor végrehajtja. Mikor van ez?
Általánosságban azt lehet mondani, hogy Online taszk rekord prefix
végrehajtása után, amikor a felhasználóra várunk. Belső esemény csak ilyen
lehet!
3, Ha saját eseményeket belső eseményekkel keverünk, és/vagy láncoljuk az
eseményeket, akkor mindegyiket vegyük Wait=No-ra. Így teljesen kiszámítható
lesz a működés. Nyilván azzal számolni kell, hogy ez csak a legközelebbi
"idle time" esetén lesz végrehajtva. Viszont legalább egy kötegben.
4, A fentiek alapján kijelenthetjük, hogy kb. 10%-ban van értelme a
Wait=Yes használatának. A többi esetben a Call, vagy függvény használata
szebb, átláthatóbb megoldás ad.

Esemény láncolás példa:
El akarom menteni az adatnézetet, csinálni valamit, majd kilépni. Mindezt
ugye egy Online taszkban, adatbevitel közben, miután Marika néni
rákattintott a Rendben gombra.

a)
Raise Event View Refresh Wait=No
Raise Event Saját event Wait=Yes
Raise Event Quit Wait=No

b)
Raise Event View Refresh Wait=No
Raise Event Saját event Wait=No
Raise Event Quit Wait=No

Az a) esetben a View Refresh bekerül az Event Queue-ba, majd végrehajtódik
a Saját esemény, majd a Quit bekerül az Event Queue-ba, majd ha Marika néni
nem csinál közben valami nagy disznóságot, megkezdődik az Event Queue
feldolgozása, végrehajtódik az adatnézet frissítés (ekkor mentődnek a
változások), majd kilép a taszkból.

A b) esetben View Refresh, majd a Saját eseményem, majd a kilépés esemény
mind bekerülnek az Event Queue-ba, majd (ha Marika néni nem...) megkezdődik
a feldolgozása, tehát frissül az adatnézet (mentés), saját esemény elindul,
és végül kilép a taszk.

A a) esetben a Saját eseményem után lett mentve a módosítás a b) esetben
előtte. Elég komoly a különbség.

Dióhéjban ennyi. Bocs ha kicsit szájbarágósra sikeredett, de hátha olvassa
kezdő Magic-es is. :-)

Ámor



On Mon, 18 Jan 2016 11:02:32 +0100, "Bakos Gyula"
<bakos...@szegedsw.hu>
wrote:

[Tisch Dávid]

Szia Ámor!

Köszi a részletes választ!

1. Azt szeretném kérdezni, hogy ezt a "virtuális feltöltős, módosító
programos" mókát form típusú módosító képernyőkön használjátok csak,
vagy lista típusúaknál is, mondjuk ideiglenes táblával? (Egyébként
persze a módosítások mentését ilyenkor is ki kell "kényszeríteni",
mondjuk - ahogy írod - egy altaszk hívással, csak az szinkron módon fut
le és a kezedben van teljesen a végrehajtása. Na, én ilyen fajta
kontrollt látnék szívesen a belső eseményekre is!)

2. A View Refresh nekem is kedvencem, de az általam írt, kiélezett
esetekben - az aszinkron lefutás (wait=no) miatt - ugyanúgy nem jó.

3. Ezt a "batch előtét taszkos online program"trükköt is több helyen
használjuk, de én személy szerint elég csúnya workaroundnak tartom.
Ráadásul úgy hallottam, hogy az ilyen konstrukciók a RIA-s
alkalmazásoknál nem megengedettek. Igaz ez?

Köszi, hogy összefoglaltad a Wait paraméter működési elvét! Remélem,
segítség lesz sokaknak! Én tudtam, hogy ez elvben így működik, de azt
nem értem, hogy ha szerinted internal event nem állhat wait=yes-szel,
akkor mi a fenének lehet úgy beállítani? Vagy hol van leírva, hogy nincs
értelme így beállítani? Mert én is azt tapasztaltam, hogy sosem
viselkedik szinkron módon, bármire is állítom. Én éppen ezt hiányolom a
Magicből: a szinkron lefutású internal eventeket, vagy annak
elehetőségét, hogy tudjam, hogy az event queue-ból mikor került ki, amit
beletettem.

Üdv:

Dávid

[sws...@anonym.hu]

Hi!

1. Nagyon ritkán. A túlnyomó többségben van egy soros (listás) lekérdező
taszk, amihez kapcsolódik egy képernyős módosító. Soros módosítók csak
akkor ha egyszerűek, kevés mezőből állnak, és a táblázat kifér egy
képernyőn.
Van egy két esetben, hogy temporary-s DB vagy memory táblát használunk és
abba felolvassuk a rekordokat, de azok sohase módosítók. (Mobilon kliens
oldali táblák, de az totál más.)

2. Ezt nem értem, hogy miért nem jó. Visszaolvastam amit írtál és az
alapján a View Refresh egy tökéletes megoldás. Ha jól értelmezem a
felhasználó módosít valamit, majd a Nyomtatás gombra kattint.? De szólj, ha
rosszul értettem! Ha igen, hát fel kell venni két eseményt, legyen a nevük
Nyomtatás_gomb és Nyomtatás_tényleges. A Nyomtatás_gomb van hozzá kötve a
gombhoz és ezt a két sort tartalmazza:

Raise Event View Refresh Wait=No

Raise Event Nyomtatás_tényleges Wait=No
A Nyomtatás_tényleges esemény pedig csak egy Call-t tartalmaz a nyomtató
altaszkra.

3. Én kevésbé gondolom workaroundnak, sok más előnye is tud lenni:
programra nézve globális változók, a tényleges taszk előtt és utána
végrehajtandó feladatok pl. ami az adatnézetre (tartomány, filter) is
hatással vannak, előnyitott táblák, stb.
Subformmal meg RIA-n. Mobil az teljesen más tészta, de erre egy levél se
elég. :-)


Tökéletesen igazad van, ezer sebből vérzik az egész, bár rengeteg hasonló
van ilyen Magicben. Csomó tényleg nincs leírva, de ez speciel igen:
Home > Reference Guide > Logic Editor > Operations > Raise Event > Raise
Event Properties > Wait
"...
Note: Internal event types should be raised asynchronously. If you want to
raise an Internal event and to have the internal handling take effect, you
should make sure that the Wait property is set to No. If you set this
property to Yes, internal handling for these events is not executed.
..."


Ámor



On Mon, 18 Jan 2016 14:53:23 +0100, Tisch Dávid <ti...@drpinterkft.hu>
wrote:

[Tisch Dávid]

Szia Ámor!

Köszi a választ!

2. Így értem. A "nem jót" arra értettem, hogy egy esemény kezelőjében
van egy raise event és egy call. Te viszont ezzel a megoldással
tulajdonképpen "megírtad" az "event processed" eseményt, amit én is
hiányoltam. Cseles. :)
Az, hogy az egymás után kiadott, aszinkron eventek garantáltan egyesével
és egymás után kerülnek feldolgozásra, az tuti? Mert én eddig azért is
nem írtam olyan megoldást, amit javasolsz, mert azt gondoltam, hogy nem
definiált a végrehajtási sorrend.

4. Köszi az idézetet! Az mi a túrót jelent, hogy egy belső esemény belső
feldolgozása nem történik meg? (Utolsó mondat.) Az, hogy nem csinál
semmit? Akkor miért lehet állítani a wait propertyt??

Üdv:

Dávid