DevExpress: "AutoSearch" funktioniert nach Änderung vom Repository nicht mehr

[haentschman]

Hallöle...

Ich habe bei DevExpress ein Ticket am Laufen. https://supportcenter.devexpress.com...but-which-ones
Wie zu erwarten war..."Mach mal eine Demo".
Zitat:
"I see the issue; however, this information doesn't allow me to determine its cause."

Ich hoffe, daß jemand mir mit einfachen Worten erklären kann welche Einstellung/Konstellation dafür verantwortlich ist...

zum Thema:
Ich habe ein „Modul“, das ich geändert habe. Eine Spalte der View hat ein Repository...das gleiche Repository wie vorher. Aber geändert. Die View hat sich im Repository geändert. (Spalten, Namen, Gruppierung). Zuvor wurde der Datensatz/Datenmenge bereits statisch im OnPopup geladen. (Refresh) Jetzt wird der Datensatz im OnPopup immer neu geladen, da er berechnet wird. (Öffnen)

Bisher gab der Benutzer die Anfangsbuchstaben der Artikelnummer ein (Spalte Artikel-Nr.), die View öffnete sich, der Treffer wurde entsprechend des Tastendrucks markiert (Video old.mp4) In der neuen Version wird die View geöffnet, die Markierung erfolgt aber immer auf dem ersten Datensatz. (Video new.mp4)

was ich versucht habe:

1. Gruppierung raus.
2. Spalte Artikelnummer als erste (war die 3., die anderen waren nicht sichtbar)
3. Daten statisch
4. Überprüfung der Eigenschaften...gleich (nur andere Namen, View)

Ohne Erfolg...Was ist falsch?

Delphi-Quellcode:

// Old static:

procedure TdmRepositories.EdRepoExtLookupTeilPropertiesInitPopup(Sender: TObject);
begin
  DMLUP.dsReproPartMaster.DataSet.Refresh;
end;

//New (change only name 'dsReproPart'):

procedure TdmRepositories.EdRepoExtLookupTeilPropertiesInitPopup(Sender: TObject);
begin
  DMLUP.LoadArticle;
  TSEAMToolsDevExpress.ExpandLevel(TcxGridTableView(EdRepoExtLookupTeil.Properties.View), 0, True);
end;
.
.
procedure TDMLUP.LoadArticle;
begin
  dsReproPart.DataSet.Free; 
  dsReproPart.DataSet := FDatabase.CreateRepositoryPart(FArticleFavorite, FReceiptAddress);
end;
.
.
function TSEAMDatabase.CreateRepositoryPart(Favorite: Boolean; ReceiptAddress: string): TDataSet;
var
  Qry: TFDQuery;
begin
  Qry := CreateQuery;
  Qry.SQL.Text := GetSQLByName('REPO_CHOICE_ARTICLE_ALL');
  Qry.ParamByName('ADR').AsString := ReceiptAddress;
  if Favorite then
  begin
    Qry.SQL.Add(GetSQLByName('REPO_CHOICE_ARTICLE_FAVORITE'));
  end;
  Qry.SQL.Add(GetSQLByName('REPO_CHOICE_ARTICLE_WHERE'));
  Qry.SQL.Add(GetSQLByName('REPO_CHOICE_ARTICLE_ORDER'));
  Qry.ParamByName('UID').AsInteger := FPreferences.CurrentUser.ID;
  Qry.Open;
  Result := Qry;
end;

Danke

[himitsu]

Die laden oft nicht alles sofort, sondern gern verzögert, also einmal die Daten in ihren Cache und dann nochmal die Generierung der Anzeige,
womit es wahrscheinlich ist, dass es einfach noch nicht da ist und somit ein Expand/ChangeRecord/sonstwas nicht noch nicht gehen kann.

Du willst nicht wissen wie lange wir versucht haben, wenn wir per Code das SearchEdit im Grid einblenden, dann auch per Code den Fokus dort rein zu setzen.
* DevExpress macht es nicht selbst
* und egal wann wir das SetFocus machen, immer knallt es
Nach einem halben Jahr haben wir dann aufgegeben, da auch DX keine Hilfe war.
Es ging auch einmal kurz, aber dann bauten sie wieder alles um und es ging von Vorne los.
(ja, Timer geht, aber versuch mal den Nutzern zu erklären, warum es eine halbe Minute braucht, bis es los geht, wenn er den SuchShortcut gedrückt hat)

ForceQueue, PostMessage, Timer ... versuch dein Glück.
Falls du viel Glück hast, gibt es irgendwo versteckt eine "mach JETZT"-Funktion.

[haentschman]

Danke...

Persönlich würde mich das nicht stören, weil die Suche im View eingeblendet ist...und die auch noch funktioniert. Ich mache mir eher Sorgen mit dem Stress mit den Usern weil es nicht mehr wie früher funktioniert...

[Sinspin]

Ich verstehe dein Leid. Aber es bringt nichts sich darüber aufzuregen. Das verkürzt nur die Zeit die uns bleibt um uns über andere Dinge aufzuregen.

Speicherst Du die Grid Einstellungen in der Registry oder in einer Config? Wenn ja muss das weg für solche Änderungen.
Ein paar Ideen, eventuell fruchtet eine davon : Sync Mode, Grid Mode, Incremental Search, Key Field.

[haentschman]

Hallöle...

Zitat:

Speicherst Du die Grid Einstellungen in der Registry oder in einer Config? Wenn ja muss das weg für solche Änderungen.

...die Spalten sind definiert über das gespeicherte Layout. Ich kenne das Problem damit. Das betrifft aber nur die Anzeige visible etc. Der Rest der Spalte (Properties) ist unverändert.
Die Properties der Artikel Nummer Spalte sind alt/neu identisch.

Zitat:

Ein paar Ideen, eventuell fruchtet eine davon : Sync Mode, Grid Mode, Incremental Search, Key Field.

...identisch alt/neu, bis auf den Namen des Key Field. Den Namen muß ich noch überprüfen.

Nachtrag:
KeyField sollte richtig sein..."ArticleNumber"

[lxo]

Zitat von haentschman:

Hallöle...
...
procedure TDMLUP.LoadArticle;
begin
dsReproPart.DataSet.Free;
dsReproPart.DataSet := FDatabase.CreateRepositoryPart(FArticleFavorite, FReceiptAddress);
end;
...

Ich vermute das Problem eher im Freigeben des DataSets und dann ein neues zuordnen.
Da wird wohl irgendwas zeitlich oder inhaltlich nicht mehr passen im DataController.

Ist es eine Option das DataSet nicht freizugeben und das bestehende einfach zu aktualisieren?


Und warum wird das DataSet überhaupt immer wieder erneuert, sind die Einträge im Popup abhängig von irgendwelchen Werten in der Datenzeile?
Wenn die Einträge im Popup immer gleich sind würde es doch reichen dies einmalig zu initialisieren.
Und auch bei Abhängigkeiten zur Datenzeile könnte man ja auch dahin gehen initial erstmal alles zu laden und dann beim Popup nach Bedarf zu filtern.

[haentschman]

Zitat:

Ist es eine Option das DataSet nicht freizugeben und das bestehende einfach zu aktualisieren?

Im SQL laufen Berechnungen bezogen auf mehrere Tabellen abhänging von äußeren Parametern. (Kundenpreise entsprechend des Rechnungsnehmers) Mit Refresh kann ich die Parameter nicht tauschen...oder ich weiß es noch nicht.

Vorgabe: SQL nicht in der Query gespeichert. Ich probiere es mal aus die Query nicht neu zu erzeugen, sondern das SQL mit anderen Parametern anzupassen.

Danke...

[lxo]

Zitat von haentschman:

Zitat:

Ist es eine Option das DataSet nicht freizugeben und das bestehende einfach zu aktualisieren?

Im SQL laufen Berechnungen bezogen auf mehrere Tabellen abhänging von äußeren Parametern. (Kundenpreise entsprechend des Rechnungsnehmers) Mit Refresh kann ich die Parameter nicht tauschen...oder ich weiß es noch nicht.

Vorgabe: SQL nicht in der Query gespeichert. Ich probiere es mal aus die Query nicht neu zu erzeugen, sondern das SQL mit anderen Parametern anzupassen.

Danke...

Also mit UniDAC kann ich einfach bei einem bereits geöffneten Query die Parameter neu setzen und dann Refresh aufrufen.
Hier mal ein Beispiel
Weiß nicht ob du das brauchst mit dem positionieren (locate), das habe ich in meinem Fall nur drin weil ich dort in eine andere Ansicht springe und die IDs gleich bleiben und ich mich somit wieder auf die alte Position stelle.

Delphi-Quellcode:

var
  lID: Integer;
begin
  <Query>.DisableControls;
  try
   lID := <Query>.FieldByName( 'ID').AsInteger;
   <Query>.ParamByName('PARAM').AsInteger := <NewValue>;
   <Query>.Refresh;
   <Query>.Locate( 'ID', lID, []);
  finally
    <Query>.EnableControls;
  end;
end;

[Sinspin]

Die Grids sind mittlerweile fürchterlich was Änderungen in Subtabellen angeht. Ich arbeite da fast nur noch mit Messages um dem Grid Zeit zu geben sich anzupassen.
Ich würde für solche Eingaben keine ExtendedLookupTable nehmen. Das machen bei mir modale Dialoge die den Grid und ein Freitextsuchfeld enthalten.
Das ergibt auch eine saubere Trennung. Aber vieleicht hast Du ja Kunden die keine 100%ig Führung brauchen um ordentlich zu arbeiten.

[haentschman]

Zitat:

Ich arbeite da fast nur noch mit Messages um dem Grid Zeit zu geben sich anzupassen.

...hast du auch schon mal dass Grid schwarz wenn du einen Dialog oder Form darüber öffnest? Hat DevExpress vor 2 Jahren eingebaut...ohne Lösung!
https://supportcenter.devexpress.com...wing-msgdialog

Zitat:

Ich würde für solche Eingaben keine ExtendedLookupTable nehmen

Das ist die Vorgaben "Eingabe" für die Artikelposition. Da wir verschiede Konstellationen der "Berechnung" haben, muß ich das vorher berechnen und in die Oberfläche fertig eintragen. Das Ergebnis der Auswahl kommt nur in EINE Tabelle.