Moin!

Mit diesen beiden Komponenten soll die WMI-Abfrage unter Delphi vereinfacht werden. Die Komponenten können in die IDE installiert oder dynamisch verwendet werden. Dabei stellt TWMIConnection die Verbindung zum WMI-Dienst auf einer Maschine her, während TMWIQuery Abfragen kapselt. Als Goodie ist noch eine Funktion enthalten, die die installierte Software auflistet (ist zwar keine WMI-Funktion, aber per WMI gibt´s nur die MSI-basierte Software).

Im Anhang befindet sich das Projekt-Archiv mit folgenden Dateien:

• WMITools.pas
  Der Quelltext der Komponenten und der Software-Abfrage-Funktion
  
• WbemScripting_TLB.pas
  WMI-TypeLibrary (sollte ab W2k passen)

Installationsanleitung (für D7(pro)):

1. Die beiden .pas-Dateien aus dem Projekt-Archiv in den \lib-Ordner der Delphi-Installation kopieren (normalerweise C:\Programme\Borland\Delphi7\lib)
   
2. Delphi-IDE starten, Menü Datei -> Alle schließen anklicken (falls ein Default-Projekt angelegt wurde)
   
3. Menü Komponente -> Packages installieren anklicken
   
4. Eintrag Borland Anwenderkomponenten auswählen, dann Bearbeiten anklicken, die Frage "Soll dieses Dialogfenster geschlossen und <Pfad>\Lib\dclusr.dpk geöffnet werden?" mit Ja beantworten
   
5. Im Fenster des Packages erst den Button Hinzu, dann auf Durchsuchen klicken
   
6. Die Datei WMITools.pas aus dem \lib-Ordner der Delpih-Installation auswählen und mit Öffnen bestätigen
   
7. Dann den Button Compil. im Package-Fenster anklicken, das Packe wird neu übersetzt (evtl. Hinweise entsprechend bestätigen; ggfs. werden Warnungen ausgegeben, dass die zusätzliche TypeLib-Unit implizit mit in das Package aufgenommen wurden, das ist OK so)
   
8. Fertig, IDE schließen (Package speichern, falls beim Beenden gefragt)
   
9. IDE wieder öffnen, jetzt sollte die neue Komponente im (evtl. neu angelegten) Register WMI zur Verfügung stehen
   

Hinweis: Eigenschaften von WMI-Objekten können auch Array-Werte annehmen. In dieser Version werden noch keine Array-Werte verarbeitet (gibt entsprechende Fehlermeldung).

Zur Verwendung einfach mal in die Demo schauen, da werden sie geholfen.

cu
Narses

Der WMI Explorer schaut ein wenig unübersichtlich aus und reagiert zudem stellenweise etwas träge. Auch die Nutzerführung könnte etwas bessersein.

Z.B. Anzeige der WMI-Query, die abgesetzt wurde, ListView mit den Spalten, die zurückgegeben wurden, Kombinierte Abfragen (z.B. Auflistung der Netzwerk-Verbindungen + Zugehöriger Daten.

Auch eine Möglichkeit zum Absetzen der SELECT-Abfragen an die WMI wär sicherlich nicht schlecht.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

Erstmal Danke für deinen Test.

BenBE hat folgendes geschrieben :

Der WMI Explorer schaut ein wenig unübersichtlich aus und reagiert zudem stellenweise etwas träge. Auch die Nutzerführung könnte etwas bessersein.

Ähm, das ist eine Demo für die Kompo, nicht der Zweck dieses Threads. Schau dir den relevanten Quelltext an (sind ja nur ein paar Zeilen), nicht die GUI.

BenBE hat folgendes geschrieben :

ListView mit den Spalten, die zurückgegeben wurden

Es wird immer nur genau eine Spalte abgefragt, deshalb wird ja auch in TStrings-Nachfahren geschrieben.

BenBE hat folgendes geschrieben :

Kombinierte Abfragen (z.B. Auflistung der Netzwerk-Verbindungen + Zugehöriger Daten. Auch eine Möglichkeit zum Absetzen der SELECT-Abfragen an die WMI wär sicherlich nicht schlecht.

Sicher durchaus berechtigte Wünsche für eine Profi-Kompo - die dann aber leider wieder so komplex wird, dass man sie nicht mehr einfach benutzen kann und zig Seiten Doku wälzen (viel schlimmer aus meiner Sicht: schreiben! ) muss.

Um also das Design-Konzept nochmal hervorzuheben: es sollte einfach werden, Daten per WMI abzufragen, nicht besonders viele Möglichkeiten bieten.

cu
Narses

k, dann zerpflücken wir mal eben den Source der Komponente ein wenig

Also fangen wir mal mit der WMI Connection an:

• Konstruktor und Destruktor sind asymmetrisch: Im Konstruktor fehlen einige Initialisierungen, im Destruktor wird nicht sichergestellt, dass die Connection geschlossen wird --> Memleak bei WMI-Zugriff.
  
• Open und Close sind nicht Status-unabhängig: Doppeltes öffnen einer Verbindung gibt die vorherige Verbindung nicht sauber frei.
  
• Das Close in Zeile 130 (else-Teil) kann entfallen, da das im Except bereits ausgeführt wird. Insbesondere, da deine Statuskontrolle im Source nicht die beste ist (auch wenn ein Double-Free bei Dir keinen Fehler verursacht)
  
• Doppeltes Führen des Aktivitätszustandes: Wenn Du anhand der Objekt-Referennzen bereits prüfen kannst, ob eine Verbindung besteht, sollte dies nicht über eine zusätzliche Variable geschehen (sei denn, diese Überprüfungen wären im Zweifelsfall zu umfangreich oder langwierig)
  
• If Cond Then ... Else Fail sollte besser als If not Cond Then Fail geschrieben werden, speziell in Verschachtelungen
  
• Sollte nicht eine WMIQuery final auf die zugehörige Connection instantiiert werden?
  
• Statt Typecast mit As Abfrage mit is und ungeprüftem Interface-Typecast nutzen. Dann entfällt die Exception-Prüfung in GetClassList und GetPropertyList
  
• Es fehlt eine Methode, mit der man in einem Query-Object einen eigenen Query-String an die WMI richten kann und dessen Ergebnis als 2D-Array zurückgegeben wird
  
• Null-Werte sollten nicht ignoriert werden. Auch wenn ich das grundlegend genauso sehe, dass man nicht ausgefüllte Felder nicht zurückgibt, erzeugt grad die Variante bei einsspaltigen Abfragen das Problem, dass man die Zuordnung von Zeilen und Spalten eines Wertes verliert, wenn manche Zeilen eliminiert werden
  
• Sollte deine Komponente nicht zumindest mit Variants oder OleVariants für die Wertrückgabe arbeiten, um mehr Flexibilität herein zu bringen? Grad weil öfters mal Zahlen als Zahlen zurückzugeben wären
  
• Die GetInstalledSoftware-Funktion passt thematisch und Implementatorisch nicht so richtig in diese Unit
  

Bin schon auf das verbesserte Upstream-Release der Unit gespannt

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

BenBE hat folgendes geschrieben :

Konstruktor und Destruktor sind asymmetrisch: Im Konstruktor fehlen einige Initialisierungen, im Destruktor wird nicht sichergestellt, dass die Connection geschlossen wird --> Memleak bei WMI-Zugriff.

@Init: Ich gehe von 0-initialisiertem Klassenmemory aus und setze nur die nicht-0-Werte. Wenn du die 0-Variablen auch initialisiert haben willst, kannst du den Code gerne für dich anpassen.
@MemLeak: Der Destruktor gibt die Interfaces durch NIL-Setzen frei, da gibt´s kein MemLeak. Du bist anderer Meinung? Beweise, bitte!

BenBE hat folgendes geschrieben :

Open und Close sind nicht Status-unabhängig: Doppeltes öffnen einer Verbindung gibt die vorherige Verbindung nicht sauber frei.

Richtig, das ist banane, wird geändert.

BenBE hat folgendes geschrieben :

Das Close in Zeile 130 (else-Teil) kann entfallen, da das im Except bereits ausgeführt wird. Insbesondere, da deine Statuskontrolle im Source nicht die beste ist (auch wenn ein Double-Free bei Dir keinen Fehler verursacht)

Schau ich mir in dem Zusammenhang an.

BenBE hat folgendes geschrieben :

Doppeltes Führen des Aktivitätszustandes: Wenn Du anhand der Objekt-Referennzen bereits prüfen kannst, ob eine Verbindung besteht, sollte dies nicht über eine zusätzliche Variable geschehen (sei denn, diese Überprüfungen wären im Zweifelsfall zu umfangreich oder langwierig)

Kinderkram.

BenBE hat folgendes geschrieben :

If Cond Then ... Else Fail sollte besser als If not Cond Then Fail geschrieben werden, speziell in Verschachtelungen

Dito.

BenBE hat folgendes geschrieben :

Sollte nicht eine WMIQuery final auf die zugehörige Connection instantiiert werden?

Warum? Sehe ich nicht so.

BenBE hat folgendes geschrieben :

Statt Typecast mit As Abfrage mit is und ungeprüftem Interface-Typecast nutzen. Dann entfällt die Exception-Prüfung in GetClassList und GetPropertyList

Schau ich mir an.

BenBE hat folgendes geschrieben :

Es fehlt eine Methode, mit der man in einem Query-Object einen eigenen Query-String an die WMI richten kann und dessen Ergebnis als 2D-Array zurückgegeben wird

Scheint, du hast den letzten Post überlesen.

BenBE hat folgendes geschrieben :

Null-Werte sollten nicht ignoriert werden. Auch wenn ich das grundlegend genauso sehe, dass man nicht ausgefüllte Felder nicht zurückgibt, erzeugt grad die Variante bei einsspaltigen Abfragen das Problem, dass man die Zuordnung von Zeilen und Spalten eines Wertes verliert, wenn manche Zeilen eliminiert werden

Jup, das ist mir noch gar nicht aufgefallen. Muss ich anpassen.

BenBE hat folgendes geschrieben :

Sollte deine Komponente nicht zumindest mit Variants oder OleVariants für die Wertrückgabe arbeiten

Nein, Designkonzept.

BenBE hat folgendes geschrieben :

Die GetInstalledSoftware-Funktion passt thematisch und Implementatorisch nicht so richtig in diese Unit

Dann ignorier sie doch einfach. Ich finde sie da gut aufgehoben (nicht zuletzt, weil ich sie in genau diesem Kontext brauche).

cu
Narses

Narses hat folgendes geschrieben :

Moin! BenBE hat folgendes geschrieben : Konstruktor und Destruktor sind asymmetrisch: Im Konstruktor fehlen einige Initialisierungen, im Destruktor wird nicht sichergestellt, dass die Connection geschlossen wird --> Memleak bei WMI-Zugriff. @Init: Ich gehe von 0-initialisiertem Klassenmemory aus und setze nur die nicht-0-Werte. Wenn du die 0-Variablen auch initialisiert haben willst, kannst du den Code gerne für dich anpassen. @MemLeak: Der Destruktor gibt die Interfaces durch NIL-Setzen frei, da gibt´s kein MemLeak. Du bist anderer Meinung? Beweise, bitte!

Zwecks Initialisierung: Nur, wenn der Memory Manager das macht. Muss nicht zwingend gegeben sein.

@Memleak: OnDisconnect wird nicht aufgerufen --> Asymmetrisches Verhalten falls User dort Initialisierungen drin hat. Zudem traue ich den M$-Klassen nicht, dass die auch rekursiv korrekt garbage-collecten. q.e.d. (Beweis durch Authorität)

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Sollte nicht eine WMIQuery final auf die zugehörige Connection instantiiert werden? Warum? Sehe ich nicht so.

Ich sehe eine Query mehr oder weniger als ein finales Objekt, was an eine Connection gebunden ist, statt einem frei herumschwirrenden Objekt, was ständig neu genutzt wird. Dies macht insbesondere die Abfrage der Spalten und der Werte je nach Implementation einfacher, da man viele Dinge cachen kann. Dies würde sogar der Performance gut tun

Ich seh die WMI hierbei ähnlich einem RDBMS (ja, ich weiß, ist keines, aber ähnlich): Ich habe eine Verbindung zu einer Datenquelle (Connection), an die ich Anfragen (Queries\Prepared Statements) schicken kann und daraufhin ein Ergebnis (Resultset) erhalte.

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Es fehlt eine Methode, mit der man in einem Query-Object einen eigenen Query-String an die WMI richten kann und dessen Ergebnis als 2D-Array zurückgegeben wird Scheint, du hast den letzten Post überlesen.

Nö, ich glaub nicht War mehr oder weniger ein Verbesserungsvorschlag, der sich ohne große Änderungen in die aktuelle Unit einbinden ließe, ohne deine "Ein-Spalten-Abfragerei" herausnehmen zu müssen. Vielmehr würde es dem User erlauben, wesentlich effizienter die Datenn abzufragen.

BTW: Du hast eine WSL-Injection in deiner Unit ;P

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Null-Werte sollten nicht ignoriert werden. Auch wenn ich das grundlegend genauso sehe, dass man nicht ausgefüllte Felder nicht zurückgibt, erzeugt grad die Variante bei einsspaltigen Abfragen das Problem, dass man die Zuordnung von Zeilen und Spalten eines Wertes verliert, wenn manche Zeilen eliminiert werden Jup, das ist mir noch gar nicht aufgefallen. Muss ich anpassen.

Und das, wo du doch täglich so viel mit Datenbanken in Berührung kommst ...

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Sollte deine Komponente nicht zumindest mit Variants oder OleVariants für die Wertrückgabe arbeiten Nein, Designkonzept.

hmmm, hätte nur die Implementation von Array-Werten in der Rückgabe vereinfacht ... *duck*

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Die GetInstalledSoftware-Funktion passt thematisch und Implementatorisch nicht so richtig in diese Unit Dann ignorier sie doch einfach. Ich finde sie da gut aufgehoben (nicht zuletzt, weil ich sie in genau diesem Kontext brauche). cu Narses

hmmm, wie in diesem Kontext? Das erfordert jetzt etwas mehr Ausführung

MfG,
BenBE.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

BenBE hat folgendes geschrieben :

Zwecks Initialisierung: Nur, wenn der Memory Manager das macht. Muss nicht zwingend gegeben sein.

Das tut er aber seit D3 und in der DOH steht, dass das Verhalten garantiert ist. Wenn ich der Doku also nicht mehr trauen kann (was Abwärtskompatibilität angeht), dann wird´s wirklich schwierig...

BenBE hat folgendes geschrieben :

@Memleak: OnDisconnect wird nicht aufgerufen --> Asymmetrisches Verhalten falls User dort Initialisierungen drin hat.

OK, das ist ein Argument, sollte da mit rein.

BenBE hat folgendes geschrieben :

Zudem traue ich den M$-Klassen nicht, dass die auch rekursiv korrekt garbage-collecten. q.e.d. (Beweis durch Authorität)

Schon klar... Ich lass es dann erstmal mal so.

BenBE hat folgendes geschrieben :

Ich sehe eine Query mehr oder weniger als ein finales Objekt, was an eine Connection gebunden ist, statt einem frei herumschwirrenden Objekt, was ständig neu genutzt wird.

Zwingt dich doch keiner, mach´s so. "...erwarte ich, dass er mir Arbeit abnimmt, mich aber gleichzeitig in meinen Möglichkeiten nicht mehr als nötig begrenzt." Schonmal irgendwo gelesen?

BenBE hat folgendes geschrieben :

War mehr oder weniger ein Verbesserungsvorschlag, der sich ohne große Änderungen in die aktuelle Unit einbinden ließe, ohne deine "Ein-Spalten-Abfragerei" herausnehmen zu müssen. Vielmehr würde es dem User erlauben, wesentlich effizienter die Datenn abzufragen.

Gerade dir muss ich doch nicht erklären, dass von 1D auf nD "etwas" mehr Aufwand nötig ist. Es passte dir besser in den Kram, das ist auch schon alles. Ich hab ja Verständnis dafür, aber das werde ich nicht umsetzen.

BenBE hat folgendes geschrieben :

BTW: Du hast eine WSL-Injection in deiner Unit ;P

Jau, ist klar, du kannst dir ja dann in deinem eigenen Code was in deine Queries injecten...

BenBE hat folgendes geschrieben :

wie in diesem Kontext? Das erfordert jetzt etwas mehr Ausführung

Nein, tut´s nicht, dazu wäre Einsicht in diverse closed-source-Projekte nötig.

cu
Narses

Narses hat folgendes geschrieben :

Moin! BenBE hat folgendes geschrieben : Zwecks Initialisierung: Nur, wenn der Memory Manager das macht. Muss nicht zwingend gegeben sein. Das tut er aber seit D3 und in der DOH steht, dass das Verhalten garantiert ist. Wenn ich der Doku also nicht mehr trauen kann (was Abwärtskompatibilität angeht), dann wird´s wirklich schwierig...

hmmm, dann sei wenigstens im Destruktor konsequent und nutz zum Nil-Setzen das Build-In-Verhalten des Variablen-Finalisators von Delphi Scherz bei Seite: Selbst wenn man Variablen auf Nil initialisiert, sollte man es wenn möglich dennoch hinschreiben; und sei es, als kurzen Kommentar, dass diese als vorgegeben erachtet werden. Das ist einfach in Bezug auf die Dokumentation des eigenen Codes sinnvoll.

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Zudem traue ich den M$-Klassen nicht, dass die auch rekursiv korrekt garbage-collecten. q.e.d. (Beweis durch Authorität) Schon klar... Ich lass es dann erstmal mal so.

Wie gesagt: Vorausgesetztes Verhalten sollte dokumentiert sein. Grad bei COM und DCOM gibt es doch gewisse Unterschiede zum Normalen Verhalten des Delphi-Compilers.

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Ich sehe eine Query mehr oder weniger als ein finales Objekt, was an eine Connection gebunden ist, statt einem frei herumschwirrenden Objekt, was ständig neu genutzt wird. Zwingt dich doch keiner, mach´s so. "...erwarte ich, dass er mir Arbeit abnimmt, mich aber gleichzeitig in meinen Möglichkeiten nicht mehr als nötig begrenzt." Schonmal irgendwo gelesen?

Jap. Beispiel, wie sowas aussehen kann, gibt's die Tage mal als PN ... (In nem anderen Zusammenhang)

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : War mehr oder weniger ein Verbesserungsvorschlag, der sich ohne große Änderungen in die aktuelle Unit einbinden ließe, ohne deine "Ein-Spalten-Abfragerei" herausnehmen zu müssen. Vielmehr würde es dem User erlauben, wesentlich effizienter die Datenn abzufragen. Gerade dir muss ich doch nicht erklären, dass von 1D auf nD "etwas" mehr Aufwand nötig ist. Es passte dir besser in den Kram, das ist auch schon alles. Ich hab ja Verständnis dafür, aber das werde ich nicht umsetzen.

Ich denk, dass auch eine Reihe anderer Nutzer deines Wrappers diese Funktionalität öfters mal gebrauchen könnten ...

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : BTW: Du hast eine WSL-Injection in deiner Unit ;P Jau, ist klar, du kannst dir ja dann in deinem eigenen Code was in deine Queries injecten...

Query.PropertyName := 'Description,Name'; ... Little Bobby Tables und so

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : wie in diesem Kontext? Das erfordert jetzt etwas mehr Ausführung Nein, tut´s nicht, dazu wäre Einsicht in diverse closed-source-Projekte nötig. cu Narses

Auch hier geh ich rein Source-Technisch und Implementatorisch aus. Klären wir aber auf einem anderen Kanal

mx
BenBE

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

BenBE hat folgendes geschrieben :

Ich denk, dass auch eine Reihe anderer Nutzer deines Wrappers diese Funktionalität öfters mal gebrauchen könnten ...

Ich denk nochmal drüber nach...

BenBE hat folgendes geschrieben :

Query.PropertyName := 'Description,Name'; ... Little Bobby Tables und so

Point taken.

cu
Narses

Moin!

Update auf v1.01, Änderungen sind im Code detailiert beschrieben. Das Konzept der 1D-Abfrage bleibt bis auf Weiteres so wie es ist (also keine eigenen WQL-Statements und 2D-Ergebnismengen). Download im ersten Beitrag.

cu
Narses

Wenn Du schon ein Property hast, warum nutzt Du das dann nicht?





Statt Quoting versuch's Mal mit Eingrenzung der zulässigen Zeichen beim Setzen des Properties. Dazu hat man Setter ja Nennt sich i.d.R. "Gültigkeitsprüfung"

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

BenBE hat folgendes geschrieben :

Wenn Du schon ein Property hast, warum nutzt Du das dann nicht?

Ich verwende innerhalb einer Klasse immer die direktesten Wege. Aber ich schau´s mir nochmal an.

BenBE hat folgendes geschrieben :

markieren Delphi-Quelltext     1: 2: 3: destructor TWMIConnection.Destroy; begin   Active := false; //Statt direktem Aufruf des Events, sonst wieder asymmetrisch

Wat? Wieso asymmetrisch? Und was für ein "Event"? Der Destruktor ist final, da kann man nicht anders hin- oder herkommen. Das ist IMHO sauber so, wie im aktuellen Code.

BenBE hat folgendes geschrieben :

Statt Quoting versuch's Mal mit Eingrenzung der zulässigen Zeichen beim Setzen des Properties. Dazu hat man Setter ja Nennt sich i.d.R. "Gültigkeitsprüfung"

Dazu müsste ich aber jedes mal den String zerlegen, ggfs. eine Exception hochzerren (was wiederum try-except-Blöcke beim Aufruf bedeutet), das ist doch Banane. Wenn das jemand "falsch" macht, hat er halt einen Bedienungsfehler gemacht.

cu
Narses

Narses hat folgendes geschrieben :

Moin! BenBE hat folgendes geschrieben : Wenn Du schon ein Property hast, warum nutzt Du das dann nicht? Ich verwende innerhalb einer Klasse immer die direktesten Wege. Aber ich schau´s mir nochmal an.

Wenn Du nur den Event-Handler ausführst, fehlen ggf. andere Aktionen, die beim Schließen auszuführen sind. --> Code-Dopplung vermeiden.

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : markieren Delphi-Quelltext     1: 2: 3: destructor TWMIConnection.Destroy; begin   Active := false; //Statt direktem Aufruf des Events, sonst wieder asymmetrisch Wat? Wieso asymmetrisch? Und was für ein "Event"? Der Destruktor ist final, da kann man nicht anders hin- oder herkommen. Das ist IMHO sauber so, wie im aktuellen Code.

Der Destructor ist im Prinzip wie jede andere Methode auch. Da kann man beliebigen Code reinpacken, sogar Aufrufe anderer Methoden. Man sollte dabei einzig beachten, dass man in diesen Methoden nicht auf Dinge zugreift, die bereits freigegeben wurden.

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Statt Quoting versuch's Mal mit Eingrenzung der zulässigen Zeichen beim Setzen des Properties. Dazu hat man Setter ja Nennt sich i.d.R. "Gültigkeitsprüfung" Dazu müsste ich aber jedes mal den String zerlegen, ggfs. eine Exception hochzerren (was wiederum try-except-Blöcke beim Aufruf bedeutet), das ist doch Banane. Wenn das jemand "falsch" macht, hat er halt einen Bedienungsfehler gemacht. cu Narses

Mein ja nur. Macht die VCL beim setzen des Name-Properties übrigens auch

mx
BenBE

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

BenBE hat folgendes geschrieben :

Wenn Du nur den Event-Handler ausführst, fehlen ggf. andere Aktionen, die beim Schließen auszuführen sind. --> Code-Dopplung vermeiden.

Ich rufe direkt den zuständigen Handler auf und erspare mir die Boolean-Fallunterscheidung im Setter und das Rauspopeln der Methodenadresse aus der Tabelle. Ich sehe da keine "Gefahr" irgend einer Art. Mag vielleicht "theoretisch" netter sein, gut. Funktional ist das gleichwertig. (Und von Code-Dopplung kann hier mal gar keine Rede sein.)

BenBE hat folgendes geschrieben :

Der Destructor ist im Prinzip wie jede andere Methode auch. Da kann man beliebigen Code reinpacken, sogar Aufrufe anderer Methoden. Man sollte dabei einzig beachten, dass man in diesen Methoden nicht auf Dinge zugreift, die bereits freigegeben wurden.

Ich sehe in deiner Antwort keine Bezug zu meiner Frage. Deshalb reduziere ich das mal auf eine redundante Aussage.

BenBE hat folgendes geschrieben :

Mein ja nur. Macht die VCL beim setzen des Name-Properties übrigens auch

Mag ja sein, bringt aber hier mehr Nach- als Vorteile.

Gut, stellen wir fest, dass wir in der Haarspalter-Phase angekommen sind. Dann sammeln wir mal fleißig praktische Erfahrungen und sehen, was im nächsten Release noch wirklich notwendig sein wird.

cu
Narses

Also, mal davon abgesehen, dass das ganze nicht funktioniert... *

GetClassList, GetPropertyList und Execute, allesamt Quasi-Identisch. Das ist nicht dein Ernst, oder? Ich mein, von dir hätt ich sowas nicht erwartet. Schreib Execute so um, dass da ein verarbeitbares Resultset rauskommt und ruf das von den andern beiden auf...

[*] Funktioniert nicht im Standard-Aufruf: ExecQuery in GetClassList sagt, "Abfrage ist ungültig". Das sagen bei dieser Abfrage auch andere WQL-Tools. Win32Only ist das Problem, __CLASS scheint ein Problem zu haben. Lässt man das weg, gehts.
Oh, da ist sogar noch ein Problem: du würdest "Win32" irgendwo im ClassName abfragen... nicht nur am Anfang

Oh, nochwas: kannst ja das Namespace-property noch als default setzen, spart Platz im DFM und gibt dem OI die Möglichkeit, per 'Geerbte Einstellungen wiederherstellen' eben dies zu tun.

Narses, ich glaube da hatte einer Recht: die Unit sieht echt nach Nachtschicht aus

Moin!

Martok hat folgendes geschrieben :

Narses, ich glaube da hatte einer Recht: die Unit sieht echt nach Nachtschicht aus

Das ist doch hier eine schnöde Verschwörung... Zu Poden mit dem Purchen! Ich sagte ja schon, dass ich dafür nicht so viel Zeit habe; und der ausgewiesene COM/DCOM-Experte bin ich nun auch nicht - was glaubt ihr wohl, wozu ich das hier "öffentlich" gemacht habe... *g*

Martok hat folgendes geschrieben :

Also, mal davon abgesehen, dass das ganze nicht funktioniert... * [*] Funktioniert nicht im Standard-Aufruf: ExecQuery in GetClassList sagt, "Abfrage ist ungültig". Das sagen bei dieser Abfrage auch andere WQL-Tools. Win32Only ist das Problem, __CLASS scheint ein Problem zu haben. Lässt man das weg, gehts.

Hm, hab den Vorschlag mit der Klassenliste aus der MSDN-Library. Bei mir klappt das, welches OS bei dir? Dann bleibt ja wieder nur der Ansatz alle Klassen abzufragen und beim Namen erst auf "Win32_" zu testen - das wollte ich ja nun auch wieder nicht...

Martok hat folgendes geschrieben :

Oh, da ist sogar noch ein Problem: du würdest "Win32" irgendwo im ClassName abfragen... nicht nur am Anfang

Jap, stimmt. *notier*

Martok hat folgendes geschrieben :

GetClassList, GetPropertyList und Execute, allesamt Quasi-Identisch. Das ist nicht dein Ernst, oder? Ich mein, von dir hätt ich sowas nicht erwartet. Schreib Execute so um, dass da ein verarbeitbares Resultset rauskommt und ruf das von den andern beiden auf...

Asche auf mein Haupt... Ich gelobe Besserung.

Martok hat folgendes geschrieben :

Oh, nochwas: kannst ja das Namespace-property noch als default setzen, spart Platz im DFM und gibt dem OI die Möglichkeit, per 'Geerbte Einstellungen wiederherstellen' eben dies zu tun.

String-Defaults gibt´s in D7 noch nicht, nur Numerics.

cu
Narses

Narses hat folgendes geschrieben :

Moin! Martok hat folgendes geschrieben : Narses, ich glaube da hatte einer Recht: die Unit sieht echt nach Nachtschicht aus Das ist doch hier eine schnöde Verschwörung... Zu Poden mit dem Purchen! Ich sagte ja schon, dass ich dafür nicht so viel Zeit habe; und der ausgewiesene COM/DCOM-Experte bin ich nun auch nicht - was glaubt ihr wohl, wozu ich das hier "öffentlich" gemacht habe... *g*

Trotzdem ist man von Dir besseren, effizienteren und saubereren Code gewöhnt ...

Zumal die meisten Dinge nichts mit COM/DCOM zu tun haben, sondern im Wesentlichen handwerklicher Natur sind

Narses hat folgendes geschrieben :

Martok hat folgendes geschrieben : Also, mal davon abgesehen, dass das ganze nicht funktioniert... * [*] Funktioniert nicht im Standard-Aufruf: ExecQuery in GetClassList sagt, "Abfrage ist ungültig". Das sagen bei dieser Abfrage auch andere WQL-Tools. Win32Only ist das Problem, __CLASS scheint ein Problem zu haben. Lässt man das weg, gehts. Hm, hab den Vorschlag mit der Klassenliste aus der MSDN-Library. Bei mir klappt das, welches OS bei dir? Dann bleibt ja wieder nur der Ansatz alle Klassen abzufragen und beim Namen erst auf "Win32_" zu testen - das wollte ich ja nun auch wieder nicht...

Also bei mir funktioniert dein aktualisiertes Abfragetool auch nicht. W2K Pro SP4 Rollup 1 + alle Patches.

Zudem: Sollte man nicht einen Fehler auch melden oder zumindest eine Möglichkeit bieten, um im Fehlerfalle die Ursache zu erfragen? *duck*

Narses hat folgendes geschrieben :

Martok hat folgendes geschrieben : Oh, nochwas: kannst ja das Namespace-property noch als default setzen, spart Platz im DFM und gibt dem OI die Möglichkeit, per 'Geerbte Einstellungen wiederherstellen' eben dies zu tun. String-Defaults gibt´s in D7 noch nicht, nur Numerics.

Müsst ich jetzt auch nachgucken; zur Not gibt es aber stored-Handler, mit denen man Ähnliches tun kann. Und die gehen auf jeden Fall bereits in D7.

mx
BenBE

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

Update auf v1.02, Download im ersten Beitrag.

Martok hat folgendes geschrieben :

Funktioniert nicht im Standard-Aufruf: ExecQuery in GetClassList sagt, "Abfrage ist ungültig". Das sagen bei dieser Abfrage auch andere WQL-Tools. Win32Only ist das Problem, __CLASS scheint ein Problem zu haben. Lässt man das weg, gehts.

Fehler behoben (das scheint W2k-spezifisch zu sein steht aber nix von im MSDN).

Martok hat folgendes geschrieben :

GetClassList, GetPropertyList und Execute, allesamt Quasi-Identisch. Das ist nicht dein Ernst, oder? Ich mein, von dir hätt ich sowas nicht erwartet. Schreib Execute so um, dass da ein verarbeitbares Resultset rauskommt und ruf das von den andern beiden auf...

Ich hab nochmal drübergeschaut: doch, das ist mein voller Ernst. Der Code ist funktionsfähig getestet und die drei eingesparten Zeilen sind es nicht wert, dafür das Messer anzulegen (das ist ja nicht nur Umstellen von ein paar Zeilen, da steckt auch noch Exception-Handling und Memory-Management drin). Ich habe dafür grad keine Zeit. (nicht missverstehen, der Vorschlag ist sinnvoll - aber bringt mich grad nicht weiter)

Martok hat folgendes geschrieben :

Narses, ich glaube da hatte einer Recht: die Unit sieht echt nach Nachtschicht aus

Das mag sein (und trifft es sogar im Kern) - aber (a) habe ich überhaupt eine veröffentlicht und (b) darfst du es gerne verbessern, statt zu nörgeln, ist ja OpenSource.

BenBE hat folgendes geschrieben :

Zudem: Sollte man nicht einen Fehler auch melden

Ja, klar, Danke dafür. Das war ja auch der Sinn der Sache.

BenBE hat folgendes geschrieben :

Müsst ich jetzt auch nachgucken; zur Not gibt es aber stored-Handler, mit denen man Ähnliches tun kann. Und die gehen auf jeden Fall bereits in D7.

Ihr beide seid mir echt zwei Strategen (bitte nicht falsch verstehen, ist nicht persönlich gemeint ), "müsste ich nachsehen", "wäre besser wenn", "könnte man auch", etc.pp. Zeigt´s doch einfach einem Progger-Opa mal so richtig, statt nur zu erwähnen, was man nicht alles besser machen könnte...

cu
Narses

Narses hat folgendes geschrieben :

Moin! Update auf v1.02, Download im ersten Beitrag.

Source-Sichtung später ...

Narses hat folgendes geschrieben :

Martok hat folgendes geschrieben : Funktioniert nicht im Standard-Aufruf: ExecQuery in GetClassList sagt, "Abfrage ist ungültig". Das sagen bei dieser Abfrage auch andere WQL-Tools. Win32Only ist das Problem, __CLASS scheint ein Problem zu haben. Lässt man das weg, gehts. Fehler behoben (das scheint W2k-spezifisch zu sein steht aber nix von im MSDN).

Teste ich dann nachher; hab hier grad kein W2K verfügbar.

Narses hat folgendes geschrieben :

Martok hat folgendes geschrieben : GetClassList, GetPropertyList und Execute, allesamt Quasi-Identisch. Das ist nicht dein Ernst, oder? Ich mein, von dir hätt ich sowas nicht erwartet. Schreib Execute so um, dass da ein verarbeitbares Resultset rauskommt und ruf das von den andern beiden auf... Ich hab nochmal drübergeschaut: doch, das ist mein voller Ernst. Der Code ist funktionsfähig getestet und die drei eingesparten Zeilen sind es nicht wert, dafür das Messer anzulegen (das ist ja nicht nur Umstellen von ein paar Zeilen, da steckt auch noch Exception-Handling und Memory-Management drin). Ich habe dafür grad keine Zeit. (nicht missverstehen, der Vorschlag ist sinnvoll - aber bringt mich grad nicht weiter)

Doch: Es reduziert dir die Nörgelliste um einen Eintrag, weil das nämlich dabei ohne Zusatzaufwand gleich mit abfällt ... Wenn das mal nix ist

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Zudem: Sollte man nicht einen Fehler auch melden Ja, klar, Danke dafür. Das war ja auch der Sinn der Sache.

Fehler melden war gemeint in Bezug auf "Exception schmeißen" und nicht "Bug reporten". Wobei dir Unit, die mir Fehler meldet, wäre sicherlich interessant ...

Narses hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Müsst ich jetzt auch nachgucken; zur Not gibt es aber stored-Handler, mit denen man Ähnliches tun kann. Und die gehen auf jeden Fall bereits in D7. Ihr beide seid mir echt zwei Strategen (bitte nicht falsch verstehen, ist nicht persönlich gemeint ), "müsste ich nachsehen", "wäre besser wenn", "könnte man auch", etc.pp.

Das mit default für Strings brauchte ich bisher noch nicht; das mit stored hab ich aber extra für dich nachgeschlagen ...

Narses hat folgendes geschrieben :

Zeigt´s doch einfach einem Progger-Opa mal so richtig, statt nur zu erwähnen, was man nicht alles besser machen könnte...

Wir sind doch erst bei der "was man tun sollte"-Runde ... Du "was man tun könnte"-Runde folgt nach dem RTM-Release (Ready to Baintain) und nicht bereits nach der öffentlichen Beta

Narses hat folgendes geschrieben :

cu Narses

mx
BenBE

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Narses hat folgendes geschrieben :

Ihr beide seid mir echt zwei Strategen (bitte nicht falsch verstehen, ist nicht persönlich gemeint ), "müsste ich nachsehen", "wäre besser wenn", "könnte man auch", etc.pp.

Du hast noch "wäre auch interessant" vergessen