Diskussion:Steuerelement

Verwendung des Begriffs „Fensterkontrollelement“ außerhalb der Wikipedia?

Den Begriff "Fensterkontrollelement" habe ich außerhalb der deutschsprachigen Wikipedia noch nie gehört, und ich wäre dankbar für einen Hinweis auf eine Verwendung dieses Begriffes in der Literatur o.ä. —Tobias Bergemann 13:41, 12. Mär. 2008 (CET)

Da bin ich auch gerade drauf gestoßen. Gebe dir vollkommen recht. Der weitaus üblichere Begriff ist Steuerelement.

Google Fight ist da auch eindeutig: ~1800:1, Mit steuerelement gui auch immerhin noch ~190:1. 11 Treffer für ein IT-Thema bedürfen wohl keiner weiteren Diskussion mehr. Ich werde das verschieben und im Artikel korrigieren. --Geri, 20:37, 14. Mai 2008 (CEST)

Steuerelement vs. Widget

Das Synonym "Widget" für "Steuerelement" widerspricht dem Widget-Artikel ("...ein kleines Computerprogramm..."). Entweder meinen beide Artikel das gleiche, da: "Auch das aktive Fenster, die Form, kann man als Steuerelement bezeichnen" oder "Widget" im Sinne von "Steuerelement" betrifft lediglich die Oberfläche, während ansonsten das komplette kleine Computerprogramm gemeint ist. Diese Unterscheidung wäre seltsam, finde ich.

"Widgets" sind Codesequenzen, welche in den Quellcode von Computerprogrammen oder deren Subroutinen eingebunden werden, um (nach der Kompilierung und dem Aufruf solcher Programme) Elemente graphischer Benutzeroberflächen zu erzeugen. Widgets sind NICHT Computerprogramme. Widgets übernehmen lediglich graphische oder interaktive Funktionen in Computerprogrammen. -- A.Abdel-Rahim (Diskussion) 03:38, 22. Aug. 2012 (CEST)

…nach 11 Jahren:

Nein, das kann man nicht so stehen lassen! Der Begriff "Widget" wird im Englischen mehrfach definiert. Er wird für Steuerelemente (en:Graphical widget) und kleine Programme (en:Software widget) genutzt. Die kleinen Programme sind tatsächlich Anwendungen mit einer Geschäftslogik und keine Steuerelemente im Sinne dieses Artikels. Die Widgets von Windows Vista & 7 (dort "Gadgets" genannt) waren als ZIP gebündelte Javascripts mit eingeschränktem HTML-Frontend. Die Scripte hatten Zugriff auf spezielle Objekte, die das Betriebssystem resp. die Widget-Engine exklusiv für diesen Zweck bereitstellte (z. B. System.Gadget.Settings.read(…) um gespeicherte Einstellungen des Gadgets zu lesen) und in normalen Webseiten resp. in anderen Browsern ungültig wären (v. a. aus Sicherheitsgründen). Eben genau derartige Mini-Anwendungen werden im dt. Artikel Widget beschrieben - und nur diese. Andere Widget-Engines funktionieren ähnlich. Es sind kleine Programmfragmente, denen vom Container in dem sie laufen bestimmte API-Funktionen zugänglich gemacht werden. Häufig aus Sicherheitsgünden isoliert in einer Sandbox. Es konnten ganze Spiele wie Minesweeper, Chats, Unternehmens-Feeds usw. realisiert werden.

Mit Steuerelementen im Sinne dieses Artikels hat das aber nicht mal entfernt etwas zu tun! Daher habe ich heute den Link darauf entfernt. Der verlinkte Artikel hatte schlicht nichts mit diesem Artikel am Hut. Um die unterschiedlichen Bedeutungen abzudecken, existiert bei uns die BKS Widget (Begriffsklärung).

Wer es für notwendig hält, kann durchaus den Banner…

{{Dieser Artikel|behandelt Bedienelemente einer grafischen Benutzeroberfläche. Zu weiteren Bedeutungen siehe [[Widget (Begriffsklärung)]].}}

…am Artikelanfang einfügen. --Siegbert v2 (Diskussion) 13:31, 23. Mär. 2024 (CET)

Widgets und Kindfenster

Das Begriffswirrwarr hat sicherlich auch seinen Ursprung aus den verschiedenen Sichtweisen eines X- oder Mac-Programmierers auf der einen und dem Windows-Programmierer auf der anderen Seite.

Beim Siegeszug grafischer Benutzeroberflächen (auch im Textmodus, etwa Turbo Vision) spielten rechteckige, überlappbare, per Clipping begrenzte Ausgabebereiche eine entscheidende Rolle, und wurden gemeinhin Fenster genannt. Erst später wurden nicht-rechteckige Ausgabebereiche möglich.

Für die Ausgestaltung von Dialogen benötigte man Kontrollelemente, die sowohl Eigenschaften von Fenstern haben (bspw. rechteckig, positionierbar, anklickbar), als auch nicht (Clipping ist nicht erforderlich und würde die Performance einbrechen lassen).

Nun ging man dazu verschiedene Wege. X und Mac verwenden „Widgets“, die keine Fenster sind.

Bei Microsoft hingegen sind Kontrollelemente ebenfalls Fenster (meistens zumindest), mehr oder weniger global verfügbare Fenstervorlagen mit vordefinierten „Klassennamen“ (hat nur entfernt mit OOP zu tun). Das Stil-Bit WS_CHILD („Fensterstil:Kind“) sorgt schließlich dafür, dass das Fenster „eingebettet“ erscheint und die Performance-Killer umgangen werden.

Ein Steuerelement hingegen ist das, was der Benutzer sieht (oder hört oder der Blinde fühlt), egal wie es implementiert wurde.

--Henrik Haftmann (Diskussion) 18:33, 1. Okt. 2012 (CEST)

Caption

Hi, kann bitte jemand Caption sinnvoll in die Liste integrieren; mir fehlt gerade die Zeit. LG, ℳ웃79 ^✍ 14:07, 28. Mär. 2017 (CEST)

Bedienelement

Habe gerade mal oder Bedienelement hinzugefügt. Der Begriff passt sogar noch besser als Steuerelement, weil das programm über diese Schaltflächen durch den Benutzer bedient wird. ;-) User:ScotXW^t@lk 20:25, 30. Jul. 2017 (CEST)

Die Ergänzung ist vollkommen gerechtfertigt, aber die Begründung hat einen kleinen Haken: Es gibt auch "unsichtbare" Steuerelemente (z. B. Timer oder Socket-Komponenten). Diese können durchaus Ereignisse auslösen und das Programm in gewisser Weise steuern, ohne das der Benutzer etwas aktiv bedient. In manchen Frameworks (z. B. .NET) werden sichtbare Steuerelemente als Control bezeichnet und die "unsichtbaren" Steuerelemente als Component. --Siegbert v2 (Diskussion) 13:47, 23. Mär. 2024 (CET)

Verwendung des Begriffs: "Formular"

Am Anfang der Liste von bekannten Steuerelementen steht derzeit das Steuerelement "Formular" mit der folgenden Erklärung:

"Formular: Das meist unsichtbar im Hintergrund eines Fensters liegende Steuerelement, das alle anderen Steuerelemente enthält"

Diese Erklärung halte ich für nicht zutreffend. Unter einem Formular bzw. Form verstehe ich ein (Dialog-)Fenster. Also die komplette Oberfläche mit Non-Client-Area (Titelleiste und Rahmen) und Client-Area (der komplette innere Bereich, den Entwickler frei gestalten können). In der Client-Area kann man direkt Steuerelemente (Textfelder, Schaltflächen Symbolleisten etc.) unterbringen. Dafür braucht man nicht zwingend ein zusätzliches Container-Steuerelement, das andere Steuerelemente enthält (also das, was bisher in der Definition für den Begriff "Formular" steht). Container werden allerdings häufig genutzt, um einen scrollbaren Bereich zu schaffen und zur einfacheren Gestaltung des Layouts. Bei diesen Containern spricht man von Frame, Panel, UserControl oder PropertySheet, aber nicht von Formular. Formular ist ein Synonym für das ganze Fenster und ist insbesondere auch nicht unsichtbar (wie es in der bisherigen Definition steht).

Mein Vorschlag:

• In der Einleitung erläutern, dass Steuerelemente auf Fenstern (alias Formularen oder Form) platziert werden können.
• Den bisherigen Punkt "Formular" in "(Layout-) Container" oder "Panel" umbenennen und beschreiben, dass mit diesen (meist unsichtbaren bzw. transparenten) Containern Steuerelemente zusammengefasst werden können.
• Optional noch am Ende der Liste einen Punkt für unsichtbare Steuerelemente (i. d. R. "Komponenten" genannt). Das sind beispielsweise die Standarddialoge (Öffnen, Speichen, Drucken, Farbauswahl, Schriftauswahl), Komponenten zur Hardware-Kommunikation (z. B. COM- und USB-Ports) und Komponenten zur Verwaltung von Diensten und Events (z. B. MAPI, Winsock, TWAIN, ImageLists, Timer etc.). --Siegbert v2 (Diskussion) 07:44, 22. Jul. 2022 (CEST)