MainMenu unsichtbar nach Update auf XE10.2.2

[norwegen60]

Hallo,

ich habe am Wochenende von XE10.2 auf XE10.2.2 upgedatet. Ich habe zwei Anwendung ohne Änderungen einfach neu kompiliert.
Eine Anwendung funktioniert einwandfrei.
Bei der zweiten ist auf manchen Rechnern das MainMenu unsichtbar.
Bei manchen Rechnern wurde es nach mehreren Starts sichtbar, bei manchen war es von Anfang an sichtbar.
Die ShortKeys, die manchen Einträgen hinterlegt sind, funktionieren überall.
Das MainMenu ist per IDE angelegt und im ganzen Prpgramm gibt es keinen Zugriff auf MainMenu1. Es müsste also auf allen Rechnern gleich gehandhabt werden.


Kennt jemand das Problem und hat eine Lösung oder einen Lösungsansatz?

Vielen Dank
Gerd

[hoika]

Hallo,
ist das wirklich immer die gleiche Installation?

Erst mal:
Minimal-Beispiel (neues Projekt) erzeugen
und auf den entsprechenden Rechner testen.

[Rollo62]

Könnte das eventuell auch an Win10 1709 Update liegen ?
Ich habe sowas ähnliches schon bei anderen Programmen, z.B. Tobit David, gesehen,
wo Fenster nicht mehr sichtbar oder einfach weiss sind, erst nach Pgn-Update sind sie wieder da.

Rollo

[Uwe Raabe]

Sind die Laufzeit-Themes in dem Projekt aktiv? Es häufen sich in letzter Zeit die Fälle, bei denen Programme ohne aktive Laufzeit-Themes massive Darstellungsprobleme haben.

[norwegen60]

Zitat:

Zitat von Uwe Raabe (Beitrag 1390862)

Sind die Laufzeit-Themes in dem Projekt aktiv?

Wenn die Einstellung Projekt - Optionen - Anwendung gemeint ist. Dort ist der Haken bei "Laufzeit-Themes aktivieren" gesetzt, aber ausgegraut, da als Manifestdatei "Benutzerdefiniert" gesetzt ist. Als Manifest ist dann None angegeben. Setze ich die Auswahl auf "Automatisch erzeugen" geht das Hauptfenster noch auf. Bei einigen Child-Fenstern bekomme ich dann aber Exceptions. Habe nie was mit den Themes gemacht. Werde es mir anschauen woher die Exceptions kommen. Auf die schnelle lande ich mit dem Debugger im CPU-Fenster.

Zitat:

Zitat von hoika (Beitrag 1390841)

ist das wirklich immer die gleiche Installation?.

Alle Rechner rufen die gleiche EXE direkt in Netzwerk auf. Die wenigen INI-Daten, die benötigt werden, liegen im Programmverzeichnis. Was ich aber mal prüfen kann. Persönliche Einstellungen, z.B. letzte Fensterposition werden in der Registry gepeichert. Ich lösche am Montag mal den kompletten Registry-Pfad.
Und wie schon gesagt: Eine andere Anwendung funktioniert einwandfrei.

[Luckie]

Und was passiert, wenn die Exe lokal auf den betreffenden Rechner gestartet wird? Eventuell bereitet das Starten über das Netzwerk Probleme.

[norwegen60]

Zitat:

Zitat von Luckie (Beitrag 1390912)

Und was passiert, wenn die Exe lokal auf den betreffenden Rechner gestartet wird?

Drei Varianten:
1. Citrix: Bisher keien Probleme bekannt
2. Lokale Installation: Ca. 60% arbeiten korrekt
3: Start vom Netzlaufwerk: Auf 2 Rechnern geht es, bei 8 geht es nicht

Bin aber nicht sicher, ob das Zufall ist. Im Moment weiß ich auch nicht, welche mit Win7 und welche mit Win 10 laufen

Auf meinem Entwickler-PC (Win10) hatte ich folgendes Verhalten:

• Keinerlei Problem mit der auf dem PC kompilierten Version
• Kopieren dieser Version aif Netzlaufwerk und Start vom Netlaufwerk => ohne Menü
• Kopieren dieser Version auf lokales Laufwerk => mit Menü
• Nach mehreren Wechseln plötzlich auch Start aus dem Netz mit Menü.
• Danach klappte es bei mir immer mit Menü
• Wie gesagt gibt es aber auch Fälle, wo der Start vom lokalen Laufwerk immer ohne Menü erfolgt

Werde am Montag die aktuellen Sources mit XE10.2 kompilieren und Testen ob es dann wieder bei allen klappt. Rückspielen der Vorversion hat Problem überall behoben.

[Rollo62]

Zitat:

1. Citrix: Bisher keien Probleme bekannt
2. Lokale Installation: Ca. 60% arbeiten korrekt

Exakt, kann ich bestätigen.
Ich rede jetzt nicht von Delphi Anwendungen, aber ziemlich massive Probleme auf lokalen Rechnern mit Win10 Creators Fall Update und diversen Programmen.
Citrix läuft gut, weiss aber im Moment gar nicht welche Windows-Version das ist.

Nach Updates der Programme war es dann aber oft OK, habe jetzt nicht gecheckt womit die entwickelt wurden (David Tobit, FoxitReader, um mal zwei zu nennen).

Rollo

[norwegen60]

Hallo,

nach einiger Sucherei habe ich herausgefunden, wie man das unsichtbare MainMenu erzeugen kann
Man benötigt nur ein MainForm mit einem TMainMenu und folgende zwei Anweisungen

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Form1.WindowState := wsMaximized;
end;

procedure TForm1.FormResize(Sender: TObject);
begin
  miDatei.Caption := 'Test';
end;

Setzt man

Delphi-Quellcode:

wsMaxiMized

schon in der IDE, wird das Menu korrekt angezeigt.

Ich speichere beim Schließen der Anwendung Größe und Lage des Fensters und Öffne die Anwendung beim nächsten Start wieder dort. Es hat eine Zeit lang gedauert, bis ich herausgefunden habe, dass der Fehler nur bei denen auftrat, die die Anwendung im Status Maximized beendet haben.
Der Fehler tritt bei Win7, Win8 und Win10 auf.

Im meiner Anwendung wurde bei Resize die Größe des Fensters angezeigt. Da das aber nur für ein Test war, war es kein Problem die Zuweisung zu löschen. Damit funktioniert die Anwendung wieder einwandfrei.
Sie funktioniert auch einwandfrei, wenn ich die Eingenschaft WindowsState schon in der IDE auf wsMaximized setze. Dann kann ich das Form ohne Probleme in OnCreate auf die letzte Größe ändern.

Hat jemand eine Erklärung?

[Uwe Raabe]

Zitat:

Zitat von norwegen60 (Beitrag 1394046)

Hat jemand eine Erklärung?

Nicht direkt, aber hast du mal gezählt, wie oft das Resize allein durch das Setzen von WindowState oder auch durch das Setzen der Caption (rekursiv) aufgerufen wird?

Das Setzen der Caption löst einen Neuaufbau des Menüs aus. Dazu wird es erstmal gelöscht und dann wieder aufgebaut. Menü weg oder wieder da löst aber eben auch einen Resize-Event aus, was zu diesem rekursiven Aufruf führt.

Schreib die Info lieber in irgendein Label - oder noch besser: verwende ein richtiges Logging (z.B. CodeSite).

[norwegen60]

Ja, ich hatte schon einen Zähler eingebaut. Resize wurde 61x aufgerufen. Ich hätte eigentlich erwartet, dass dieser Effekt auch beim Umschalten von Maximized zu Normal auftritt, aber da war es nur 1x.
Blöd nur wenn so was jahrelang funktioniert und dann plötzlich Probleme macht.
Insgesamt war die Implementation aber unsinnig weshalb sie jetzt draußen ist.

[himitsu]

Zitat:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Form1.WindowState := wsMaximized;
end;

Du greifst schon jahrelang von innerhalb der Klasse auf vielleicht deren globale Variable drauf zu, anstatt auf Self? :shock:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1394064)

Du greifst schon jahrelang von innerhalb der Klasse auf vielleicht deren globale Variable drauf zu, anstatt auf Self? :shock:

Das ist in der Tat schon echt böse, aber Delphi fängt das netterweise dadurch ab, daß die Instanz bereits vor dem Aufruf von Create passend gesetzt wird. Auch wieder so ein Fall, wo Bad Practice schon jahrelang toleriert wird. Irgendwann kommt aber dann doch das böse Erwachen und führt zu Kommentaren wie diesem:

Zitat:

Zitat von norwegen60 (Beitrag 1394054)

Blöd nur wenn so was jahrelang funktioniert und dann plötzlich Probleme macht.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1394066)

aber Delphi fängt das netterweise dadurch ab, daß die Instanz bereits vor dem Aufruf von Create passend gesetzt wird.

Jupp, aber nur bei automatisch erzeugten Forms, welche über Applicataion.CreateForm erzeug werden. Normal ist das nicht und knallen wird es immer, wenn die Form/Komponente mehrfach existiert. :angle:

[norwegen60]

Im Echtcode hatte ich über Self zugegriffen. Nur bei der Ursachensuche und der Reduktion auf das Wesentliche ist mir diese Fehler rein gerutscht.
Eigentlich wirde ich in so einem Fall weder

Delphi-Quellcode:

Self.WindowsState

noch

Delphi-Quellcode:

Form1.WindowsState

sondern nur

Delphi-Quellcode:

WindowsState := wsMaximiced

verwenden.
Mittlerweile ist mir eigentlich auch bewusst, dass die Klasse im Create eigentlich noch gar nicht komplett instanziert sein muss, aber es gibt eben auch Altlasten.

Mir war allerdings nicht bewusst, dass der Zugriff über Form1 nicht zulässig ist. Form1 ist nicht vielleicht, sondern ganz sicher die globale Variable von TForm1. Andernfalls würde dort die korrekte globale Variable stehen.

Aber wie gesagt
1. Zugriff direkt auf WindowsState Eigentlich zu 80% so
2. Zugrif über Self.WindowsState Um deutlich zu machen dass es ein FormVariable ist oder Form1 in einer Funktion(Self) weitergeben wird
3. Zugriff über Form1.WindowsState Kann noch Code aus den Anfängen geben

Der reale Code sah so aus:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  uRegDo.SaveFormPos(self);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  uRegDo.RestoreFormPos(self);
end;

[Uwe Raabe]

Zitat:

Zitat von norwegen60 (Beitrag 1394071)

Form1 ist nicht vielleicht, sondern ganz sicher die globale Variable von TForm1. Andernfalls würde dort die korrekte globale Variable stehen.

Das ist sicher korrekt, aber es ist eben nicht immer

Delphi-Quellcode:

Form1 = Self

! Vielleicht gilt das für deinen aktuellen Code, aber generell kann man von dieser Äquivalenz nicht ausgehen.

[HolgerX]

Hmm..

Zitat:

Zitat von norwegen60 (Beitrag 1394071)

Mir war allerdings nicht bewusst, dass der Zugriff über Form1 nicht zulässig ist. Form1 ist nicht vielleicht, sondern ganz sicher die globale Variable von TForm1. Andernfalls würde dort die korrekte globale Variable stehen.

In meinen Projekten hat nur eine Form eine Globale Var, das Hauptfenster!
Bei allen anderen löschen ich die var als erstes bei Neuanlage.

Alle weiteren Fenster der App werden erst bei Bedarf erzeugt.

Ich habe mich schon immer gewundert, wieso immer alle neu angelegten Formulare oder Datenmodule bei der automatischen Erzeugung angelegt werden.. ;)

[Uwe Raabe]

Zitat:

Zitat von HolgerX (Beitrag 1394076)

Ich habe mich schon immer gewundert, wieso immer alle neu angelegten Formulare oder Datenmodule bei der automatischen Erzeugung angelegt werden.. ;)

Nur, wenn das in den Optionen aktiv ist: