Office: Einsatz von ActiveX-Steuerelementen

Servus Marsu,

deine Lösung mit UFO ist gudi, der Nachteil ist, der Fokus vom HF wird verlassen und somit wird der aktuelle Datensatz gespeichert, was nicht immer gewollt ist.

Da bin ich schon öfters drauf reingefallen, dachte mir ne schöne allgemeine lösung auszulagern und dann....*boah

Allerdings, eine andere Lösung habe ich momentan hier nicht beizutragen *redface.gif*

Gruß
JPA

 

Hallo miteinander,

nun habe ich mich voller Optimismus auf die Lösung mit dem SpinLabel aus der FM20.DLL gestürzt und muss leider feststellen,
dass dieses Control auf dem Zielrechner überhaupt nicht vorhanden ist, weißer Fleck im Formular. *frown.gif*
Somit gibt es auch keine Fehlermeldung, weder im Formular noch beim Start der Anwendung.

Der Verweis ist gesetzt und ist sogar in der neuen Umgebung umgesetzt worden, soweit ist alles OK.
Woran kann denn das nun schon wieder liegen - any ideas?

 

Ich kenne nur den SpinButton, kein Spinlabel *wink.gif*

Die fm20.dll ist seit Urzeiten Bestandteil von Officeanwendungen.
Auch den SpinButton gibt's mid. seit Off 95.

Um auszuschließen, dass dein Formular an sich eine Macke hat:
Kannst du einen SpinButton 'sichtbar' in einem neuen Formular verwenden?

 

Hi,

du hast recht, da habe ich mich vertan.

Klar gibt es die (bzw. eine) FM20.DLL auf dem Zielrechner und ich schrieb ja auch, dass der Verweis korrekt angepasst wurde (von C:Windows\System32\ nach C:\Windows\SysWow64\) aber das Control im Formular ist nicht sichtbar, ein weißer Fleck wie gesagt.

Auch ein Test mit einem neuen Formular brachte kein anderes Ergebnis. Ich verstehe das nicht, jahrelang gab es hiermit kein Problem. *confused.gif*

 

Hallo
wie ich schon gesagt habe evtl.
hast Du auf diesem PC in der Registery ein Proble mit
Com oder/und ActivX Komponenten

ich habe es jedoch nicht so gesagt, sondern auf eine mögliche Lösung hingewiesen *wink.gif*

dieser Fehler müsste man nur einmal Korigieren nicht immer wieder.

 

\@Ruedi:
Es handelt sich nicht nur um einen Rechner, es sind hunderte, die davon betroffen sind.
Wie gesagt, Registry-Eingriff kommt nicht in Frage, aber dennoch Danke fürs Mitdenken.

@all:
Aber ich konnte mich inzwischen mit der Label-Lösung von Marsu anfreunden (-> vielen Dank dafür!) und das Thema ist für mich erledigt.
Auch wenn ich schrecklich gern eine nachvollziehbare Erklärung gefunden hätte...

Nochmals vielen Dank an alle Beteiligten!

 

ah, dann kann es doch nur ein registrierungsproblem sein, entweder auf dem Entwicklungsrechner oder auf den Ziel-Rechner.

Daher der Vorgeschlagene Test auf den zielrechner testhalber in einem neuem Formular das Element einzufügen (geht natrülich nur wenn kein Runtime-Version).

Es kann auch am Entwicklungsrechner liegen, das dort die Registrierung ne Problem hat, oder die Version der DLL-Datei höher ist als die der Zielrechener usw....

Oder an beides :-)

Vielleicht liegt die Ursache an einem MS-Update...

Gruß
JP

 

Hallo Anne,
mich würde interessieren ob sich das Phänomen auf den Spinbutton beschränkt.
Hast du ausprobiert, ob z.B. ein Image oder eine Scrollbar der Formsklasse gleiche Probleme bereitet?

Ist es richtig, dass du eine Access 97 Anwendung auf einem 64 bit Rechner (Win7?) laufen lässt?

 

Hallo noch einmal,

möglich bis wahrscheinlich, aber wie klärt man das auf?

Geht nicht, da Ausführung in der Runtime-Version.

Gut möglich, aber wie lässt sich die Ursache des Problems einkreisen?

Die Idee kam mir auch schon und wäre eine gute Erklärung dafür, dass es bislang funktioniert hat.

Nein, das habe ich nicht und ich mache mir auch wenig Hoffnung, dass andere Controls besser funktionieren könnten.
Außerdem hilft mir das wohl auch nicht weiter.

Ja, so ist es, und das funktioniert auch sehr gut, so lange man Access 2010 nicht benutzt.

 

Schau dir doch mal die versionnr. der DLL-Datei auf deinem Etnwicklungsrechner an und die von einem Zielrechner.
Wenn auf deinem Entwiscklungrechner höher, dann unreg diese, kopiere die von der runtime version rein und reg diese dann.
Anschließend setzt du dein control erneut ins formular ein und dann beten das es geht *grins

So habe ich mein problem mit mscomctl.ocx auf meinem Entwicklungsrechner (der war auch zu neu) gelöst.
Gruß
JPA

 

Ja, so ist es, und das funktioniert auch sehr gut, so lange man Access 2010 nicht benutzt.

Auf welcher Runtime lauft die Anwendung? Nutzt du nur die 97er oder auch höhere RT-Versionen?

 

Hallo
da zu

möglich das Dir meine kleine MDB dabei Hilft die ich einmal geschrieben
habe lege sie in den Anhang
öffne nur den bericht.

lasse sie auf den unterschiedichen PC laufen und sehe dir die unterschiede an *wink.gif*

dann bekommst Du so was

 

Hallo @all.

Die Version auf dem Entwicklungs-PC ist die niedrigere bzw. ältere, ebenso wie die Windows-Version.
Das halte ich übrigens seit Jahren für eine erfolgreiche Strategie, um die von mir entwickelten Anwendungen auf unterschiedlich konfigurierten Systemen (Windows/Office/???) einsetzen zu können. Weshalb ich auch lange Zeit (und überwiegend immer noch) bei Access 97 und der damit verbundenen Developer Edition hängen geblieben bin.

Das Paket wird ausschließlich mit der A97-er Runtime ausgeliefert.

Vielen Dank dafür, das werde ich sicherlich mal gebrauchen können. Aber im aktuellen Fall handelt es sich (wie bereits mehrfach erwähnt!) um eine wirklich große Zahl von Anwendern, die kann ich nicht alle "abklappern".

Ich hatte versucht, die Auskunft "wo läuft was seit wann nicht mehr oder vielleicht immer noch" per Rund-Email abzufragen, habe aber nur ein geringes Feedback erhalten und ehrlich gesagt auch kein großes Vertrauen in die Qualität der Antworten. Daraus lässt sich also auch nicht wirklich etwas herleiten.

Die Erfahrung, dass man besser auf ActiveX-Steuerelemente verzichten sollte, hatte ich bereits in meinen Anfängen mit Access gemacht. Dabei bleibt es dann wohl. Auch wenn es zwischenzeitlich (ca. 10 Jahre lang) zumindest mit dem hier vorgestellten Beispiel scheinbar problemlos funktioniert hat.

...ihr merkt es wohl, es bleibt ein gewisses Frustgefühl. *wink.gif*