Formular Check - roter Rahmen um Controls

CRouch

Hallo,
ich möchte gerne vor dem "absenden" eines Formulars checken, ob die Inputfelder / Comboboxen ausgefüllt wurden. Wenn nicht, soll das entsprechende Element einen roten Rahmen bekommen. Ist der Feld ausgefüllt, soll der Rahmen wieder verschwinden.
Gibt es hierfür bereits ein UDF oder wie könnte ich das ab einfachsten realisieren?

Vielen Dank schonmal.

**alpines**

Das kriegst du ganz einfach mit Labels hin. Erstelle einfach ein leeres Label mit derselben Größe wir das Control (Nur 2 nach oben und links versetzt und 4 größer) und färbe es transparent bzw. die aktuelle Hintergrundfarbe.
Wenn das Control nicht richtig ausgefüllt wurde kannst du einfach die Farbe gleich rot setzen und schon hast du einen roten Rahmen drum.

Alternativ kannst du dafür auch _GDIPlus verwenden aber die Label Variante ist wesentlich einfacher.

**alpines**

Hier ein Beispiel wie du es machen könntest:

Spoiler anzeigen

[autoit]

#include <ButtonConstants.au3>#include <EditConstants.au3>#include <GUIConstantsEx.au3>#include <StaticConstants.au3>#include <WindowsConstants.au3>#Region ### START Koda GUI section ### Form=$Form1 = GUICreate("Form1", 170, 77, 192, 124)$Label1 = GUICtrlCreateLabel("", 14, 14, 141, 25)$Input1 = GUICtrlCreateInput("Geben Sie eine Zahl ein", 16, 16, 137, 21, BitOR($GUI_SS_DEFAULT_INPUT,$ES_CENTER))$Button1 = GUICtrlCreateButton("Bestätigen", 16, 40, 138, 25)GUISetState(@SW_SHOW)#EndRegion ### END Koda GUI section ###While 1$nMsg = GUIGetMsg()Switch $nMsgCase $GUI_EVENT_CLOSEExitCase $Button1If Not Number(GUICtrlRead($Input1)) ThenGUICtrlSetBkColor($Label1, 0xFF0000)EndIfEndSwitchWEnd

[/autoit]

Allerdings ist hier das Problem das das Label danach den Fokus hat also müsstest du wieder das Input fokussieren.

CRouch

Danke erstmal für Deine Idee. Das Problem an dieser Variante ist, dass da Label vor dem Inputfeld liegt und das Inputfeld nicht mehr "anklickbar" ist. Wenn ich die Reihenfolge tausche (so wie im Beispiel) sieht das Ganze nicht mehr besonders schön aus, da ja nicht der Rand des Labels sondern das gesamte Label gefüllt wird.
Vielleicht noch andere Ideen?

AutoIt

#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#include <ColorConstants.au3>




$Form1 = GUICreate("Form1", 170, 77, 192, 124)
$Input1 = GUICtrlCreateInput("Geben Sie eine Zahl ein", 16, 16, 137, 21)
$Label1 = GUICtrlCreateLabel("", 14, 14, 141, 25)


$Button1 = GUICtrlCreateButton("Bestätigen", 16, 40, 138, 25)


GUISetState(@SW_SHOW)


While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit


		Case $Button1
			If Not Number(GUICtrlRead($Input1)) Then
				GUICtrlSetBkColor($Label1, $COLOR_RED)
			Else
				GUICtrlSetBkColor($Label1, $CLR_NONE)
			EndIf
	EndSwitch
WEnd

Alles anzeigen

**Kanashius**

So funktioniert es :). Du brauchst halt das $Gui_Disable als state beim label.

AutoIt

#include <GUIConstantsEx.au3>
$Form1 = GUICreate("Form1", 170, 77, 192, 124)
$Label1 = GUICtrlCreateLabel("", 14, 14, 141, 25)
GUICtrlSetState(-1,$GUI_DISABLE)
$Input1 = GUICtrlCreateInput("Geben Sie eine Zahl ein", 16, 16, 137, 21)
$Button1 = GUICtrlCreateButton("Bestätigen", 16, 40, 138, 25)
GUISetState(@SW_SHOW)
While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
		Case $Button1
			If Not Number(GUICtrlRead($Input1)) Then
				GUICtrlSetBkColor($Label1,0xFF0000)
			Else
				GUICtrlSetBkColor($Label1, 0x000000)
			EndIf
	EndSwitch
WEnd

Alles anzeigen

**BugFix**

Ich verwende für sowas keinen roten Rahmen, sondern setze bei fehlerhafter Überprüfung die Schrift auf rot. Das fällt auch sofort ins Auge und ist eindeutig.

CRouch

Und wenn das Inputfeld leer ist und der User soll darauf hingewiesen werden, dass das Feld leer ist? Keine, rote Schrift

**BugFix**

Zitat von CRouch

Keine, rote Schrift

Man, wo ist deine Kreativität? Da schreibst du rein: DARF NICHT LEER SEIN!

**Kanashius**

Ich färbe meistens den Hintergrund des Textfeldes ein :P, so hat jeder seine art^^
(Wenn mans nicht lesen kann, dann nen helleres rot z.b.)

CRouch

Zitat von BugFix

Man, wo ist deine Kreativität? Da schreibst du rein: DARF NICHT LEER SEIN!

Naja ganz so unkreativ bin ich nicht. Nur wenn ich die Controls auf GuiCtrlRead($xyzControl) <> "" teste, und bei einem Fehler danach Text reinschreibe, drückt der User danach auf senden und das Formular wird mit "Darf nicht Leer sein!" abgeschickt. Wie könnte denn ansatzweise eine DrawRect Variante mit GDI+ aussehen?

Runa

AutoIt

#include <GUIConstants.au3>


$gui = GUICreate("", 300, 200)
GUISetBkColor (0xFFFFFF)
$Input_Border =GUICtrlCreateLabel("", 9, 9, 192, 22)
GUICtrlSetBkColor($Input_Border, 0x666666)
$Input = GUICtrlCreateInput("", 10,10,190, 20, -1, $WS_EX_TOOLWINDOW)
GUICtrlSetBkColor($Input, 0xDEDEDE)
$Button = GUICtrlCreateButton("Absenden", 9, 35, 100, 21)
GUISetState()




While 1
    $msg = GUIGetMsg()
    Switch $msg
        Case $GUI_EVENT_CLOSE
            Exit
		Case $Button
			If GUICtrlRead($Input) = "" Then
				GUICtrlSetBkColor($Input_Border, 0xFF0000)
				GUICtrlSetState($Input, $GUI_FOCUS)
			Else
				GUICtrlSetBkColor($Input_Border, 0x666666)
				GUICtrlSetState($Input, $GUI_FOCUS)
			EndIf
    EndSwitch
WEnd

Alles anzeigen

Einfach und Pragmatisch. Alternativ lässt sich das Label auch - wie Kana geschrieben hat schlicht disablen. Warum also das Script unnötig mit der kompletten GDI+-Library aufblähen?

CRouch

Mist, Entschuldigung. Den Hinweis von Kana die Label zu disablen habe ich gekonnt überlesen.
Nun funktioniert es wie ich es mir vorgestellt habe. Danke!

AutoIt

#include <GUIConstants.au3>


$gui = GUICreate("", 300, 200)
GUISetBkColor (0xFFFFFF)
$Input_Border1 =GUICtrlCreateLabel("", 9, 9, 192, 22)
GUICtrlSetState(-1,$GUI_DISABLE)
$Input_Border2 =GUICtrlCreateLabel("", 9, 39, 192, 22)
GUICtrlSetState(-1,$GUI_DISABLE)
$Input_Border3 =GUICtrlCreateLabel("", 9, 69, 192, 22)
GUICtrlSetState(-1,$GUI_DISABLE)


GUICtrlSetBkColor($Input_Border1, 0x666666)
GUICtrlSetBkColor($Input_Border2, 0x666666)
GUICtrlSetBkColor($Input_Border3, 0x666666)






$Input1 = GUICtrlCreateInput("", 10,10,190, 20, -1, $WS_EX_TOOLWINDOW)
GUICtrlSetBkColor($Input1, 0xDEDEDE)


$Input2 = GUICtrlCreateInput("", 10,40,190, 20, -1, $WS_EX_TOOLWINDOW)
GUICtrlSetBkColor($Input2, 0xDEDEDE)


$Input3 = GUICtrlCreateInput("", 10,70,190, 20, -1, $WS_EX_TOOLWINDOW)
GUICtrlSetBkColor($Input3, 0xDEDEDE)






$Button = GUICtrlCreateButton("Absenden", 9, 100, 100, 21)
GUISetState()




While 1
    $msg = GUIGetMsg()
    Switch $msg
        Case $GUI_EVENT_CLOSE
            Exit
		Case $Button
			If GUICtrlRead($Input1) = "" Then
				GUICtrlSetBkColor($Input_Border1, 0xFF0000)
				;GUICtrlSetState($Input1, $GUI_FOCUS)
			Else
				GUICtrlSetBkColor($Input_Border1, 0x666666)
				;GUICtrlSetState($Input1, $GUI_FOCUS)
			EndIf


			If GUICtrlRead($Input2) = "" Then
				GUICtrlSetBkColor($Input_Border2, 0xFF0000)
				;GUICtrlSetState($Input2, $GUI_FOCUS)
			Else
				GUICtrlSetBkColor($Input_Border2, 0x666666)
				;GUICtrlSetState($Input2, $GUI_FOCUS)
			EndIf


			If GUICtrlRead($Input3) = "" Then
				GUICtrlSetBkColor($Input_Border3, 0xFF0000)
				;GUICtrlSetState($Input3, $GUI_FOCUS)
			Else
				GUICtrlSetBkColor($Input_Border3, 0x666666)
				;GUICtrlSetState($Input3, $GUI_FOCUS)
			EndIf
    EndSwitch
WEnd

Alles anzeigen

**chesstiger**

Auch wenn schon eine Lösung gefunden wurde... Ich habe Anfang des Jahres ein ähnliches Problem gehabt, es ging damals auch darum, eine Benutzereingabe zu validieren. In diesem Zuge ist auch meine InputFilter-UDF entstanden, der ein oder andere mag sich an sie erinnern. Bevor ich die geschrieben habe, hatte ich einen anderen Ansatz verfolgt: Manuelle Kontrolle und eine Markierungs-UDF, genau das, was hier beschrieben wird. Im Endeffekt brauchte ich sie dann doch nicht, da der InputFilter alles zu meiner Zufriedenheit abfing. Aber vielleicht kannst du ja damit was anfangen.
Das ganze arbeitet über Subclassing vom Eltern-Fenster des Controls. Der Rahmen wird bei WM_PAINT mittels GDI+ gezeichnet. Die UDF steht - wie im Header beschrieben - unter der LGPLv3. Dokumentation findet man in der HTML-Datei.

Runa

@Chessi Das hat aber wieder den Nachteil dass man die komplette GDI+ Library mitschleppen muss. Jeder Include wird vollständig mitgenommen. Und GDI+ ist nicht gerade Klrin und hat noch den einen oder anderen Include selbst…

**autoBert**

Schon mal etwas vom Au3Stripper gehört, der sollte standardmäßig vor dem Compilen benutzt werden. Ich empfehle Parameter /soi (same as /so but will leave master script untouched."

Runa

Doch habe ich - und er hat von insgesamt 10 Scripts 7 nach seinem "werken" zerstört. Wenn er das bei dir nicht hat: Glückwunsch - nutze ihn.

Ich bleibe dabei von Haus aus nicht "the biggest possible method" zu verwenden, sondern die pragmatischste, die für den Nutzer keinerlei Nachteile hat. Eben sowas wie ein deaktiviertes Label als Rahmen hinter dem Input, um den Rahmen einfärben zu können, statt GDI+ auszupacken. (1MB alleine für deren Bibiliothek... zum Vergleich: Die WinAPI hat gerade mal 0.8 MB - mithalten kann dort nur ein kommerzielles Produkt (VK: >500€) von mir mit fast 1500 Zeilen Code und genau drei Includes - das hat ebenfalls 1MB Größe).

Wenn du weiter diskutieren willst, bitte einen Moderator, diese Unterhaltung in einen seperaten Thread im Offtopic-Bereich zu verschieben.

**chesstiger**

@Bioshade
Du hast zwar recht, aber wenn ich schon einen riesigen Interpreter mitschleppen muss, dann macht das den Braten auch nicht mehr fett.
Außerdem leben wir ja nicht mehr in einer Zeit, in der die Datenverbindung über die Telefonleitung läuft. Ob 1 MB oder 5 MB, das juckt heute keinen mehr. Und meine Methode hat den Vorteil, dass sie sich nahtlos integriert und auch so gedacht ist. Du missbrauchst einfach irgendwelche Controls.
Führt zwar beides zum Ziel, deins sogar schneller... Aber meins ist dafür praktisch die Lehrbuch-Methode.

Aber darum wollen wir uns jetzt nicht streiten. Hauptsache es gibt eine Lösung.

**autoBert**

Zitat von Bioshade

Doch habe ich - und er hat von insgesamt 10 Scripts 7 nach seinem "werken" zerstört. Wenn er das bei dir nicht hat: Glückwunsch - nutze ihn.

Mit Parameter /soi bleibt das Originalskript unangetastet.

Runa

chesstiger :

Naja: Folgendes Szenario - Kunde zieht das Script beim Login. Die Leute fangen alle zwischen 8 und 8 Uhr 5 an. Es sind 180 Mitarbeiter. Da ist das nicht die Frage ob 1MB oder 5MB sondern ob fast ein GB durch das Netzwerk gezogen werden muss, oder ob es gerade mal knapp unter 200MB sind. Und 180 Leute sind noch die eher kleineren Kunden. Klar: Nur das Script alleine ist da noch recht "unproblematisch". Nehmen wir aber mal 4 oder 5 dieser Script-Größen (was nicht unüblich wäre, gerade wenn ThinClients im Betrieb sind) - dann reden wir von 1GB oder 5GB die in maximal 5 Minuten quer durch das Netz gezogen werden, dass so schon belastet wird. So viel hast du nicht mal, wenn alle YouTube aktiv haben.

autoBert:

Dennoch zerstört es ganze Scripte. Den "Tipp" habe ich schon bei Hilfe und Support bekommen.

**chesstiger**

Allerdings geht YouTube auch nicht nur aufs Intranet. Und mit 5 MB ist ein AutoIt-Programm doch immer noch ein Leichtgewicht im Gegensatz zu viel anderer Software. Nimm zum Beispiel mal ein Office-Paket. Aber gut, ich habe bisher noch nie mit einer solchen Infrastruktur gearbeitet. Nur lokale Installationen, die über OPSI beim Starten (höchstens 2 von 30 gleichzeitig) Updates ziehen.