4. Grundlegende Fragen zu ActiveX, COM uvm.

Grundlegende Fragen zu ActiveX, COM uvm.

  • I

    hey schrieb:

    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?

    0
  • ?

    iko79 schrieb:

    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.

    0
  • G

    Sowohl GDI als auch GDI+ sind hardwarebeschleunigt* soweit die Graka-Treiber das unterstützen. Generell scheint aber GDI noch einen kleinen Tacken schneller zu sein, GDI+ hat aber dafür Sachen wie Kantenglättung, wesentlich besseren Support für Alpha-Channel, kann direkt png, jpeg, gif laden...

    /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.

    0
  • I

    Herzlichen Dank für die Antworten, haben mich schon a Stück weiter gebracht. Bin grad dabei, mal an Prototypen für das Teil mit GDI+ zu entwickeln...

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

    0
  • Mod

    ActiveX-Control==COM!

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

    0
  • I

    Mir ist sehr wohl bewusst, dass ActiveX auf COM basiert. Die Frage war nicht, ob ich COM, sondern ob ich COM+ verwenden muss.

    0
  • Mod

    COM+ ist eine Erweiterung zu COM! Mehr nicht.

    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...

    0
  • I

    Martin Richter schrieb:

    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.

    0
  • Mod

    Nein es ist kein Höllenaufwand...

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

    0
  • I

    okay, thx!

    0
  • I

    Hier hab ich gelesen, dass ActiveX-DLLs die Funktionen DllRegisterServer und DllUnregisterServer bereit stellen müssen, um in der Registry eingetragen werden zu können.

    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?

    0
Anmelden zum Antworten