weiß nicht ob ich in diesem Forum richtig bin, aber ich find es passt in kein andres so richtig rein...

Ich versuche ein ActiveX-Control für IE zu schreiben, das Bilder lädt und anzeigt (vorest von der Platte, später über Netzwerk, wie genau ist noch nicht spezifiziert). Das Problem, das ich dabei habe ist, dass ich zwar ausreichende Kenntnisse von C++ besitze, jedoch weder von ActiveX, noch von COM oder GDI den Hauch einer Ahnung habe.

Ich habe mir in den letzten Tagen einen groben Überblick aneignen können, jedoch ist es leider dabei geblieben -- MSDN ist für den Einstieg viel zu umfangreich, Bücher hab ich keine zur Verfügung, brauchbare online-Resourcen konnte ich nicht finden.

Ich habe ATL Tutorials von MSDN nachgebaut, wollte in diese jetzt eine prototypische Bildanzeige einbauen, hätte dafür GDI und GDI+ verwendet, bin aber zweimal gescheitert.

Meine Frage an euch: Könnt ihr mir einen Schubser in die richtige Richtung geben, damit ich mich nicht verzettle und nach 'ner Woche merke, dass ich einen komplett anders an die Aufgabe herangehen muss? Kann ich ein ActiveX-Control mithilfe von ATL bauen, das GDI verwendet (MFC möchte ich vermeiden)? oder brauche ich dafür GDI+? benötige ich für die Netzwerkkommunikation COM+? Ist es mit der in [1] verwendeten, Event-basierten Kommunikation möglich, die Bilder vom Server zum Client zu transportieren?

Danke schon mal für die Infos!

[1] http://msdn2.microsoft.com/en-us/library/h89x2xwb(VS.80).aspx

Meine Frage an euch: Könnt ihr mir einen Schubser in die richtige Richtung geben, damit ich mich nicht verzettle und nach 'ner Woche merke, dass ich einen komplett anders an die Aufgabe herangehen muss? Kann ich ein ActiveX-Control mithilfe von ATL bauen, das GDI verwendet (MFC möchte ich vermeiden)? oder brauche ich dafür GDI+?

die GDI kannst du eigentlich grundsätzlich immer verwenden, wenn du einen DeviceContext hast, und den solltest du eigentlich auch immer kriegen kriegen können, wenn du ein handle zu nem Fenster hast.
über die Unterschiede zwischen GDI und GDI+ findest du bei google viel. Ich denke für dein Projekt ist die GDI+ wohl angebrachter, vorallem wenn es darum geht, die "internettauglichen" Formate wie PNG, JPEG und GIF zu unterstützen, das erspart dir eine menge arbeit im gegensatz zur verwendung von GDI.

letztendlich ist (fast) alles gezeichnete unter windows (hardware-beschleunigstes mal außen vor jetzt), z.B. die darstellung dieser seite, alles weitere, unter verwendung der gdi gerendert.
aber einarbeiten in ATL, COM und GDI+? da hast du ja viel vor :>

darf man fragen, wo du spezielle GDI-(Zeichen-)Probleme hast?

aber einarbeiten in ATL, COM und GDI+? da hast du ja viel vor :>

Allerdings ^^

hey schrieb:

über die Unterschiede zwischen GDI und GDI+ findest du bei google viel.

Ja, man könnte sagen schon ZU viel beispielsweise bin ich auf widersprüchliche Informationen zur Geschwindigkeit gestoßen: Ich hab gelesen, dass GDI hardwarebeschleunigt ist, GDI+ allerdings nicht. Anderswo wurde diese Aussage wieder entkräftet... Was is jetzt wirklich schneller?

hey schrieb:

Ich denke für dein Projekt ist die GDI+ wohl angebrachter, [...] PNG, JPEG und GIF

Stimmt, darum is mir GDI+ prinzipiell a Spur sympathischer.

hey schrieb:

letztendlich ist (fast) alles gezeichnete unter windows (hardware-beschleunigstes mal außen vor jetzt), z.B. die darstellung dieser seite, alles weitere, unter verwendung der gdi gerendert.

Warum nicht mit GDI+?

hey schrieb:

darf man fragen, wo du spezielle GDI-(Zeichen-)Probleme hast?

Klar:

Der Wizard erstellt mir das ATL-Projekt mit der Compiler-Option /MDd, ich nehme an, aus gutem Grund. Verwende ich die GDI Klasse CBitmap und inkludiere dazu das File afxwin.h, meckert der Compiler:

#error Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]

Interessant ist dabei allerdings, dass die entsprechende Zeile in afx.h, nämlich

#ifdef _DLL
#ifndef _AFXDLL
#error Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
#endif
#endif

ausgegraut ist, da ich 'ne DLL builde. Versuche ich anstelle von /MD[d] die Option /MT[d], bekomme ich den Fehler hier, aus afxv_win32.h:

#ifdef _WINDOWS_
	#error WINDOWS.H already included.  MFC apps must not #include <windows.h>
#endif

Ganz davon abgesehen weisen beide Fehler darauf hin, dass ich dabei bin, MFC zu verwenden, wo doch in der MSDN zu lesen ist, dass durch ATL die Verwendung von MFC vermieden werden sollte?

Was is jetzt wirklich schneller?
Um die Geschwindigkeit musst du dich erstmal kümmern. Aber es ist falsch, dass GDI hardwarebeschleunigt sein soll. Es ist genau anders herum, sie dient dazu, hardware zu wrappen, um immer das gleiche interface bereitstellen zu können.

iko79 schrieb:

hey schrieb:

Ich denke für dein Projekt ist die GDI+ wohl angebrachter, [...] PNG, JPEG und GIF

Stimmt, darum is mir GDI+ prinzipiell a Spur sympathischer.

guut, da du das ganze sowieso in C++ bewerkstelligen willst, lohnt sich der Blick auf die GDI+ eher, denn die GDI ist eine sammlung von C-Funktionen, Strukturen und Zeigern auf void (STRICT möge mich verschonen) x))

warum nicht mit GDI+

naja theoretisch könnte man diese auch als weiteren "ersatz" sehen, evt. sogar gewrappt; also ich glaube kaum, dass sich der code eines LineTo() mit HPEN und dem GDI+ äquivalent ernsthaft unterscheided.
die GDI+ ist prinzipiell nichts "anderes", sie erwartet die möglichkeit der grafik-bearbeitung sowie -ausgabe.

---------------

Der Wizard erstellt mir das ATL-Projekt mit der Compiler-Option /MDd, ich nehme an, aus gutem Grund. Verwende ich die GDI Klasse CBitmap und inkludiere dazu das File afxwin.h, meckert der Compiler:

STOP! wenn du die "GDI Klasse" CBitmap, die es schonmal gar nicht gibt, denn wie oben erwähnt ist die GDI eine implementierung in C, verwendest, verwendest du doch bereits die MFC. außer du benutzt die klasse aus atlgdi.h, was aber wiederum zur WTL gehört (soweit ich weiß, achtung HALBWISSEN!)

zu deinen Fehlern kann ich dir nix sagen, außer, dass du auf den fehler hören könntest und <windows.h> aus den #includes nehmen könntest.

/me votes for GDI+

*:

msdn schrieb:

Windows-based applications do not access the graphics hardware directly. Instead, GDI interacts with device drivers on behalf of applications.

...wie schnell das ganze ist hängt quasi vom Graka-Treiber und dessen Implementierung ab.

Was ich allerdings immer noch nicht ganz herausgefunden habe: Wofür brauche ich COM+? Und brauch' ich das für meinen Anwendungsfall überhaupt?

Wieso denkst Du ohne COM auskommen zu können wenn Du ein ActiveX Control erzeugen willst?

Wenn Du also eines der folgenden Themen benötigst dann hast Du es mit COM+ zu tun:
-Deklarative Transaktionen
-Synchronisation
-Just-in-Time-Aktivierung
-Queued Components (Komponenten in der Warteschlange)
-Objekt-Pooling
-Rollenbasierte Sicherheit

Im Allgemeinen benötigt man all' dies nicht...

COM+ ist eine Erweiterung zu COM! Mehr nicht.

Ich weiß allerdings scheint's so, als sollte man sich früh entscheiden, nachdem der Project-Wizzard schon wissen will ob man COM+ Unterstützung haben will. Nachträglich einbauen is für an Anfänger sicher wieder der Höllenaufwand, drum frag ich vorher, damit ich nicht irgendwann mal drauf komm dass ichs doch brauch. Keine Ahnung, was das alles ist, was du da aufzählst, aber ich glaub, ich lass es einfach mal weg... Danke trotzdem jedenfalls.

Ansonsten:
http://msdn2.microsoft.com/de-de/library/bb979194.aspx

Tatsächlich erfolgt eine solche Aktion nämlich nicht durch Hilfsprogramme wie regsvr32.exe, sondern durch die Komponenten selbst. Dafür stellen sie – wie API-Funktionen aus anderen DLLs – jeweils die Funktionen "DllRegisterServer" und "DllUnregisterServer" zur Verfügung, die sich um die notwendigen Eintragungen in der Registry kümmern und lediglich "von außen angestoßen" werden müssen.

Meine ActiveX-DLL beinhaltet keine dieser Funktionen, das COM Control erbt von folgenden Klassen, die ebenfalls keine der beiden Funktionen bereit stellen.

class CRTSClientObj :
	public CComControl<CRTSClientObj>,
	public IRTSClientObj,
	public IPersistStreamInitImpl<CRTSClientObj>,
	public IPersistStorageImpl<CRTSClientObj>,
	public IOleControlImpl<CRTSClientObj>,
	public IOleObjectImpl<CRTSClientObj>,
	public IOleInPlaceActiveObjectImpl<CRTSClientObj>,
	public IOleInPlaceObjectWindowlessImpl<CRTSClientObj>,
	public IViewObjectExImpl<CRTSClientObj>,
	public IObjectSafetyImpl<CRTSClientObj, INTERFACESAFE_FOR_UNTRUSTED_CALLER>

Das Registrieren per regsvr32 funktioniert aber trotzdem. Wie ist das möglich?