EDOMI - Fragen zur Visuseitenerstellung

[HappyJack]

Eine Frage zu der Möglichkeit Text zu drehen. Ich möchte Text um 270 Grad drehen (funktioniert ja) und diesen aber am Rand eines Pop-up Fensters positionieren. Leider geht das nicht, da er (blöd zu beschreiben) die Länge von Text ungedreht als Rand beibehält. Ich kann somit den Text nur zu 50% der Textlänge an den Rand. Mit anderen Worten ein längerer gedrehter Text läßt sich nicht an den Rand schieben. Ist das so gewollt?

[rdeckard]

Hmm...habs auch mal getestet. Scheint ein Bug zu sein. Die Verschieben-Hilfe hat immer noch die ursprünglichen Werte des Elements (bevor es gedreht wurde).
Man kann es auch nicht überlisten, indem man zuerst x=50 und y=300 setzt und dann erst dreht. Ein Versuch wars wert...hehe

[HappyJack]

hatte ich auch schon versucht - mag er nicht

[gaert]

Nee, das mag er wirklich nicht Liegt ganz einfach daran, dass der Editor das Visuelement nur visuell dreht, nicht jedoch "mathematisch". Dies ist und war mir durchaus bewusst, nur war mir dieses Verhalten schnuppe da ich die Rotation lediglich für die Darstellung rotationssymmetrischer Elemente (Drehknopf) verwendet habe (also nie für vertikalen Text o.d.G.).

Kommt auf die Liste

[HappyJack]

Supi

[gaert]

So - erledigt. In Zukunft wird die Rotation bei der Berechnung der "Bounding-Box" berücksichtigt - siehe Screenshot. Zu bedenken ist lediglich, dass sich die Koordinaten eines Visuelements immer auf den unrotierten(!) Zustand beziehen. Wenn man also z.B. einen 100x50 große Box um 90 Grad rotiert und in die linke obere Ecke (0,0) positioniert, werden die Koordinaten nicht (0,0) sein, sondern (-25,25) - einfach mal nachrechnen... Im Visueditor werden natürlich die "echten" Koordinaten (0,0) angezeigt, in den Einstellungen des Visuelements jedoch (-25,25) - denn dies entspricht der unrotierten Rohfassung des Elements.

Lange Rede kurzer Sinn: Solange man nicht manuell die Koordinaten eingibt, muss man nicht nachdenken

Bildschirmfoto 2016-03-04 um 10.20.39.png


PS: Aktuell kann man noch keine negativen Koordinaten angeben - also nicht wundern...

[Stoxn]

Magst Du in dem Zuge auch Vertical Align für Text aufnehmen? Hatte ich in einem anderen Thread schon mal angesprochen und ich gebe zu, da scheint nicht sonderlich viel Interesse zu bestehen. Aber man kann ja noch mal fragen... :-)

[gaert]

Das würde sehr tiefgehende Änderungen nach sich ziehen, da ein "exzentrisches" Positionieren in der Vertikalen konzeptionell nicht vorgesehen ist. Daher wird dies eher nicht implementiert werden... Aber wie schon gesagt kannst Du doch einfach ein weiteres Visuelement entsprechend skalieren und positionieren.

[Stoxn]

Oh, das die Änderung tiefgehend ist, war mir nicht bewusst. Genau so habe ich es gelöst und der Mehraufwand ist verschwindend gering. Dann bleiben wir auch dabei - danke für die Antwort.

[KNXFan1970]

Gerade probiere ich den Schieberegler aus, der wirklich gut funktioniert. Nun soll der Schieberegler aber nur in Abhängigkeit eines anderen KO sichtbar/bedienbar sein.
Hier komme ich nicht weiter. Ich kann zwar mit einem anderen Universalelement überdecken, aber der Schieberegler darunter bleibt dabei ja bedienbar (wenn auch nicht mehr sichtbar). Hat jemand eine Idee, wie ich dies lösen könnte.
Vielen Dank an ALLE, die darüber nachdenken...

[gaert]

Du kannst den ganzen Slider "ausblenden", indem Du ihm per dynamischen Design eine 100%tige Transparenz (Opazität: 0) verpasst...

Oder Du weist dem überdeckendem Element einen "Befehl" zu (irgendeinen sinnlosen Dummy-Befehl) - dann erst reagiert das Element nämlich auf Klick-Ereignisse und verhindert so, dass der Slider anklickbar ist.

Die erste Variante wäre natürlich "sauberer"

[KNXFan1970]

Du kannst den ganzen Slider "ausblenden", indem Du ihm per dynamischen Design eine 100%tige Transparenz (Opazität: 0) verpasst...

Oder Du weist dem überdeckendem Element einen "Befehl" zu (irgendeinen sinnlosen Dummy-Befehl) - dann erst reagiert das Element nämlich auf Klick-Ereignisse und verhindert so, dass der Slider anklickbar ist.

Die erste Variante wäre natürlich "sauberer"

Danke gaert und sorry, wenn ich gleich noch einmal nachfrage. Das dynamische Design kann doch nur auf das im Element angegebene Status-KO reagieren. Das ist aber schon mit dem Status für den Slider belegt und kann somit nur auf Sliderwerte reagieren. Oder gibt es noch eine andere Möglichkeit?

Somit bleibt bisher scheinbar nur Variante 2 - aber das reicht ja auch

Ergänzung:
Ich sag es nicht gern, aber Variante 2 scheint - zumindest so, wie ich es probiert habe - auch nicht zu funktionieren. Man kann den Slider trotzdem bedienen - selbst, wenn man dem überdeckenden Element einen Dummy-Befehl z.B. 'KO Dummy Wert 1 zuweisen' mit auf den Weg gibt.

[gaert]

Da hast Du natürlich recht - der Slider kann nur auf sein KO reagieren bezüglich des dynamischen Designs.

Variante 2 funktioniert bei mir wunderbar (hab's noch nicht auf einem Touch-Device probiert, nur per Maus). Du musst natürlich darauf achten, dass das verdeckende Element auch wirklich "über" dem Slider liegt (z-Index). Das Element muss den Slider vollständig(!) überdecken - also das gesamte Visuelement, nicht nur den eigentlichen Slider-Knopf.

Ein Dummy-Befehl ist unbedingt erforderlich, da ansonsten bei dem Element kein Klick/Touch-Event hinzugefügt wird (ist ja dann nicht notwendig). Das Element ist ohne Befehl quasi "durchsichtig" für Klick/Touch-Events.

[KNXFan1970]

gaert
Mein Fehler - es lag am z-Index (den muss man wirklich setzen!). Bei gleichem z-Index wird der Slider auch überlagert und "versteckt", aber der Klick/Touch geht dann "durch" - selbst mit Dummy-Befehl (meine ich getestet zu haben).
Jetzt (mit z-Index) funktioniert es (am Mac und am iPhone) - sieht aber nicht so toll aus, da der 'Klickindikator' natürlich seinen Job macht.
Besteht die Möglichkeit irgendwann dem Slider eine zusätzliche Eigenschaft zu geben, um diesen - gesteuert über ein KO - unsichtbar (für's Auge und für Klick/Touch) zu machen?

[gaert]

Der Z-Index ist nur dann erforderlich, wenn das Element "von Natur aus" hinter dem Slider liegen würde (dies tut es, wenn es zeitlich vor dem Slider erstellt worden ist). Wenn's im Editor vor dem Slider liegt (egal ob per Z-index oder bedingt durch die Erstellung) klappt das so oder so!

Zu Deiner Frage: Eher nicht, denn dies würde ja noch ein weiteres KO bedeuten (3 KOs insgesamt). Und das ist nicht vorgesehen und irgendwie wird's dann auch langsam unübersichtlich mit den KOs...

Aber: Du kannst natürlich einen Umweg über eine Logik nehmen, d.h. der Slider bekommt nicht das tatsächliche Status-KO präsentiert, sondern ein entsprechend modifiziertes Status-KO (intern). Wenn dieses z.B. -1 ist, wird der Slider nicht angezeigt (dynamisches Design), ansonsten wird der Slider (samt Status-KO) angezeigt.

In der Praxis brauchst Du dann nur eine Logik, die dieses "Fake-Status-KO" entweder auf den korrekten Wert setzt oder auf -1 (je nach Situation).

EDIT:
Wofür braucht man soetwas eigentlich? Ich finde, dass ein Slider (oder jedes andere Element) immer sichtbar/bedienbar sein sollte. Wenn die Situation dies nicht erlaubt (z.B. Sollwertverstellung), dann würde ich dies z.B. in ein Popup verfrachten und nur anzeigen, wenn es Sinn macht bzw. erlaubt ist (Code, Logik, o.d.G.).