| |
 Anzeigen |
|
|
| Social Bookmark Script |
|
|
|
  |
 Paralleler Datenzugriff bei Dialogen |
exli2 
Mitglied
Dabei seit: 02.12.2009
Beiträge: 37
Einsatzart von VDF: gewerblich
Anwenderstatus: Newbie
Herkunft: Berliner Gegend
Betriebssystem: XP
 |
|
| Paralleler Datenzugriff bei Dialogen |
     |
Hallo, folgendes Problem: In einer meiner Anwendungen erscheint ein Dialog mit gefilterten Daten in einer dBGrid. In der aufrufenden View sollen die ausführlichen Datensätze beim Navigieren in der Dialog-Grid gleich mit angezeigt werden, also beim Wechsel des record in der Grid soll der Wechsel in der View ebenfalls sofort erfolgen ohne den Dialog zu verlassen.
Vielleicht habe ich ja auch nur einen Hänger...den dann aber schon lange.
Hat jemand eine Idee?
__________________
Programme sind nur so gut, wie das Zusammenspiel der Synapsen des Entwicklers.
|
|
02.12.2009 10:16 |
|
|
HerbertLewandoske
Grünschnabel
Dabei seit: 20.04.2009
Beiträge: 8
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Ebenfeld
Betriebssystem: Windows 7
|
|
Da fallen mir zwei Möglichkeiten ein:
a) Du benutzt in beiden Views das gleiche DD - also in der zweiten View "use (xx_DD(View1(Self))"
b) Du sendet im dbGrid nach jedem Zeilenwechsel ein refresh an die zweite View. Dafür muss in der zweiten View der "View_Latch_State auf on gesetzt sein.
Viele Grüße
Herbert
|
|
|
02.12.2009 12:07 |
|
|
exli2
Mitglied
Dabei seit: 02.12.2009
Beiträge: 37
Einsatzart von VDF: gewerblich
Anwenderstatus: Newbie
Herkunft: Berliner Gegend
Betriebssystem: XP
Themenstarter 
|
|
Erstmal Danke für die schnelle Antwort. Variante 2 hatte ich schon getestet, beim Scrollen durch die Grid wird ein refresh an das entsprechende Feld der View gesendet, dort auch aktualisiert, aber der Rest der View bleibt leer, so als wäre der Find nicht ausgeführt worden. Der View_latch_state ist standardmäßig auf true.
Variante1 verstehe ich nicht ganz; xx_dd wird in View und Dialog verwendet, oder wie soll ich das verstehen? wenn ich mit use die xx_dd aus der View anspreche, gibt´s ne Fehlermeldung, einmal Prüfungsfehler und ein "..bereits definiert". Schon wieder Denkfehler?
Gruß
Andreas
__________________
Programme sind nur so gut, wie das Zusammenspiel der Synapsen des Entwicklers.
|
|
|
02.12.2009 20:26 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Hallo
Habs noch nicht ganz verstanden, wie die 2 Fenster definiert sind:
Von welcher Klasse ist das aufrufende Fenster (dbVIew?)?
Von welcher Klasse ist das aufgerufene Fenster, also das mit dem dbGrid ?
Und wie rufst Du das Fenster mit dem dbGrid auf (Activate? Popup?)
Wenn Du einem "Fenster" einen andere Datensatz unterschieben willst, so kannst Du das mit find_by_recnum/rowid bewerkstelligen (direkt an das betroffene DD senden). Dann werden die DEO (Eingabedatenfelder) automatisch aktualisiert.
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
05.12.2009 22:36 |
|
|
exli2
Mitglied
Dabei seit: 02.12.2009
Beiträge: 37
Einsatzart von VDF: gewerblich
Anwenderstatus: Newbie
Herkunft: Berliner Gegend
Betriebssystem: XP
Themenstarter
|
|
Hallo, danke für die Rückmeldung.
Aus einer dBView wird mit activate ein (Filter)Dialog aufgerufen, der u.a. eine dBGrid mit gefilterten Daten der dd wie in der View enthält. Beim Zeilenwechsel in dieser Grid soll der komplette Datensatz in der View, die gerade nicht den Focus hat dargestellt werden, also Scrollen in der Dialog- Grid soll ein Aktualisieren der View zur Folge haben. Beim Zeilenwechsel sende ich ein refresh an die View (in diesem Fall Auftragsnummer). In der View ändert sich auch dieses eine Feld, aber der Rest der View bleibt leer. Erst beim Deaktivieren des Dialogs und Drücken von F9 werden die Daten in die View eingelesen. Ein Senden des find (also wie F9) vor dem refresh hat auch keine Auswirkung in der View. Und damit komme ich nicht ganz klar...
__________________
Programme sind nur so gut, wie das Zusammenspiel der Synapsen des Entwicklers.
|
|
|
07.12.2009 11:58 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Habe noch weitere Fragen (hoffe kann Dir auch mal ne Antwort geben 
)
Und wie stellst Du fest, dass in der Grid die Zeile gewechselt wurde?
Würde eine dbList (readOnly Grid) anstelle einer dbGrid (rw) nicht auch schon reichen?
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
07.12.2009 16:50 |
|
|
exli2
Mitglied
Dabei seit: 02.12.2009
Beiträge: 37
Einsatzart von VDF: gewerblich
Anwenderstatus: Newbie
Herkunft: Berliner Gegend
Betriebssystem: XP
Themenstarter
|
|
Schön, dass es solche Helfer gibt! So, folgendes: Natürlich hätte es eine dbList auch getan, aber ich aber die dbGrid auf ReadOnly gesetzt, passieren kann da nichts. Der Wechsel der Zeile wird durch die column_entry_msg erfasst, und beim Wechsel ein refresh an das entsprechende Feld der dbView gesendet, also Wechsel in col Auftragsnummer ändert auch Feld Auftragsnummer in der View.
So siehts in der Testumgebung aus:
set column_entry_msg item 0 to Sprung
Procedure Sprung
send refresh to (auftrag_auftragnr(c2(oAuftrag(self))))
End_Procedure
Und das klappt bis auf die vollständige Darstellung des Datensatzes in der View, während ich in der Grid scrolle. Der Sprung in der Grid (also in den Datensätzen) ergibt den entsprechenden Wert der Spalte (der Grid) in der View.
Erst wenn der Dialog zu ist, und die übliche Taste F9 gedrückt wird, werden die Felder der View mit dem der Auftragsnummer entsprechenden Datensatzn gefüllt. So ganz schlüssig ist mir dieses Verhalten nicht, da mit dem Refresh ja auch find ausgeführt wurde...und der Datensatzpuffer ja eigentlich genau diesen Datensatz enthält, der in der Grid markiert ist.
Ich hänge mal ein Bildchen hieran.
Gruß
Andreas
exli2 hat dieses Bild (verkleinerte Version) angehängt:
__________________
Programme sind nur so gut, wie das Zusammenspiel der Synapsen des Entwicklers.
|
|
|
07.12.2009 19:53 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Hallo
ein Programm sagt mehr als Worte. Habe mal runmgespielt (ja das muss man auch noch nach 15 Jahren VDF Programmierung) und Dir einen Lösungsansatz. Ich habe dazu das Order Entry Beispiel genommen. Als Anhang findest Du die Filter View. Im Order.Vw selber must Du noch folgendes hinzufügen:
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
|
use orderFilter.vw // Im Anhang heisst das File orderFilter.txt
... und weiter unten innerhalb des Objektes oDbContainer3d1 den Button für den
Aufruf des Filters...
Object oFilterBT is a Button
Set Location to 19 255
Set Label to "zeige Filter"
Procedure OnClick
Handle hoClient
Get Client_Id to hoClient
Send Activate_oOrderFilter of hoClient
End_Procedure
End_Object
|
|
Das Grundproblem mit dem Zuweisen eines Records an ein DD ist, dass dies nur geht, wenn der sogennate operation_mode = 0 (debugger anwerfen und diese globale variable überwachen!) ist. Das heisst, wenn keine andere Data Dictionary funktion im Gange ist. Deshalb entfallen die "New_Current_Record" Ansätze im DataDictionary. Dein Ansatz, mit dem Column_Entry, habe ich nicht probiert, denke aber, dass er auch funzt.
Die "natürliche" Funktion scheint aber row_changing zu sein.
HTH, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
08.12.2009 10:34 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Freut mich
Ich rate Dir: Benutze wieder das current_record. Arbeite nicht auf Buffer Ebene (Auftrag.recnum). Du weisst NIE was im Buffer steht. Du hast GENAU EINEN Auftrag Buffer, der aber vom X Auftrag_DD benutzt wird um die Daten zu holen/sichern. In Deinem Fall ists vermutlich so, dass mit an Sicherheit grenzender Wahrscheinlichkeit der Wert in Auftrag.recnum korrekt ist. Wenn immer möglich solltest du auf das DD Objekt zugreifen.
Operation Mode ist eigentlich ein Flag, das einerseits besagt ob eine DataDictionary operation am laufen ist (>0) und wenn ja welche. Aus technischen Gründen (z.B. da es pro Table nur einen Buffer gibt) ist es nicht möglich 2 oder mehr DD Operationen gleichzeitig auszuführen. darum ist es nicht möglich einen find_by_recnum aus new_current_Record aufzurufen resp. die Methode wird einfach nicht ausgeführt.
Vor und nach dem Row_Changing ist noch keine DD operation aktiv und deshalb gehts. Während dem Row_Chaging (im Forward drinnen) wird die eigentliche DD operation ausgeführt.
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
08.12.2009 15:26 |
|
|
exli2
Mitglied
Dabei seit: 02.12.2009
Beiträge: 37
Einsatzart von VDF: gewerblich
Anwenderstatus: Newbie
Herkunft: Berliner Gegend
Betriebssystem: XP
Themenstarter
|
|
In dieser Anwendung ist in der Tat die Wahrscheinlichkeit, daß im Buffer etwas anderes steht sehr gering, es wird hier keine Zugriffe anderer Nutzer geben. Allerdings bekomme ich mit dieser Variante die Fehlermeldung "undefinierte Objektreferenz"
Send DoAssingCallingView to (current_record(auftrag_DD(oAuftrag(self))))
Daher habe ich dann den recnum verwendet. Wenn ich Dich richtig verstanden habe ist der operation_mode genau in dem Moment des Forward größer 0 und dann geht nichts anderes?!
Ich verwende ebenfalls auftragsmäßig seit mehreren Jahren VDF, angefangen mit 5.0 und jetzt bei 11, aber so richtig glücklich bin ich mit den Funktionsübersichten bzw. Erklärungen vor allem in Englisch nicht. Teilweise geht auch manches verloren, weil man zwischen den einzelnen Klassenerklärungen (und der VDF- Versionen) hin und her springen muß, um den (funktions) Überblick zu bekommen. Und leider ist die deutschsprachige Gemeinde etwas klein, aber VDF in meinen Augen streckenweise genial.
Gibt´s noch Hilfen außerhalb dieser Foren? Habe nämlich noch so einiges vor...
Gruß
Andreas
__________________
Programme sind nur so gut, wie das Zusammenspiel der Synapsen des Entwicklers.
|
|
|
08.12.2009 17:17 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Hallo
Ich denke Du hast das ganze etwas anders angewendet.
In meinem Beispiel war die Funktion DoAssignCallignView im View mit dem Grid definiert. Die Aufgabe dieser Funktion war, dem Aufrufenden View, dem korrekten DD den gewünschten Record aufzuzwingen. Die Funktion besteht aus rein praktischen Gründen, denn damit konnte ich innerhalb des Views mit dem Grid einfach die Funktion aufrufen und die gewünschte Recnum mitgeben und im aufrufenden View wurde der korrekte Datensatz angezeigt (praktisch wenn man verschiednene Lösungsvarianten prüfen will).
Betreffend Operation_Mode: Setze im Debugger in der Row_Changing Funktion einen Breakpoint und für operation_mode als watched variable hinzu. Steppe durch den Debugger (immer schön F11 drücken) und verfolge was passiert. Im Moment des Forward ist er immer noch 0. Aber irgendwann, ganz tief in der Verschachtelung wird dann irgend ein Find oder so aufgerufen und dann ist auch der Wert nicht mehr = 0.
Habe übrigens das row_changing durch debuggen gefunden (ausgehend von up/down_row im dbGrid).
Das englischsprachige Forum ist der beste Ort...
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
08.12.2009 17:32 |
|
|
exli2
Mitglied
Dabei seit: 02.12.2009
Beiträge: 37
Einsatzart von VDF: gewerblich
Anwenderstatus: Newbie
Herkunft: Berliner Gegend
Betriebssystem: XP
Themenstarter
|
|
Clever! Ich hab´s mir mal im Debugger angesehen, und tatsächlich irgendwann ist der Wert 1 und behält den Wert...
Ich hab bereits desöfteren mir einige Packages angesehen und manchmal daraus Funktionen verwendet, die sonst nicht dokumentiert waren. Aber mit dem Debugger geht´s natürlich auch.
Danke nochmal für das Gespräch und das nunmehr tolle Ergebnis.
Gruß Andeas
PS. Fällt Dir was zu folgender Frage ein? Problem sind 6 DF-Tabellen und 4 ODBC- Tabellen innerhalb einer Workspace. Die ODBC - Tabellen sind eingebettete Tabellen und liegen auf einem Server bei Provider X mit ca. 20.000 Datensätzen. Wenn zur Laufzeit der Anwendung keine Verbindung online besteht, soll die Workspace alternative DF- Tabellen verwenden, ansonsten eben die Online- Table´s. Ich habe das noch nicht im Griff, weil ja in den betreffenden Views die Fields aus der Online- Tabelle verwendet werden...Die Anzahl der Felder der größten Tabelle beträgt etwa 60. Das muß ich noch knacken, dann funktioniert das Kunden/Auftrags/Wirtschaftssystem..
__________________
Programme sind nur so gut, wie das Zusammenspiel der Synapsen des Entwicklers.
|
|
|
08.12.2009 19:20 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
| Zitat: |
20.000 Datensätzen. Wenn zur Laufzeit der Anwendung keine Verbindung online besteht, soll die Workspace alternative DF- Tabellen verwenden, ansonsten eben die Online- Table´s. Ich habe das noch nicht im Griff, weil ja in
|
Da fällt mir spontan nur die Benutzung von "open xxx as yyy" ein.
Das Programm startet und stellt zuallererst fest, dass keine/eine Verbindung zum entfernen System möglich ist. Je nachdem wird der "open as" entsprechend ausgeführt. Bedingung dafür ist, dass die Tabellendefinition online/offline identisch ist.
Vllt postest Du Deine Frage in einem neuen Thread?
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
09.12.2009 07:31 |
|
|
|
|
|
|
|
PERFEKT! Danke für diesen Tip! Zwar habe ich noch eine Änderung drin: