Methoden und Eigenschaften auslesen

specialwork · Verfasst: Mo 15.03.04 15:29

Hallo,
Kann mir mal jemand erklären, wie man die Eigenschaften und Methoden (auch Enums, Aliase, usw.) eines COM Objektes auslesen kann.

Ich denke das die Funktionen

markieren

Delphi-Quelltext

1:	GetIdsOfNames, QueryInterface

dabei eine große Rolle spielen, oder?
Zum einen möchte ich gerne einen eigenen Viewer entwicklen, mit dem man sich die Schnittstellenelemente ansehen kann, und zum anderen brauche ich es unbedingt, für spezielle Automatisierungsaufgaben zu bewältigen.

Speziell geht geht es darum, den Quelltext für VCL Wrapper-Komponenten zu erzeugen.

Gruß, Tom

Ps: Für ein paar Codeschnipsel wäre ich sehr dankbar

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Hallo!

Com-Objekte allgemein bieten an sich keinerlei Möglichkeit, die Methoden aufzulisten. Die Methode GetIdsOfName wird erst in IDispatch-Schnittstellen (ein Nachfahre von IInterface, der nicht von allen COM-Objekten unterstützt wird) implementiert, QueryInterface liefert dir nur ein Interface, das du bereits kennen musst, nicht jedoch irgendwelche Infos über Methoden des angegebenen Interfaces.

Vielen COM-Objekten wird deshalb eine Typbibliothek (*.tlb) dazugelegt, die du in Delphi über "Projekt\Typbibliothek importieren" einlesen lassen kannst. Das Erstellen von Quelltext ist dann erledigt, Delphi legt automatisch entsprechende Schnittstellen-Units im Import-Folder an.

Cu,
Udontknow

specialwork · Verfasst: Mo 15.03.04 15:56

Hallo, Udontknow,

Leider reicht mir das, was Delphi produziert nicht aus. Genauer gesagt, geht es darum Collections in einer VCL Wrapperklasse abzubilden. Wenn man die von Delphi produzierten Wrapperklassen sinnvoll verwenden will, das heißt, wenn man zur Entwicklungszeit verschiedene Eigenschaften verändern will, muß man die Compilerdirektive {$LiveServerAtDesigntime} aktivieren. Trotzdem ist die Wrapperkomponente immer noch nicht so brauchbar, wie man es von Delphikomponenten gewohnt ist. Außerdem wird der Quelltext zur Komponente nach jedem Neuimport der TypeLib gnadenlos überschrieben.

Com-Objekte allgemein bieten an sich keinerlei Möglichkeit, die Methoden aufzulisten
... Aber wie machen die Entwicklungsumgebeungen wie etwa Visual Studio oder auch Delphi das ? Die haben auch nicht immer eine TypeLib zur Verfügung, und können es trotzdem.

Gruß, Tom

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Die Betonung liegt auf "allgemein". Es gibt keine Möglichkeit, von jedem COM-Objekt die Methoden zu erfahren.

Manche (nicht alle!) COM-Objekte (in Delphi beispielsweise TTypedComObject-Nachfahren) unterstützen jedoch die Schnittstelle IProvideClassInfo, mit der eine Auflistung ohne Typbibliothek möglich ist.

Zitat:

Trotzdem ist die Wrapperkomponente immer noch nicht so brauchbar, wie man es von Delphikomponenten gewohnt ist. Außerdem wird der Quelltext zur Komponente nach jedem Neuimport der TypeLib gnadenlos überschrieben.

Was ist denn anders? Wie ist man es denn gewohnt? Ich persönlich arbeite zur Entwurfszeit überhaupt nicht mit Com-Objekten, sondern erledige alles zur Laufzeit, daher bin ich nicht so firm in diesem Thema...

Cu,
Udontknow

specialwork · Verfasst: Mo 15.03.04 16:35 Titel: Was ist denn anders?

Was ist denn anders?

1. Delphi kapselt alle Eigenschaften des Interfaces in eine Klasse namens TServerProperties.
2. Delphi erstellt standardmäßig, ohne Möglichkeit dies abzustellen, eine Wrapperkomponente an der man zur Entwicklungszeit keine Änerungen vornehmen kann.
3. Delphi konvertiert Methoden- und Eigenschaftsnamen die mit anderen Namen kollidieren (z.B. Connect wird zu Connect1, oder Disconnect wird zu Disconnect1)
4. Generell werden Interface-Properties von Delphi als fehlerhaft interpretiert. Es wird dann eine Warnung ausgegeben, die da heißt: Die Eigenschaft xyz hat einen unterschiedlichen Ergebnistyp ..., und wird somit nicht in den ServerProperties angezeigt.
5. Delphi kann natürlich auch nicht erkennen, das es sich bei einigen Interfaces um ich nenne sie mal Collections-Interfaces handelt. Das bedeutet, das 2 oder mehr Interfaces gemeinsam eine Collection bilden.

Gruß, Tom

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Zitat:

1. Delphi kapselt alle Eigenschaften des Interfaces in eine Klasse namens TServerProperties.

Was, wenn ein Objekt mehrere Interfaces hat?

Zitat:

2. Delphi erstellt standardmäßig, ohne Möglichkeit dies abzustellen, eine Wrapperkomponente an der man zur Entwicklungszeit keine Änerungen vornehmen kann.

Wie? Irgendwo muss doch der Code dieser Wrapper-Komponente herumliegen...

Zitat:

4. Generell werden Interface-Properties von Delphi als fehlerhaft interpretiert. Es wird dann eine Warnung ausgegeben, die da heißt: Die Eigenschaft xyz hat einen unterschiedlichen Ergebnistyp ..., und wird somit nicht in den ServerProperties angezeigt.

Kannst du dafür mal kurz ein wenig Code zeigen? Einmal irgendeine Property-Definition, bei der das auftritt, und die Zugriffsmethode(n), die diese Property benutzt? Ich kann bei meinen Com-Objekten problemlos properties definieren.

Zitat:

5. Delphi kann natürlich auch nicht erkennen, das es sich bei einigen Interfaces um ich nenne sie mal Collections-Interfaces handelt. Das bedeutet, das 2 oder mehr Interfaces gemeinsam eine Collection bilden.

Recht eigentümlicher Begriff, "Collection". Meinst du damit, daß ein und dasselbe Objekt mehrere verschiedene Interfaces implementieren kann?

Cu,
Udontknow

MaxiTB · Verfasst: Mo 15.03.04 16:57

Das mit der TypeInfo stimmt nur bedingt:

Zitat:

IDispatch::GetTypeInfo
Retrieves the type information for an object, which can then be used to get the type information for an interface.

HRESULT GetTypeInfo(unsigned int iTInfo, LCID lcid, ITypeInfo FAR* FAR* ppTInfo);
Parameters
iTInfo
The type information to return. Pass 0 to retrieve type information for the IDispatch implementation.
lcid
The locale identifier for the type information. An object may be able to return different type information for different languages. This is important for classes that support localized member names. For classes that do not support localized member names, this parameter can be ignored.
ppTInfo
Receives a pointer to the requested type information object.
Return Value
The return value obtained from the returned HRESULT is one of the following:

Return value Meaning
S_OK Success; the type information element exists.
DISP_E_BADINDEX Failure; iTInfo argument was not 0.

Example
The following code from the sample file Lines.cpp implements the member function GetTypeInfo:

// This function implements GetTypeInfo for the CLines collection.
STDMETHODIMP
CLines::GetTypeInfo(
UINT iTInfo,
LCID lcid,
ITypeInfo FAR* FAR* ppTInfo)
{
*ppTInfo = NULL;

if(iTInfo != 0)
return ResultFromScode(DISP_E_BADINDEX);

m_ptinfo->AddRef(); // AddRef and return pointer to cached
// typeinfo for this object.
*ppTInfo = m_ptinfo;

return NOERROR;
}

See Also
IDispatch Interface, CreateStdDispatch, CreateDispTypeInfo.

Zitat:

ITypeInfo Interface
This section describes ITypeInfo, an interface typically used for reading information about objects. For example, an object browser tool can use ITypeInfo to extract information about the characteristics and capabilities of objects from type libraries.

Type information interfaces are intended to describe the parts of the application that can be called by outside clients, rather than those that might be used internally to build an application.

The ITypeInfo interface provides access to the following:

The set of function descriptions associated with the type. For interfaces, this contains the set of member functions in the interface.
The set of data member descriptions associated with the type. For structures, this contains the set of fields of the type.
The general attributes of the type, such as whether it describes a structure, an interface, and so on.
The type description of an IDispatch interface can be used to implement the interface. For more information, see the description of CreateStdDispatch in Dispatch Interface and API Functions.

An instance of ITypeInfo provides various information about the type of an object, and is used in different ways. A compiler can use an ITypeInfo to compile references to members of the type. A type interface browser can use it to find information about each member of the type. An IDispatch implementor can use it to provide automatic delegation of IDispatch calls to an interface.

Siehe fett, wobei das bedingt über folgendes ermittelt werden kann:

Zitat:

IDispatch::GetTypeInfoCount
Retrieves the number of type information interfaces that an object provides (either 0 or 1).

HRESULT GetTypeInfoCount(unsigned int FAR* pctinfo);

Parameter
pctinfo
Points to a location that receives the number of type information interfaces provided by the object. If the object provides type information, this number is 1; otherwise the number is 0.
Return Value
The return value obtained from the returned HRESULT is one of the following:

Return value Meaning
S_OK Success.
E_NOTIMPL Failure.

Comments
The function may return zero, which indicates that the object does not provide any type information. In this case, the object may still be programmable through IDispatch or a VTBL, but does not provide run-time type information for browsers, compilers, or other programming tools that access type information. This can be useful for hiding an object from browsers.

Example
This code from the Lines sample file Lines.cpp implements the GetTypeInfoCount member function for the CLines class (ActiveX or OLE object).

STDMETHODIMP
CLines::GetTypeInfoCount(UINT FAR* pctinfo)
{
*pctinfo = 1;
return NOERROR;
}

See Also
IDispatch Interface, CreateStdDispatch

Weiters ists wohl klar, daß die Method dann per GetIdsOfNames und Invoke aufgerufen wird. Aber die spare ich mir jetzt zu posten ;-)

.

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

@MaxiTB:

Zitat:

Das mit der TypeInfo stimmt nur bedingt: ...

Sorry, bin gerade wohl nicht auf der Höhe. Was soll mir (uns) das fett gedruckte sagen? :roll:

Zitat:

Weiters ists wohl klar, daß die Method dann per GetIdsOfNames und Invoke aufgerufen wird. Aber die spare ich mir jetzt zu posten .

Hmmm, aber wir sprechen doch allgemein von COM-Objekten, die evtl. IDispatch gar nicht implementieren.

Cu,
Udontknow

MaxiTB · Verfasst: Mo 15.03.04 17:09

::Udontknow

Erstens ist in der Typeinfo die ganze Methodendefinition vorhanden - weiß ich auch aus Praxis, sonst hätte ich wohl meinen jetzigen Job nicht, weil ich ständig Methoden enumeriere ;-)

. Zwar in C++, aber das ist ja kein Hindernis in Delphi, denke ich mal. Ach ja - ich habe Funktion discription fett gedruckt, wenn du genau hinsiehst ;-)

.

Zweitens macht ein COM-Object ohne IDispatch nicht viel Sinn ... das ist wie wenn man Delphi ohne VCL verwendet [außerdem - wie will man dann die Methode dynamisch aufrufen ?]. Da kann mans gleich in C schreiben ;-)

. Daher gehe ich mal aus, daß wie es normal ist, IDispatch implementiert ist - in C++ wird ja eh alles per CDispImpl abgeleitet, d.h. ist mir auch noch kein COM-Objekt untergekommen ohne (siehe aber auch mehr dazu und wie man COM (richtig) programmiert 'Essential COM' von Don Box, Addison Wesley). Das ist aber kein Problem - man muß ja sowieso ein Query machen auf IDispatch - dann sieht man schon, was für einen Lazarus man da auf der Platte hat *g*.

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

specialwork · Verfasst: Mo 15.03.04 17:12

> Udontknow

Also ich denke, dass die meisten COM Bibliotheken das IDispatch Interface unterstützen. Für mich ist es aber vorerst nur wichtig, Bibliotheken solcher Art auszulesen. Soweit ich weiß, ist es sogar um ein vielfaches langsamer, wenn man die COM Biblitheken nicht über IDispatch anspricht.

Gruß, Tom

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Naja, gut, wenn es dir nur um IDispatch-unterstützende Objekte geht...

Zitat:

Zweitens macht ein COM-Object ohne IDispatch nicht viel Sinn

Merkwürdig, ich komme wunderbar ohne IDispatch aus.

Zitat:

Soweit ich weiß, ist es sogar um ein vielfaches langsamer, wenn man die COM Biblitheken nicht über IDispatch anspricht.

Sämtliche DirectX-Interfaces sind nicht von IDispatch abgeleitet . Es ist wohl eher umgekehrt. :wink:

Cu,
Udontknow

specialwork · Verfasst: Mo 15.03.04 17:41

Hey UdontKnow

Auszug aus der DirectX SDK für C++

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

IDirectPlay8Peer*  g_pDP = NULL;
...
CoInitialize( NULL );
...
hr = CoCreateInstance( CLSID_DirectPlay8, NULL, CLSCTX_INPROC_SERVER,
                         [b]IID_IDirectPlay8Peer[/b], (LPVOID*) &g_pDP );

if( FAILED( hr ) ) 
  {
    MessageBox( NULL, TEXT("Failed Creating IDirectPlay8Peer. "),
                  TEXT("DirectPlay Sample"), MB_OK | MB_ICONERROR );
    return FALSE;
  }

bedeuted das IID von IID_IDirectPlay8Peer nicht IDispatch Interface of Interface IDirectPlay8Peer ?

MaxiTB · Verfasst: Mo 15.03.04 17:43

::Udontknow

Zitat:

Merkwürdig, ich komme wunderbar ohne IDispatch aus.

Stimmt, hat ja auch nur Sinn, wenn man die TypeInfo public machen will, also z.B. wenn man seine Interfaces sprachunabhängig anbieten will. Mit einem COM-Objekt ohne Dispatch kannst du unter VB z.B. nix anfangen - unter .NET sehr, sehr eingeschränkt. Weiters kannst du ja nur über IDispatch Exceptionhandling, Collections und Events realisieren (und zwar COM konform) - wobei das wieder andere CXXXImpl Klassen sind, die von IDispatch abgeleitet sind.

Zitat:

Sämtliche DirectX-Interfaces sind nicht von IDispatch abgeleitet . Es ist wohl eher umgekehrt.

Aufrufe und enumerieren sind natürlich langsamer - kein Thema - der direkte call ist immer schneller !

Was DirectX angeht ...
Sprechen wir jetzt von Objekten oder Interfaces ? Das IDispatch wird ja als Interface implementiert und in die Map gelistet, die Methoden der Dispatch werden im Objekt implementiert (CDispImpl). Unter DX macht man ein Interfacequery aber fordert keine Objekte an. Das sind ja zwei verschiedene Sachen - und die Frage war ja eindeutig nach den Objekten. Ob die COM-Objekte der DirectX-SDK ein IDispatch implementiert haben, habe ich mir noch nie andgesehen, weil ich noch nie ein Objekt angefordert habe - nur die Interfaces. Allerdings hab ich DX auch nur unter C++ gecodet, vielleicht läuft das unter Delphi irgendwie anders (CoCreateInstance macht ja scheinbar auch eine direkten Call - nur ists ein WinAPI Funktion - was die genau intern macht, weiß ich nicht).

::specialwork

Nein - das ist nur die GUID - CoCreateInstance enumeriert über die GUID den pointer auf die Methode; das heißt aber noch lange nicht, daß TypeInfo drinnen sein muß oder eben auch IDispatch.

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

MaxiTB · Verfasst: Mo 15.03.04 17:53

::Udontknow

Habe jetzt mal reingespyed in ein paar COM-Klassen auf meinem Rechner - unter anderem DX7 - und du hast recht: DX7 war die einzige Klasse, die keine IDispatch implementiert hatte. Manchmal frage ich mich wirklich, für was ich MS style Richtlinien folge, wenn die sich selber nicht immer dran halten :roll:

!

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

@MaxiTB:

Zitat:

Unter DX macht man ein Interfacequery aber fordert keine Objekte an.

Mit Verlaub, aber das klingt sehr hanebüchen. Wie soll denn das gehen? Jedes Interface (nicht zu verwechseln mit Interface-Definition!) repräsentiert doch den Zugriff auf ein Objekt!

Wenn du kein Objekt hinter dem Interface hättest, wo sollen denn die Methoden-Aufrufe ausgeführt werden?

@Specialworks:

deine Frage bezüglich der Schnittstelle habe ich nicht verstanden, aber ich habe mal in meine DX-Header reingeschaut:

markieren

Quelltext

1:
2:

IDirectPlay8Peer = interface(IUnknown)
...

IDirectPlay8Peer ist also direkt von IUnknown/IInterface abgeleitet, nicht von IDispatch (schliesslich ist IUnknown der Urahn aller Interfaces).

Edit: Jetzt habe ich den Sinn deiner Frage verstanden! Nein, IID steht für "Interface-Identifier" oder "Interface-ID". Mit dieser GUID hat man einen eindeutigen Bezeichner für ein Interface, sodaß keine Verwechslungsgefahr besteht. Analog dazu gibt es die CLSID bzw. den "Class-Identifier" der eine bestimmte Klasse eindeutig identifiziert. Diese gibst du ja an CreateComObject, und zurück bekommst du eine IInterface-Schnittstelle auf ein Objekt, daß mithilfe der angegebenen Klasse erstellt wurde.

Cu,
Udontknow

MaxiTB · Verfasst: Mo 15.03.04 18:17

::Udontknow

Zitat:

Mit Verlaub, aber das klingt sehr hanebüchen. Wie soll denn das gehen? Jedes Interface (nicht zu verwechseln mit Interface-Definition!) repräsentiert doch den Zugriff auf ein Objekt!

Jo - hab mich unglücklich ausgedrückt - wollte damit Aussagen, das man normalerweise CreateInstance verwendet und ich so keine Ahnung habe, was alles im Objekt gemapped ist, weil ich nie einen dynamischen Call gebraucht habe. Mir ist schon klar, daß man eine Objekt-Instanz anfordert.

Ähm ... eine Frage noch ... was ist hanebüchen - konnte ich im offiziellen Wörterbuch nicht finden ... und dictionary.reference.../translate/text.html bietet noch keine Konvertierung in nordischen Slang ;-)

?

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Hanebüchen bedeutet so viel wie "unglaublich", "unsinnig", "grob fehlerhaft". :wink:

Zitat:

Jo - hab mich unglücklich ausgedrückt - wollte damit Aussagen, das man normalerweise CreateInstance verwendet und ich so keine Ahnung habe, was alles im Objekt gemapped ist, weil ich nie einen dynamischen Call gebraucht habe.

Irgendwie tauchen bei mir mehr Fragezeichen auf als verschwinden. Ich verwende für meine Objekte Create(Remote-)ComObject, um sie zu erstellen. Was meinst du mit Mapping, meinst du Schnittstellen-Implementierungen? Und was heisst "dynamischer Call"? Was wolltest du mir denn dann oben mitteilen (keine Objekte anfordern)?

Cu,
Udontknow

MaxiTB · Verfasst: Mo 15.03.04 19:08

::Udontknow

Weil man unter C++ COM Objekte erstellen kann über Interfaces. Wenn mans automatisiert über CoCreateInterface macht, dann ist nicht wirklich transparent, was man macht, weil man ja auch nicht angeben muß, welche Klasse dahinter steht. Das ist alles was ich damit sagen wollte - das ich jetzt gar nicht weiß, obs bei DX eine gemappetes IDispatch gibt.

Bei COM-Objekten werden Interfaces ja gemappt - es können ja in ein COM-Objekt ja mehrere implementiert werden - ist ja wichtig, da auf Interface-Ebene COM keine Mehrfachvererbung unterstützt. Das sieht dann in C++ z.B. so aus:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:

//--- Header information ---//

#ifndef CT_COLOR_H
#define CT_COLOR_H

#include <uq_color.h>

#pragma once

#ifndef WIN32
 #error Beware: This class is designed for WIN32 platform only !
#endif

// 2003-07-25 N MX ============================================================

class ATL_NO_VTABLE CtColor : public CComObjectRootEx<CComSingleThreadModel>, public CComCoClass<CtColor, &CLSID_Color>, public IDispatchImpl<IColor, &IID_IColor, &LIBID_UqCore>
{
 public:
 
  DECLARE_REGISTRY_RESOURCEID(IDR_COLOR)

  DECLARE_PROTECT_FINAL_CONSTRUCT()

  BEGIN_COM_MAP(CtColor)
   COM_INTERFACE_ENTRY(IColor)
   COM_INTERFACE_ENTRY(IDispatch)
  END_COM_MAP()

  STDMETHOD(SetRgb)(BYTE Red,BYTE Blue,BYTE Green);
  STDMETHOD(SetRgba)(BYTE Red,BYTE Blue,BYTE Green,BYTE Alpha);

  STDMETHOD(get_DefaultValue)(VARIANT *Result);  

  STDMETHOD(get_Alpha)(BYTE *Result);
  STDMETHOD(put_Alpha)(BYTE Value);
  STDMETHOD(get_Blue)(BYTE *Result);
  STDMETHOD(put_Blue)(BYTE Value);
  STDMETHOD(get_Green)(BYTE *Result);
  STDMETHOD(put_Green)(BYTE Value);
  STDMETHOD(get_Red)(BYTE *Result);
  STDMETHOD(put_Red)(BYTE Value);
  STDMETHOD(get_Transperent)(VARIANT_BOOL *Result);
  STDMETHOD(put_Transperent)(VARIANT_BOOL Value);
  STDMETHOD(get_Value)(VARIANT *Result);
  STDMETHOD(put_Value)(VARIANT Value);

 private:
  
  UqColor mValue;  
};

typedef CComObject<CtColor> CtColorObject;

OBJECT_ENTRY_AUTO(__uuidof(Color), CtColor)

#endif

Und wer mich verpfeifft bei meiner Firma, daß ich hier Firmeninternes poste, der kriegt eine auf die Nuß

! Auch wenns nur was kleines ist *g*.

BTW - hier sieht man schön, daß die Interfaces IColor und IDispatch gemappt werden - das man dann ja schön im OLE Viewer ansehen kann. Wer oben die CDispImpl vermißt, der sei drauf hingewiesen, daß IColor von einer IBase abgeleitet ist, welche diese bereits implementiert (plus eine Menge anderer Sachen - IBase ist natürlich ein reallocales Template).

Was dynamisch - statisch angeht ists einfach: Methodenaufruf über GUID werden in 'Essential COM' als static bezeichnet, Aufrufe über Invoke als dynamic. Ach ja - Don Box war bei MS zuständig für die Intergrierung von COM/COM+ in die .NET CLR. Deshalb halte ich mich vor allem an seine Namensgebungen wenns um COM geht (und somit an jene von Bob Atkinson, Tony Williams und Craig Wittenberg).

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

specialwork · Verfasst: Mo 15.03.04 23:32

Hallo ?

Das ist ja alles ganz schön interressant, aber hier geht es nicht darum wer von euch beiden Recht hat oder nicht, sondern viel mehr, wie ihr mir bei meinem Problem helfen könnt. Also ich warte...

Gruß, Tom

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Setzen wir doch noch einmal bei meinem Post von 16:56 an...

Cu,
Udontknow

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme