Morng Reiner,

boah äih, da hast Du Dir aber viel Arbeit gemacht, danke dafür

zur Erläuterung: Ich entwickle einen "Assistenten" in einem Formular mit
einem Registersteuerelement, welches 2 Seiten ("Schritte") enthält. Der
Button "weiter" soll von Schritt1 (=Seite1) zu Schritt2 (=Seite2) wechseln.

Reiner Wolff schrieb:
> Moin Michael,
>
>
> Sowas habe ich auch schon mal gehabt. Wenn ich mich recht erinnere hatte
> das bei mir etwas zu tun mit Objektvariablen, die nicht wieder freigegeben
> wurden.
> Trotzdem würde ich erstmal an Deiner Stelle testweise anfangen, das
> Formular neu zu erstellen. Also, neues Formular auf und ein cmdWeiter
> draufpacken, Code für drüberkopieren und ausprobieren.
>
> Ein paar kleine Fragen hätte ich allerdings auch zum Code:
>
>> '-----------------------------
>> Private Sub cmdWeiter_Click()
>> '-----------------------------
>>
>> If bytStep < 5 Then
>> ShowButton "Zurueck", True ' zeigt den Zurück-Button an
>> ShowButton "Weiter", False ' Blendet den Weiter-Button aus
>
> Der Code von ShowButton könnte auch interessant sein. Bei Deinem Problem
> ggf. auch ob die Parameter ByRef oder ByVal übergeben werden.
>
Private Sub ShowButton(ByVal strName As String, byval boolStatus As Boolean)

Me("cmd" & strName).Visible = boolStatus
Me("rec" & strName).Visible = boolStatus
Me("lbl" & strName).Visible = boolStatus

End Sub

Hiermit bilde ich Schaltflächen mit verschiedenen Farben nach. cmd...
ist der (transparente) Button, rec... ein farbiges REchteck und lbl...
die Beschriftung des Buttons.

>> ' With Me
>> ' .Caption = strFormTitle & "Schritt 2 von 2"
>> ' !lblKopf.Caption = vbCrLf & "Eingabe von weiteren Daten ..."
>> ' !tabStaLan.Pages("Schritt2").SetFocus
>> ' !cboPilot.RowSource = "1;Hinz;2;Kunz"
>> ' !cboPilot = vbNullString
>> ' !cboPilot.SetFocus
>> ' End With
>
> Warum wird der Focus hier zweimal woanders hingesetzt?
> Kannst Du Dir das SetFocus ggf. einfach sparen?
>
wenn ich den ersten SetFocus weg lasse, wird das Objekt cboPilot nicht
gefunden.

> Gibt es einen Grund, dass Du mit einem Ausrufezeichen auf die
> Steuerelemente verweist und nicht mit einem Punkt?
> Das betrifft die alte Frage 'dot vs. bang', die von Access leicht
> unterschiedlich gehandhabt werden. Ich habe mir im Laufe der Jahre
> angewöhnt, höchstens beim Zugriff auf Spalten eines Recordsets das
> Ausrufezeichen zu benutzen. Ob das bei Dir irgendwelche Auswirkungen hätte,
> weiß ich allerdings nicht.
>
Ich habe "gelernt": was ich selbst erzeugt habe mit "!" zu verweisen und
auf Eigenschaften bzw. Methoden mit "."
Es hat auch keine Auswirkungen.

> Nächste Frage wäre, welche dieser Zeilen für das Problem zuständig ist.
> Tritt es auch auf, wenn Du nur With und End With wieder einkommentierst,
> ohne dass tatsächlich Befehle dadrin ausgeführt werden, ect.?
>
Ich habe allmählich den Eindruck gewonnen, dass diese Sub
cmdWeiter_Click gar nicht ursächlich für den Fehler ist ;-) Ich bin
deshalb auf der Suche nach einer Möglichkeit, so eine Art "Trace" oder
"Callstack" zu bilden, mit dessen Hilfe ich feststellen kann, welche
Routinen nach und nach durchlaufen werden. Kennst Du vielleicht so eine
Möglichkeit (AddIn oder was auch immer)?

>> Else
>>
>> Me.Visible = False
>
> Wird dieser Dialog vielleicht mehrfach aufgerufen und verbleibt auf Grund
> dieser Zeile dann im Arbeitsspeicher, so dass Du ein Problem mit mehreren
> Instanzen dieses Formulars bekommst?
>
> Ich hätte ansonsten hier entweder
> Me.Hide
> oder
> Unload Me
> erwartet.
>
>> End If
>> End Sub
Von mir "geplant" ;-) soll der Code nur einmal durchlaufen werden, aber
wer weiß das schon

>
> Hast Du ansonsten schonmal getestet, ob das Problem nur auf Deinem Rechner
> besteht oder ob es auch auf anderen Maschinen auftritt?
> (Falls Du keine Testmöglichkeit hast, kannst Du mir die DB gepackt als PM
> schicken.)
>
Ich werde es mal auf einem anderen Rechner versuchen.
Also schon mal vielen Dank für Deine Mühe

Gruß aus Franken
Michael

Moin Michael,

*Michael König* schrieb:
> boah äih, da hast Du Dir aber viel Arbeit gemacht, danke dafür

gerne.

> Reiner Wolff schrieb:
>>> If bytStep < 5 Then
>>> ShowButton "Zurueck", True ' zeigt den Zurück-Button an
>>> ShowButton "Weiter", False ' Blendet den Weiter-Button aus
>> Der Code von ShowButton könnte auch interessant sein. Bei Deinem Problem
>> ggf. auch ob die Parameter ByRef oder ByVal übergeben werden.
> Private Sub ShowButton(ByVal strName As String, byval boolStatus As Boolean)
>
> Me("cmd" & strName).Visible = boolStatus
> Me("rec" & strName).Visible = boolStatus
> Me("lbl" & strName).Visible = boolStatus
>
> End Sub

Ich hatte mal (für mich) unerklärliche Abstürze, die ich nur dadurch
beheben konnte, indem ich solche Steuerelementzugriffe umgeschrieben habe
in:
Dim str As String
str = "cmd" & strName
Me.Controls(str).Visible = boolStatus
str = "rec" & strName
Me.Controls(str).Visible = boolStatus
str = "lbl" & strName
Me.Controls(str).Visible = boolStatus

Ich weiß zwar nicht warum (nicht schon vorher), aber danach funktionierte
mein Code damals.

>>> ' With Me
>>> ' .Caption = strFormTitle & "Schritt 2 von 2"
>>> ' !lblKopf.Caption = vbCrLf & "Eingabe von weiteren Daten ..."
>>> ' !tabStaLan.Pages("Schritt2").SetFocus
>>> ' !cboPilot.RowSource = "1;Hinz;2;Kunz"
>>> ' !cboPilot = vbNullString
>>> ' !cboPilot.SetFocus
>>> ' End With
>> Warum wird der Focus hier zweimal woanders hingesetzt?
>> Kannst Du Dir das SetFocus ggf. einfach sparen?
> wenn ich den ersten SetFocus weg lasse, wird das Objekt cboPilot nicht
> gefunden.

Solche "Probleme" kenne ich bei der Text-Eigenschaft, die gerne mal den
Focus haben möchte. Hier klingt das für mich allerdings danach, als ob Du
auf cboPilot nicht richtig verweist.
Du hast vermutlich ohne das SetFocus versucht so zu verweisen:
!cboPilot.RowSource = "HinzKunz"
versuch's mal mit
.tabStaLan.Pages("Schritt2").cboPilot.RowSource = ...

Ich habe schon viele Probleme mit SetFocus-Varianten gehabt und meide den
Befehl, wo immer ich kann. Das Register ließ sich imho auch ohne SetFocus
wechseln.

>> Nächste Frage wäre, welche dieser Zeilen für das Problem zuständig ist.
>> Tritt es auch auf, wenn Du nur With und End With wieder einkommentierst,
>> ohne dass tatsächlich Befehle dadrin ausgeführt werden, ect.?
> Ich habe allmählich den Eindruck gewonnen, dass diese Sub
> cmdWeiter_Click gar nicht ursächlich für den Fehler ist ;-) Ich bin
> deshalb auf der Suche nach einer Möglichkeit, so eine Art "Trace" oder
> "Callstack" zu bilden, mit dessen Hilfe ich feststellen kann, welche
> Routinen nach und nach durchlaufen werden. Kennst Du vielleicht so eine
> Möglichkeit (AddIn oder was auch immer)?

Ich habe keine AddIns zur Codeerzeugung im Einsatz, aber es könnte sein,
dass die MZTools sowas können. Vielleicht hilft Dir da auch die CodeGenie
da weiter. Bei beiden könnte man nach sowas mal suchen.

Ansonsten hilft eine globale Variable
Public DebugMode As Boolean
gepaart mit jeder Startzeile in jeder Prozedur:
If DebugMode Then Debug.Print /Prozedurname/

Wenn Du dafür ein schönes AddIn gefunden hast, sag bescheid. ;-)

>> Hast Du ansonsten schonmal getestet, ob das Problem nur auf Deinem Rechner
>> besteht oder ob es auch auf anderen Maschinen auftritt?
>> (Falls Du keine Testmöglichkeit hast, kannst Du mir die DB gepackt als PM
>> schicken.)
> Ich werde es mal auf einem anderen Rechner versuchen.

Da fällt mir gerade mal so ein, dass Du sagtest, Du hättest nur 3 Verweise.
Das Tab-Steuerelement ist im Prinzip auch nichts anderes als ein Verweis,
den Du allerdings in den 'Komponenten' in der Toolbox findest und nicht
unter Extras - Verweise.
Da hat es im Laufe des letzten Jahres für VB ein paar kumulative Updates
gegeben, die sehr viele dieser OCX-Dateien ausgetauscht hat.
Schau doch mal nach, welches Steuerelement Du da nutzt und welche Version
die zugehörige Datei hat.

> Also schon mal vielen Dank für Deine Mühe

Na, irgendwie muss man sich doch das Wochenende versauen, oder?

Gruß aus Kiel
Reiner
--
"Wir haben hier keine Zeit zu lesen, was auf dem Bildschirm steht!."

(Ausrede eines Anwenders,
der Probleme mit der Bedienung eines Programmes hatte.)

Hallo Reiner,

Reiner Wolff schrieb:
> Moin Michael,
>
> Ich hatte mal (für mich) unerklärliche Abstürze, die ich nur dadurch
> beheben konnte, indem ich solche Steuerelementzugriffe umgeschrieben habe
> in:
> Dim str As String
> str = "cmd" & strName
> Me.Controls(str).Visible = boolStatus
> str = "rec" & strName
> Me.Controls(str).Visible = boolStatus
> str = "lbl" & strName
> Me.Controls(str).Visible = boolStatus
>
> Ich weiß zwar nicht warum (nicht schon vorher), aber danach funktionierte
> mein Code damals.
>
meiner nicht :-(

> Solche "Probleme" kenne ich bei der Text-Eigenschaft, die gerne mal den
> Focus haben möchte. Hier klingt das für mich allerdings danach, als ob Du
> auf cboPilot nicht richtig verweist.
> Du hast vermutlich ohne das SetFocus versucht so zu verweisen:
> !cboPilot.RowSource = "HinzKunz"
> versuch's mal mit
> .tabStaLan.Pages("Schritt2").cboPilot.RowSource = ...
>
> Ich habe schon viele Probleme mit SetFocus-Varianten gehabt und meide den
> Befehl, wo immer ich kann. Das Register ließ sich imho auch ohne SetFocus
> wechseln.
>
auch getestet, ohne Erfolg

> Ich habe keine AddIns zur Codeerzeugung im Einsatz, aber es könnte sein,
> dass die MZTools sowas können. Vielleicht hilft Dir da auch die CodeGenie
> da weiter. Bei beiden könnte man nach sowas mal suchen.
>
> Ansonsten hilft eine globale Variable
> Public DebugMode As Boolean
> gepaart mit jeder Startzeile in jeder Prozedur:
> If DebugMode Then Debug.Print /Prozedurname/
>
> Wenn Du dafür ein schönes AddIn gefunden hast, sag bescheid. ;-)
>
bis jetzt nix gefunden; auch mit DebugMode kein Ergebnis, die einzelnen
Subs werden schön brav geöffnet und wieder geschlossen.

> Da fällt mir gerade mal so ein, dass Du sagtest, Du hättest nur 3 Verweise.
> Das Tab-Steuerelement ist im Prinzip auch nichts anderes als ein Verweis,
> den Du allerdings in den 'Komponenten' in der Toolbox findest und nicht
> unter Extras - Verweise.
> Da hat es im Laufe des letzten Jahres für VB ein paar kumulative Updates
> gegeben, die sehr viele dieser OCX-Dateien ausgetauscht hat.
> Schau doch mal nach, welches Steuerelement Du da nutzt und welche Version
> die zugehörige Datei hat.
>
Ich hatte heute die Gelegenheit, die Anwendung (abgespeckt) auch auf
Access XP (2002) und Access 2003 zu testen. Überall trat der Fehler auf.
Das Einzige, was zusätzlich zu erfahren war, ist Folgendes: In Access
2003 gibt es nun wohl auch die Aufrufeliste (Call Stack), und dort
konnte ich zwischen den zwei gerade betroffenen Subs eine Zeile mit dem
Text "Kein Basic-Code" entdecken, was immer das heißen mag. Kennst Du
diesen Text? Leider kann ich Dir auch die abgespeckte Testversion nicht
zusenden, der Auftraggeber hat was dagegen ;-)

> Na, irgendwie muss man sich doch das Wochenende versauen, oder?
>
da weiß ich aber Besseres als sich mit Access und ein paar Hirnis herum
zu ärgern. Trotzdem danke

Gruß Michael

Moin Michael,

*Michael König* schrieb:
> Reiner Wolff schrieb:
>> Da fällt mir gerade mal so ein, dass Du sagtest, Du hättest nur 3 Verweise.
>> Das Tab-Steuerelement ist im Prinzip auch nichts anderes als ein Verweis,
>> den Du allerdings in den 'Komponenten' in der Toolbox findest und nicht
>> unter Extras - Verweise.
>> Da hat es im Laufe des letzten Jahres für VB ein paar kumulative Updates
>> gegeben, die sehr viele dieser OCX-Dateien ausgetauscht hat.
>> Schau doch mal nach, welches Steuerelement Du da nutzt und welche Version
>> die zugehörige Datei hat.
> Ich hatte heute die Gelegenheit, die Anwendung (abgespeckt) auch auf
> Access XP (2002) und Access 2003 zu testen. Überall trat der Fehler auf.
> Das Einzige, was zusätzlich zu erfahren war, ist Folgendes: In Access
> 2003 gibt es nun wohl auch die Aufrufeliste (Call Stack), und dort
> konnte ich zwischen den zwei gerade betroffenen Subs eine Zeile mit dem
> Text "Kein Basic-Code" entdecken, was immer das heißen mag. Kennst Du
> diesen Text?

Ja, klar. Der wird in der Aufruferliste (Strg-L) angezeigt, wenn Code in
einer externen DLL (oder OCX) irgendetwas gemacht hat. So ne DLL ist ja ein
Kompilat von zB C++ oder VB oder sonst einer Programmiersprache und damit
kein VBA-Code mehr.

> Leider kann ich Dir auch die abgespeckte Testversion nicht
> zusenden, der Auftraggeber hat was dagegen ;-)

Falls es dem Auftraggeber besser gefällt, kann ich den Auftrag auch
offiziell über meine Firma laufen lassen. Das ein Auftraggeber nicht
möchte, dass seine Datenbank irgendwelchen Privathanseln zugeschickt wird,
kann ich nachvollziehen. Wenn ich helfen kann, kann er auch gerne eine
Rechnung mit Umsatzsteuerausweis und dergleichen kriegen.
Is ja nich so, dat ich sowat nich auch beruflich machen würde.

>> Na, irgendwie muss man sich doch das Wochenende versauen, oder?
> da weiß ich aber Besseres als sich mit Access und ein paar Hirnis herum
> zu ärgern. Trotzdem danke

Ooch, Access ist dafür schon eine Möglichkeit (gibt da ja genug zu tun),
nur Hirnis habe ich dieses Wochenende keine gefunden :-/

Gruß aus Kiel
Reiner
--
Es gibt Zeiten, wo einem alles gelingt. Aber das braucht niemanden zu
beunruhigen. Sie gehen sehr schnell vorüber...

Morng Reiner,

Reiner Wolff schrieb:
> Moin Michael,
>
> Ja, klar. Der wird in der Aufruferliste (Strg-L) angezeigt, wenn Code in
> einer externen DLL (oder OCX) irgendetwas gemacht hat. So ne DLL ist ja ein
> Kompilat von zB C++ oder VB oder sonst einer Programmiersprache und damit
> kein VBA-Code mehr.
>
Roger

> Falls es dem Auftraggeber besser gefällt, kann ich den Auftrag auch
> offiziell über meine Firma laufen lassen. Das ein Auftraggeber nicht
> möchte, dass seine Datenbank irgendwelchen Privathanseln zugeschickt wird,
> kann ich nachvollziehen. Wenn ich helfen kann, kann er auch gerne eine
> Rechnung mit Umsatzsteuerausweis und dergleichen kriegen.
> Is ja nich so, dat ich sowat nich auch beruflich machen würde.
>
Danke für das Angebot, aber ich muss doch versuchen, es irgendwie hin zu
bekommen. Mal sehen, ob ich die DB so "neutralisieren" kann, dass es
keine Einwände mehr gibt.

> Ooch, Access ist dafür schon eine Möglichkeit (gibt da ja genug zu tun),
> nur Hirnis habe ich dieses Wochenende keine gefunden :-/
>
Damit meinte ich u.a. mich selbst als ziemlichen Laien in Sachen Access,
aber ich bin durchaus lernwillig.

Gruß aus Franken
Michael

Hi!

>Vielleicht hilft mir, wenn ich erfahre, womit sich die mso9.dll
>(hauptsächlich) beschäftigt.

Die mso9.dll ist die Microsoft Office Objekt Library für Office 2000.


Wenn der Fehler auftritt, wenn Du das Formular öffnest, dann wäre es
interessant, ob dabei Code abläuft. Wenn ja, dann zeige den mal.

Zeilen kann man auch einzeln Auskommentieren. Nur so kann man dann die Zeile
finden, die das Problem ist.

Was ist denn, wenn Du das Formular nicht auf Dialog eingestellt hast. Kommt
der Fehler dann auch?

Wenn mal in einem Formular der Wurm drin ist, dann kopiert sich der immer
mit. Lösche das Formular und mach es neu. Die Controls kannst Du schon
rüberkopieren. Ich setze dafür immer kurz eine Dummy-Control auf Left/Top 0
vor dem Copy-Past, dann steht, nach dem Einfügen, wieder alles da wo es hin
soll. (Das Dummy-Control löscht man dann wieder.)


Gruss
Oliver

Hallo Reiner,
gerne möchte ich auf Dein Angebot zurück kommen, und Dir eine
"neutralisierte" Fassung der fehlerhaften DB zukommen lassen.
Teilst Du mir bitte mit, wie Du es gerne hättest?
Gruß Michael

Hallo Reiner,
gerne möchte ich auf Dein Angebot zurück kommen, und Dir eine
"neutralisierte" Fassung der fehlerhaften DB zukommen lassen.
Teilst Du mir bitte mit, wie Du es gerne hättest?
Gruß Michael

Hallo Reiner,
gerne möchte ich auf Dein Angebot zurück kommen, und Dir eine
"neutralisierte" Fassung der fehlerhaften DB zukommen lassen.
Teilst Du mir bitte mit, wie Du es gerne hättest?
Gruß Michael

Hallo,

Michael König wrote:

> gerne möchte ich auf Dein Angebot zurück kommen, und Dir eine
> "neutralisierte" Fassung der fehlerhaften DB zukommen lassen.
> Teilst Du mir bitte mit, wie Du es gerne hättest?

Wenn du sie irgendwo hochlaedst, z.B. http://www.file-upload.net/ koennen
sie sich mehrere Leute anschauen.

Gruss - Peter

--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com