[gelöst] "Keine Rückmeldung" eines Form in Windows7 ... Suche Lösungsansatz

[Kolumbus]

Hallo Gemeinschaft,

ich bin gerade dabei eine Anwendung unter Windows7 zu testen. Dabei gibt es Probleme an einer Stelle, an der es unter Windows XP bisher keine (spürbaren) Probleme gab:

Hintergrundinfo: Aus einem Hauptformular wird, nach Klick auf einen Menüpunkt, ein weiteres Formular instanziiert und angezeigt. Auf diesem neuen Formular gibt es ein TPanel, auf dem ein TButton platziert ist. Ein Klick auf diesen Button bewirkt die Anzeige eines vorher ausgeblendeten Formularteils (mittels Erhöhen des Form-Heigth-Wertes). Dies wird in einer Funktion realisiert, welche innerhalb der Button-Click-Methode aufgerufen wird. Vorher müssen jedoch einige Vorbereitungen getroffen werden (Initialisierung des ausgeblendeten Bereiches), welche ebenfalls in der Button-Click-Methode stattfinden.

Problemeingrenzung: Ich habe mittels MessageBoxen die Click-Methode unter Windows7 durchgesteppt, bis das Formular hängen bleibt. Ist vielleicht nicht der beste Weg, aber es half mir das Problem bis zu folgenden Codezeilen zu verfolgen:

// aus ButtonXYZClick(...)

pHints= ( (bool)Target ? HintListB : HintListA);							// Zeiger auf TStringList mit Hinweistexten
for(i= PnlKennWerte->ControlCount - 1; i > -1; --i){						// Loop (Panel-Controls KL-Werte):
	if((pTmpEdt= dynamic_cast<TEdit*>(PnlKennWerte->Controls[i])) == NULL)	// Zeiger auf Edit-cast erfolglos:
		continue;															// nächster Durchlauf
	pTmpEdt->Hint= pHints->Strings[pTmpEdt->Tag];							// Hinweis zuordnen
	while(pTmpEdt->Text.Pos(",") < 4) pTmpEdt->Text= " " + pTmpEdt->Text;	// angezeigten Wert nach rechts verschieben
}

Nun habe ich keine Ahnung, wo ich anfangen soll das Problem weiter einzugrenzen. Hat eventuell jemand einen Hinweis diesbezüglich für mich???

MfG

Edit: [gelöst]-Tag im Thread-Titel ergänzt.

[Th69]

Könnte es sein, daß deine while-Schleife eine Endlosschleife ist (denn wenn kein Komma gefunden wird, dann gibt Pos() ja -1 zurück und -1 < 4 ?

Edit: oder gibt Pos() 0 zurück? Ich weiß es nicht mehr - aber auch 0 < 4

[Kolumbus]

Hallo Th69,

Danke für die Anregung. Die Edit-Felder werden vorher zwingend mit Strings gefüllt, welche ein "," enthalten. Dies geschieht direkt vor dem geposteten Code mittels FloatToStrF(<String mit Komma>, ffFixed, 6, 3);. Ich habe mir sicherheitshalber in W7 den Inhalt der Edits mal per MessageBox() ausgeben lassen und siehe da: Es steht ein "." statt einem "," Komma im String... Damit handelt es sich bei meinem while-Konstrukt tatsächlich um eine Endlosschleife... ...zu dumm!
Also werd' ich jetzt mal den DecimalSeparator setzen. Ist natürlich recht aufwändig jetzt für die gesamte Anwendung zu prüfen, wo der DecimalSeparator überall gesetzt werden muss.
Es gibt ja sicherlich einige Funktionen, die den DecimalSeparator wieder auf Betriebssystemeinstellung setzen???
Oder sollte ich besser in meiner gesamten Anwendung "," und "." als DecimalSeparator zulassen?

MfG

[Kolumbus]

Ich nochmal. Da es sich bei den while-Schleifen um Vorgänge zur rechtsbündigen Textausrichtung in TEdits handelt, habe ich für die Laufbedingung jetzt einen Vergleich mit .Length() anstelle .Pos(",") gewählt. Da die Edits eine Schriftart mit konstanter Zeichenbreite nutzen, ist das kein Problem. Somit besteht nicht mehr die Gefahr einer eventuellen Endlosschleifigkeit ( ).

Was mich in diesem Zusammenhang verwundert: Ich habe im Test-Windows 7 (64bit Professional) mal nach den Einstellungen geschaut und es ist das Komma als Dezimaltrennzeichen eingestellt. Warum in meiner Anwendung dann ein Punkt genutzt wurde, ist mir schleierhaft... Ich habe jetzt im FormShow() meines Main-Form den DecimalSeparator explizit auf Komma gesetzt, weitere Tests werden zeigen, ob das ausreicht.

MfG

[Jansen]

Kolumbus schrieb:

[...] zur rechtsbündigen Textausrichtung in TEdits [...]

Da gibt es m.E. einen FAQ-Eintrag. Man muss zwar eine eigene Komponente ableiten, das erscheint mir aber trotzdem effektiver als die obigen Verrenkungen.