Office: Zeichnen mit GDI32.DLL

Ich beschäftige mich damit einen Assistenten zu erzeugen. Er soll Möglichkeiten bieten Objekte auf ein Formular zu ziehen uvm. (zum Vergleich der Beziehungsassistent).
Grundsätzlich wäre das mit den Controls der MSForms Klasse sehr einfach möglich. Allerdings gibt es dort keine Linien, die ich einfach in einem bestimmten Winkel platzieren kann.
Und sobald ich richtig Zeichnen will, wird eh schon alles ein Problem.

Jetzt habe ich gesehen dass man das mit den API Klassen GDI32 umsetzen könnte.
Unter verschiedenen Umständen werden aber Teile eines Formulars neu gezeichnet und in diesem Bereich verschwinden dann die gezeichneten Elemente. *mad.gif*

So wie ich das sehe müsste ich die WindowMessage abfangen und selbst für das Neuzeichnen sorgen. Bis ich das aber genau Verstehe und alles in eine Klasse packen kann geht aber etwas Zeit drauf.

Vielleicht gibt es eine alternative Klasse oder eine Methode damit Windows selbst für das Neuzeichnen sorgt.

Vielleicht hat jemand Erfahrung mit dem Programmieren von Controls.
Wie funktioniert das dort?

LG Markus

:)

 

Hallo!

Kannst du kurz beschreiben, was dein "Assistent" (=Access-Add-In?) machen soll?
"Objekte auf ein Formular ziehen" kann alles mögliche sein - vor allem verstehe ich dann den Zusammenhang mit "Vielleicht hat jemand Erfahrung mit dem Programmieren von Controls" nicht.
Willst du ein ActiveX mit Visual Studio (.net) erstellen und das dann in einem Access-Formular nutzen?


Ansonsten: wegen "Zeichnen" .. wäre ein Bild als Formularhintergrund für dein Vorhaben nutzbar?

mfg
Josef

 

Bei der Entwicklung eines grafischen Controls überschreibt man üblicherweise die Paint-Methode des Controls und implementiert dort eigene Logik um die visuelle Darstellung des eigenen Controls auf dem Ausgabemedium zu zeichnen.

In Access kannst du keine eigenen Controls im eigentlichen Sinne erstellen. Daher ist der "einfache" Ansatz mit dem überschreiben der Paint-Methode dort nicht möglich. Stattdessen musst du dich dort mittels Subclassing in die MessageQueue des Formulars einklinken und, wie du bereits vermutet hast, selbst die entsprechenden WindowMessages behandeln und für das Neuzeichnen deines Controls sorgen.

Mit VBA ist dies allerdings nicht gerade trivial zu implementieren und alle bisher dokumentierten Lösungswege bringen erhebliche Stabilitätsprobleme während der Entwicklung mit sich. - Nicht unbedingt während der Laufzeit der fertigen Anwendung.

 

Hallo Markus,
leider habe ich noch nicht ganz verstanden, was Du mit Objekten meinst.
Wenn es darum geht, z.B. Linien auf ein Formular zu zeichnen reichen vielleicht Access Bordmittel.

Ich habe mal ein Projekt realisiert, bei dem auf Ersatzteilzeichnungen die Artikelbezeichnungen mit Linien auf die entsprechenden Teile zeigten.
Die Ersatzteilzeichnungen habe ich als Bild in ein Formular geladen und darauf mit der Maus die Linien und Textfelder positioniert.
Die Linien und Textfelder sind unsichtbar auf dem Formular vorhanden. Mit einem Mausklick wird eine Linie (bzw. Textfeld) sichtbar und die Koordinaten werden in einer Tabelle abgelegt.
Beispiel im Anhang.

es grüßt Jens *Smilie

 

Danke für die vielen Rückmeldungen.

Ziel:
Zur Laufzeit mittels Mausaktionen Zeichnen beschreibt es am besten.
Linien, Rechtecke, Kreise Texte einfügen - entfernen. So ähnlich wie in Paint.
Im Hintergrund soll Access aber die Aktionen in Objekte verarbeiten und schlussendlich Datensätze anlegen und das gesamte "Bild" daraus reproduzieren können.

Der Vergleich mit dem Assistenten für Beziehungen war nur, da man auch dort zur Laufzeit grafische Elemente erstellt.
Dazu möchte ich auch in der Lage sein - also kein ActiveX als solches. Das wäre mir zu wenig flexibel - ich möchte es direkt in Access realisieren, da es alles Basis für unterschiedlichste Assistenten dienen soll.

Die Frage war nur - wie das Prinzip bei der Control Erstellung funktioniert.
So wie ich das verstehe (weil ohne Erfahrung) ist ein Control aus Betriebssystem Sicht ein Formular. Daher gehe ich davon aus, dass das Control eine Methode besitzt die für das Neuzeichnen sorgt.
Da das nichts weiter als eine Anweisung an das BS darstellt, kann ich das genauso in VBA durchführen.

@Sonic8
Hast du einen Link zu den angesprochenen Lösungsvorschlägen und eventuell auch Kenntnis was zu diesen Stabilitätsproblemen führt? Ich könnte mir eine Problematik in Verbindung mit der Message Auswertung vorstellen. Wenn ein Formular über meiner Zeichnung verschoben wird, dann müsste es ja ununterbrochen zu einer Neuzeichnung kommen. Ich nehme an, dass das ein Knackpunkt ist hier eine Lösung zu finden. Da gibt es ja den "gelöschten" Sektor in der "Zeichnung". Da braucht man sicher eine ausgeklügelte Vektorlogik um da das BS nicht mit unnötigen Befehlen einzudecken.


LG Markus

 

Hallo!

Das ActivX ist so flexibel, wie du es gestaltest. *wink.gif*
Mit .net wäre mehr machbar als mit Access.

In Access kannst du gar kein Control (Interface "Control") erstellen.
Du kannst höchstens mit Code die Funktionalität von Controls erweitern.

Eine Möglichkeit mit Access-Boardmitteln wäre ein Unterformular mit ausreichend Steuerelementen (inkl. Linien) die du dann zur Laufzeit anordnest, passend formatierst und sichtbar machst.
Zum Schmökern könnte Access NetView dienen.

mfg
Josef

 

\@Josef,
danke. Da würde ich dann doch eher die MSForm Controls verwenden.
Die kann ich auch in Access integrieren und zur Laufzeit hinzufügen.
Da gibts dann aber höchstens grade Linien.

LG Markus

 

Hier wird so etwas mit Bordmitteln umgesetzt: Codebeispiel - Access kann auch malen

 

Hier ist ein Artikel von André Minhorst, der das Vorgehen erklärt.
Das Problem mit der Stabilität während der Entwicklung kommt dadurch, dass sobald der VBA Editor einmal geöffnet war, je eine zusätzliche WindowMessage erzeugt wird, wenn deine WindowProc aufgerufen wird. D.h. für jede behandelte Msg gibt's zusätzlich eine neue. Die MessageQueue kann also niemals abgearbeitet werden, sondern wird immer länger...

Ja, das ist richtig. Das wird zu einem ziemlichen Geflacker auf dem Bildschirm sorgen. - Ich bin insgesamt nicht überzeugt, ob man eine wirklich funktionierende Lösung für den Vorhaben mit direktem Zeichnen über GDI+ erreichen kann.

 

Danke ich mir den Link ansehen.
Für mich ist die Frage, wie die fertigen Controls das Problem lösen.
Die können ja auch nicht zaubern, sondern verwenden ebenso eine API dafür.

Die Frage ist nur welche. Ich behaupt einmal kühn, dass man das mit der GDI auch (ohne Geflackere) hinkriegt wenn man es richtig macht.
Aber bis zum Beweis bleibt das nur eine Behauptung. Sollte jemand darüber was WISSEN bitte um Info.

LG Markus

 

Ich glaube dieses Problem kann man relativ leicht umgehen, indem man statt Access.Forms einfach MsForms einsetzt. Dann muss man nicht mit der hwnd der Access Application arbeiten.

LG Markus

 

Ich weiß nicht, ob das einen Unterschied macht. - Du verwendest immer das hWnd des Forms, nicht der Application.
Du könntest es ausprobieren. In den meisten Fällen sind die MSForms aber keine Alternative zu den Access-Forms.

 

\@sonic8
noch muss ich testen.
Beispiel von Minhorst aus deinem Link:

Code:

 

Ja, in dem Beispiel ist das richtig, weil André dort mittels SubClassing das Schließen des Access-Hauptfensters verhindert.
In deinem Fall würdest du nur das Formular subclassen, das deine "Zeichenunterlage" enthält.

 

\@sonic8, danke ich melde mich sobald ich Erfahrung gesammelt habe.

LG Markus