4. Grundlegende Fragen zu ActiveX, COM uvm.

Grundlegende Fragen zu ActiveX, COM uvm.

  • ?

    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