("DateField1").setEmpty() springt unerlaubt in eine SUB

[balu]

Hallo ihr Spezialisten und Könner,

diesmal habe ich für mich eine echt extrem unverständlich harte Nuss zu knacken.
Beispieldatei ist im Anhang.

Beim klick auf einen Button im Tabellenblatt soll ein Dialog gestartet werden. Das funktioniert aber diesmal gar nicht wie geplant, und das Makro wird mit folgender Fehlermeldung abgebrochen.

fehler.png (8.54 KiB) 219 mal betrachtet

Okay, so eine Fehlermeldung ist für mich nichts neues. Aber diesmal versteh ich reine weg gar nichts, da mir das verständis wegen der Entstehung der Fehlermeldung einfach fehlt. Also habe ich in der IDE das Makro per Einzelschritt ausgeführt, und etwas sehr merkwürdiges beobachtet.
Ich versuch mal den Ablauf zu beschreiben.

In der Basic-IDE im Modul *Formular* das Makro per Einzelschritt starten.
Als erstes wird die

Code: Alles auswählen

Sub EingabeFormular

gestartet -{steht ganz am Anfang}-. In dieser Sub wird einiges 'initialisiert'. Sie wird aber noch nicht beendet!!
Dann wird die gewünschte Seite eingestellt:

Code: Alles auswählen

oDialog1.Model.Step = 1

Jetzt folgt ein Sprung in die

Code: Alles auswählen

Sub Ruecksetzen

Dort steht in der ersten Zeile

Code: Alles auswählen

oDialog1.getControl("DateField1").setEmpty()

Und nun geschieht das Unfassbare!
Und das ist kein Scherz!

Jetzt springt der Einzelschritt-Anzeiger im gleichem Modul in die

Code: Alles auswählen

Sub KopfDaten

Noch etwas zur Verdeutlichung, um das Unfassbare zu verstehen.
In der Sub Ruecksetzen sollen noch einige weitere Elemente nach dem DateField1 auf .Visible = False gesetzt werden. Doch dazu kommt es erst gar nicht, da der Einzelschritt-Anzeiger beim erreichen von

Code: Alles auswählen

oDialog1.getControl("DateField1").setEmpty()

sofort, also unverzüglich in die andere Sub springt. Und wenn der Einzelschritt-Anzeiger in der nicht gewollten Sub ist, wird die bis zu der Zeile wo die Fehlermeldung zustande kommt auch abgearbeitet.

Wie ist das möglich das ein Sprung in eine andere Sub initialisiert und ausgeführt wird, ob wohl es keinen direkten Makro programmierten dementsprechenden Befehl dafür gibt?
Ich muss ergänzend dazu sagen, das dem DateField1 bei
- Ereignisse
- Text modifiziert
die Sub KopfDaten zugeordnet ist.

Und wenn ich das Makro wie geplant über den Button im Tabellenblatt starte, dann kommt es an genau der gleichen Stelle zu der eingangs gezeigten Fehlermeldung.


Und nun leg ich noch eins oben drauf, nein, besser gesagt sogar zwei!

1.)
Wenn ich das DateField1 auskommentiere, dann wird die

Code: Alles auswählen

Sub Ruecksetzen

ordnungsgemäß bis zum Ende ausgeführt und es erfolgt der geplante Rücksprung in die

Code: Alles auswählen

Sub EingabeFormular

Dort werden dann noch ein paar weitere Initialisierungen durchgeführt, und erst dann kommt es zu

Code: Alles auswählen

oDialog1.execute

2.)
Wenn ich dem DateField1 das zugeordnete Makro lösche, und im Makro die DateField1-Zeile NICHT auskommentiere, dann gibts auch keine Fehlermeldung. und der ganze Prozess wie bei 1.) beschrieben läuft auch jetzt ab.

Das auskommentieren, bzw. das zugeordnete Makro für DateField1 löschen, sind leider keine brauchbaren Lösungen da ich diese Funktionaltäten brauche.

WinXP, OOo 3.2.1 & 3.3.0

- Was zum Donnerwetter ist da nur los?
- Weiß einer von euch wie ich das Problem beseitigen kann?
- Kann mir überhaupt jemand helfen?
- Könnt ihr das unter anderen Bedingungen bestätigen, Betriebssystem und anderes Office?

Ich bedanke mich schon mal für eure Bemühungen. Und diesmal ist es ja echt eine Mühseelige Arbeit.

Freue mich auf eure Antworten.



Gruß
balu

[Stephan]

Und nun geschieht das Unfassbare!
Und das ist kein Scherz!

Für DateField1 ist für das EReignis "Text modifiziert" das Makro Kopfdaten() zugewiessen.

Und diesmal ist es ja echt eine Mühseelige Arbeit.

Nö.


Gruß
Stephan

[Stephan]

Ich muss ergänzend dazu sagen, das dem DateField1 bei
- Ereignisse
- Text modifiziert
die Sub KopfDaten zugeordnet ist.

Soweit hatte ich jetzt garnicht gelesen, aber wenn ich diese ZUweisung entferne startet bei mir der Dialog normal (OOo3.3.0), deswegen hielt ich diese ZUweisung für die Ursache.

WEitersuchen ist jetzt schwierig weil ich ja keinen FEhler mehr bekomme


GRuß
Stephan

[Stephan]

Das auskommentieren, bzw. das zugeordnete Makro für DateField1 löschen, sind leider keine brauchbaren Lösungen da ich diese Funktionaltäten brauche.

Vorschlag 1:
Du mußt eine Variable definieren die prüft was gerade abgearbeitet wurde bevor das Text-Ändern-Ereignis eingetreten ist und dann je nach WErt dieser Variable das Text-Ändern-Ereignismakro nur bei Bedarf ausführen.

Grob gesagt:
schreib in den KOpf

Code: Alles auswählen

Dim nichtstun 

Dann in:

Code: Alles auswählen

Sub EingabeFormular
  nichtstun = 1
  Monatsvariablen 

  '...

  Schaltflaeche_einstellen
  nichtstun = 0
  oDialog1.execute
End Sub

und in:

Code: Alles auswählen

sub KopfDaten
  If nichtstun = 1 Then
    Exit Sub
  End If
  DlgModl = oDialog1.Model.getByName("ListBox1")
  '...

Reicht das insgesamt schon?


Gruß
Stephan



Gruß
Stephan

[balu]

Hallo Stephan,

Wahnsinn wie schnell Du geantwortet hast. Das hatte ich zu dem Zeitpunkt gar nicht mitbekommen.

Eins hab ich jetzt in Bezug auf meine Frage dazu gelernt.

Wie ist das möglich das ein Sprung in eine andere Sub initialisiert und ausgeführt wird, ob wohl es keinen direkten Makro programmierten dementsprechenden Befehl dafür gibt?

Ich beantworte jetzt selber mal meine Frage.
Die Zuweisung eines Makros für ein Dialog-Element, und folglich wohl hochstwahrscheinlich auch für ein Formular-Element, beziehen sich nicht immer nur auf das dementsprechende Element welches man im Dialog oder im Formular sieht, sondern auch auf den Makro-Code.

Oder anders ausgedrückt.

Die Auswirkung eines zugewiesenen Makros bewirkt nicht nur im Sichtbaren Element, sondern auch im Makro selber bestimmte Aktionen. So wie in diesem "ungünstigen" Falle.

Na ja, zumindest so, oder so ähnlich. Besser kann ich es momentan nicht erklären, aber ich habe es vom Prinzip her jetzt für mich verstanden.

Du mußt eine Variable definieren die prüft was gerade abgearbeitet wurde bevor das Text-Ändern-Ereignis eingetreten ist und dann je nach WErt dieser Variable das Text-Ändern-Ereignismakro nur bei Bedarf ausführen.

Dieser Lösungsvorschlag ist einfach und gut, und wird auch von mir übernommen. Zumal er mit einem extrem minimalem Arbeitsaufwand erledigt ist. Die Alternative die mir im Traum so umhergeisterte, gefiel mir überhaupt nicht. Ein paar kleine Subs erstellen, und diese bei den Ereignissen z.B. für Fokus oder Maus oder ähnlichem zuweisen und die momentanige löschen. -{brrrr, da schauerts mir}-


Nur gut das ich mit Einzelschritt gearbeitet hatte, denn sonst wäre mir wohl die Entstehung zu der Fehlermeldung ein Rätsel geblieben.


Stephan ich Danke dir vielmals.



Gruß
balu