Ich habe eine ähnliche Idee gepostet mit einer Ergänzung bzgl Filterung in den Tabellenköpfen. Vielleicht kann man die Ideen zu einer vereinen bzw. für beide voten? siehe https://ideen.docusnap.com/s/idea/0873X000000cOSYQA2/detail
klar, das Grid würde ich auch nicht in der defaultmaske unterbringen. Das Problem mit dem Speichern solcher Werte (auf verschieden Darstellungen/Tabs/Masken) ist ja ein grundsätzliches... Aber ggf. sollte man die Ursache , konkret bei den Standorten, angehen und herstellerseitig eine Lösung anbieten. Gerade bei den großen Kunden , welche die Abbildung der Assets auf Raumebene nutzen wollen/müssen es anders lösen bzw. abzubilden. Ein Scrollen in einem solchen Baum ist nicht ergonomisch. ( x Gebäude, n Etagen, m Räume kann schon groß werden) Aber auch die Tatsache dass der Pfad nicht ohne weiteres im Tree zu erkennen ist und Räume auch gleiche Namen in unterschiedlichen oder sogar gleichem Etagen , Gebäuden haben können, zeigt das es zwar alles flexibel abbildbar in der rekursiven Struktur ist aber es folglich auch Probleme mit sich bringen kann. z.B. Kontinent unter Raum anlegen. Doppelte Raumbezeichnungen. In Thosts steht aber nur der zugeordnete Standort kontextfrei ohne Struktur drin ... Asset Listen bei den Standorten sollten rekursiv aufgelöste werden können (wie auch bei den Plänen möglich) , etc. Es ist dann einiges an Customizing was man dann nachträglich , (außerhalb Default Baum) baut um es abzubilden. Ein selbst auferlegtes Namensschema der Raum; Etagen, Gebäude, verhindert dies . Eine festere Definition der Struktur (also Räume nur in Etagen, und Etagen nur in Gebäuden,etc.) würde hier in Verbindung mit technischer Verhinderung von Doppeleinträgen (Raum1... eineindeutig !) Dazu gehören dann auch noch die Pfade des Assets , etc. Auch wenn die Suche praktisch im Baum wäre und ich dies auch ausdrücklich unterstütze (siehe Like) würde ich mir eine übergreifenden Ansatz der Problematik wünschen ; Also den Einbau des häufig gemachten Customizings in den Standard (rekursive Standort Assetlisten, Eineindeutige Standortbezeichnung, Strukturvorgaben, Pfadangaben Liste (siehe Bild von eben) statt Treeview, etc.) ggf. auch Namensschema für die Standorttypen (analog Nummerkreisverwaltung) , etc. Das Ausbessern von ggf. fehlenden / gewünschten Funktionen ist nicht immer zielführend um die eigentliche Problematik zu lösen.
Ja, das geht bei selbst erstellten MAsken und ich nutze dies auch so. Leider geht das nicht bei Default-Masken, da man dort die Treeviews nicht entfernen kann. Eine zusätzliches Grid beisst sich dann mit dem Werks-Treeview beim Speichern eines Standortes.
Ich kann leider keinen Screenshot von einem Treeview mit Suchfeld machen, da es das ja nicht gibt. Gemeint ist, dass man aktuell in Treeviews bei großen Datenmengen lange scrollen muss. Mit einem Filterfeld könnte man schneller zum Ziel gelangen.
siehe https://ideen.docusnap.com/s/idea/0873X000000cOSYQA2/detail