First, mappView visualization positions are static (you cannot move widgets at runtime), so using the Paper widget—which can take full content—might do the job.
do not use the Paper widget function (“svgContent”) for a button bar that is already
Even if a button bar is already available as a mappView widget, I’m not sure if you can use a widget inside a Paper widget. It might work for styling, but I doubt it would support binding or event binding.
ideally use “horizontalPos” and “verticalPos” of the Paper widget click event
What would be the goal of using the click event? Did you not want to manage the button bar’s position from the PLC side?
Possibly position the created widget dynamically elsewhere in the future (hence no SVG)
If you don’t use the SVG part of the Paper widget, I think it will be complicated.
Here’s my thought: You could create an SVG section within the Paper widget that consists of multiple buttons, each with a unique “id”. Group all these buttons inside a <g></g> tag with its own unique “id”. When you need to move the button bar, you can use a Transform to reposition the group. When a user clicks on the Paper widget, you can check the “elementId” from the click event to identify which button was clicked.
Do you have a more concrete example of what you’re trying to achieve? A small diagram would be perfect!
The (by an external program) generated SVG of the customers production line has several elements (machines, transport elements, etc.) which are selected and are already “marked” by the plc. But now there is another “multi client part” which show an “overlay” (button bar) to give the customer the possibility to show more information (name of selected element, button for jumping to window with propteries/settings [speed, more information to errors, etc.]).
Other departments mentioned that they also have use cases for such an widget which can be positioned at runtime but they don’t use SVGs → the reason why I’m looking for a “mapp view way” (instead of the “SVG way”).
The idea is good by I think the “svgContent” could also be generated at runtime with javascript (no need to prepare an item in given SVG).
The Red rectangle is a Paper widget used to represent production line (with all the elements), the Green rectangle is the “overlay” you want to add inside the Paper widget to control what is display in the Paper widget (I used random text for the buttons just to have someting).
And the other important thing is that you want to change position of the button bar when based on what you are displaying in the Paper widget (based on the client line)?
And also be sure that this could handle multiple clients, like that the “overlay” choices affect only the current client, not all clients!
Yes, I use that and I also had to build a “synchronization” here, since we trigger/send transformStrings from different sources (PLC1, PLC2, widgets.xx1.clicked, widgets.xx2.clicked, variables.xx3.valueChanged, etc.).
Not sure if I fully understood your use case - but it sounds to me that a “dialog” is your friend.
A dialog can be opened at (almost) any position and the content can be dynamically exchanged, so you can show widgets, based on your current position in the SVG. This should give you the impression of an “overlay”.
horizonalPos and verticalPos are predefined enum values - not integers.
With the event-binding you’re feeding in integers, which, at runtime, cannot be resolved to the expected enums … so it behaves like not specified and the dialog opens at “right” / “top”. That’s why it did not work for you.
The script editor is smarted and does not allow you to connect the integer values.
Is there also a setting option so that the dialog only covers this specific content? I couldn’t find that.
Unfortunately, when I use the dialog, it also covers flyouts (ribbon), which shouldn’t be the case.
no. This is not covered by this function.
”OpenDialogAtTarget” is supposed to open the dialog in relation to a target widget - but it does not care about covering anything or not.
If you need more control, you need to use “OpenDialog”.
Unfortunately, I can’t figure out how to set the dialog to be opened in a “more background level”.
I’ve seen the “autoRaise” attribute mentioned in conjunction with zIndex (level?).
→ Where can I see what can be transferred here (in “brease_enum_autoraise”)? It’s an enum → where can you see the content?
=> I tried the selectable values (“enabled” or “disabled”) of the XML (.eventbinding), but nothing changes and it continues to cover foreign elements
I think I do not understand what you’re trying to solve. What do you mean with “opened in a “more background level”” ?
In general you cannot control the z-index of a dialog, a dialog is always opened on highest level. Please also keep in mind that a dialog is always “above” the content - you cannot move a dialog behind the widgets of the content.
“autoRaise” is useful if you have several open dialogs in parallel. If this feature is used, it brings a dialog into foreground, if you click on it - otherwise the dialog remains in the background.
Das “Popup-Widget”, das gerade aufgegangen ist, hat nicht die Funktion irgendwas anderes zu überdecken, da es extrem störend ist, wenn man im Menüband (oberes Ende wie bei Microsoft Office Tools oder anderen Programmen) etwas öffnet und Teile davon durch einen “Dialog” verdeckt werden.
Es gehört ausschliesslich zu dem “paper widget” und stellt nur für dieses widget weitere Buttons oder auch Labels (Name des Elements) zur Verfügung.
Danke für die Erklärung.
Was ich allerdings nicht verstehe ist, warum ein Dialog etwas verdecken würde?
Anders ausgedrückt: Ob der Dialog etwas verdeckt oder nicht hängt letztlich davon ab, an welcher Position er geöffnet wird bzw. wie groß er ist.
Hat der Dialog die passende Größe und man öffnet ihn innerhalb der Grenzen des SVGs, dann sollte man doch den gewünschten Effekt bekommen?
In der GUI befindet sich bereits ein “Menü Button”, der ein Flyout von links über ca 60% des Bildschirms öffnet.
Wenn ein Nutzer nun im SVG klickt erscheint der Dialog (Button bar).
Der Dialog sollte nicht verschwinden, wenn dem Bediener gerade noch einfällt, dass er im Menü (Flyout von links) eine andere Sprache auswählen muss (da er bspw. nur auf die Grafik konzentriert war).
→ dieses Menü (60% des Bildschirms als Flyout von links) wird dann überdeckt vom Dialog