Wie findet man am einfachsten heraus, in welchem Modul der gerade
benutzten .net-Version eine Klasse steckt?
Beispiel: die Klasse Monitor.
Wenn man in VisualStudio den Namen tippt, ohne daß der zugehörige Modul
mit using vereinbart ist, tut sich nichts, wenn man mal von
einschlägigen Fehlermeldungen absieht.
Ich habe mehr oder weniger per Zufall herausgefunden, daß
1
using System.Threading;
die Klasse unter .net 2.0 Compact hervorzaubert. (In anderen Versionen
gibt es einen Modul System.Threading.Monitor)
Ziemlich unbefriedigend...
Peter II schrieb:> einfach on die doku zu Monitor schauen?
Die führt in meinem speziellen Fall auf System.Threading.Monitor - den
es unter .net 2.0 Compact nicht gibt.
M$-Dokus sind eine Pest.
Uhu Uhuhu schrieb:> Die führt in meinem speziellen Fall auf System.Threading.Monitor - den> es unter .net 2.0 Compact nicht gibt.
laut doku schon
Versionsinformationen
.NET Framework
Unterstützt in: 3.5, 3.0, 2.0, 1.1, 1.0
.NET Compact Framework
Unterstützt in: 3.5, 2.0, 1.0
XNA Framework
Unterstützt in: 2.0, 1.0
Uhu Uhuhu schrieb:> M$-Dokus sind eine Pest.
nur weil du damit nicht umgehen kannst? Sie sind eines der besten doku
wo wirklich alles drin steht, auch viele Anmerkungen auf was man zu
achten hat.
Peter II schrieb:> laut doku schon
Witzbold. Doku lesen kann ich selbst und einen Rat, was zu tun ist, wenn
die Implementierung offensichtlich nicht zur Doku paßt, hast du
Schlaumeier auch nicht.
> nur weil du damit nicht umgehen kannst?
Aber saudumme Sprüche klopfen...
Uhu Uhuhu schrieb:> Witzbold. Doku lesen kann ich selbst und einen Rat, was zu tun ist, wenn> die Implementierung offensichtlich nicht zur Doku paßt, hast du> Schlaumeier auch nicht.
woher soll ich wissen welche Fehlermeldung du bekommst?
Muss man eventuell unter dem CF die mscorlib als Referenz erst
hinzufügen?
Welche Namespace ist denn unter System verfügbar?
Lesen ist nicht dein Ding. Die Lösung zu dem Monitor-Problem steht im
Eingangsposting.
Eine generelle Lösung für derlei Probleme suche ich, weil ich immer
wieder auf solche Klippen auflaufe.
Und nein, ich habe definitiv 2.0.
Uhu Uhuhu schrieb:> Eine generelle Lösung für derlei Probleme suche ich, weil ich immer> wieder auf solche Klippen auflaufe.
gut also hast du es schon gelöst, und welche info davon steht nicht in
der doku?
http://msdn.microsoft.com/de-de/library/system.threading.monitor%28v=vs.90%29.aspx
Es steht drin, in welchen namespace sie verfügbar ist. Es steht da unter
welchen Platform sie verfügbar ist. Und es steht da in welchen assembly
sie ist. Was hat dir also zu deinen glück gefehlt?
Peter II schrieb:> Was hat dir also zu deinen glück gefehlt?
Ich suche nach einer Möglichkeit, derlei Informationen aus dem SDK
heraus zu holen. Bei c guckt man bei derlei Dingen in den .h-Files, oder
grept und weiß bescheid.
Bei C# kenne ich bisher nichts vergleichbares. Aber die Information muß
irgendwo drin stecken, denn VS kennt die Symbole ja ab dem Moment, wo
man die entsprechende using-Anweisung gibt.
Gibt es irgend einen Viewer für Assemblies, oder besser noch ein
Kommandozeilen-Tool mit dem man die Symbole in eine Textdatei holen
kann?
Uhu Uhuhu schrieb:> Gibt es irgend einen Viewer für Assemblies
ja, einfach im Studio den Klassenbrowser verwenden.
> Ich suche nach einer Möglichkeit, derlei Informationen aus dem SDK> heraus zu holen. Bei c guckt man bei derlei Dingen in den .h-Files, oder> grept und weiß bescheid.
naja ich lese lieber die doku wo genau das drin steht und auch auch die
infos über die Verwendung rauslesen kann. Warum sollte ich mich durch
irgendwelche headerfile hangeln die sich selber wieder inlcude und bei
ifdef unleserlich werden.
Selbst bei C gebe ich einfach
man fopen
ein, und dort steht alles notwendige drin.
Solche Symbolverzeichnisse erleichtern die Grobsuche. Wenn ein Name
nicht vorkommt, braucht man im betreffenden Kontext nicht weiter zu
suchen. Außerdem bekommt man schnell einen Überblick, was vorhanden ist
und wo.
ClassView ist schonmal was, aber wenn man keine Idee hat, was in Frage
kommen könnte, dann kann man ganz schön rumklicken. Eine poplige
ASCI-Text-Liste mit Namespace : Symbol ist da doch deutlich überlegen.
Uhu Uhuhu schrieb:> Solche Symbolverzeichnisse erleichtern die Grobsuche.
also wenn ich eine klasse nicht kenne kann ich sie auch nicht suchen.
Und für den Rest gibt es die Klassenübersicht in der MSDN.
Peter II schrieb:> also wenn ich eine klasse nicht kenne kann ich sie auch nicht suchen.
Wenn ich einen Topf habe, in dem einfach alle Symbole aus allen
Komponenten habe, dann sind mögliche Kandidaten für eine gesuchte
Funktion sehr schnell gefunden.
Kennst du die Kompaktversionen näher?
Der Pocket-PC hat ja keine Maus und man bekommt vom Stift nur
MouseUP-Events mit der linken Taste. (MouseDown bekomme ich nicht, aber
vielleicht verdeckt das Click-Event da irgendwas.)
Kontextmenüs werden durch einen längeren Druck auf ein Control
ausgelöst. Bevor das Menü hochpappt, wird um die Stiftspitze aus blauen
Punkten eine Kreisanimation gezeichnet, wenn der Kreis geschlossen ist,
kommt das Menü.
Ich hätte gerne diese Kreis-Funktion, weiß aber nicht, ob ich da
überhaupt ran komme. Hast du eine Idee?
Uhu Uhuhu schrieb:> Kennst du die Kompaktversionen näher?
nein leider nicht. Ich musste nur mal für jemand in C etwas
Programmieren was ein CF 1.1 nicht machbar war.
Uhu Uhuhu schrieb:> Ich hätte gerne diese Kreis-Funktion, weiß aber nicht, ob ich da> überhaupt ran komme. Hast du eine Idee?
SHRecognizeGesture dürfte für die Animation zuständig sein
http://msdn.microsoft.com/en-us/library/aa925176.aspx
Ansonsten könnte das vielleicht auch mit LoadAnimatedCursor/SetCursor
umsetzbar sein.
So, jetzt habe ich was gefunden, was die Sucherei entscheidend
vereinfacht:
http://www.pinvoke.net/default.aspx/
Und die Liste der von den DLLs des .net CF habe ich mir auch entliehen -
siehe Anhang.
Und SHRecognizeGesture ist dort auch begraben und ich kann es sogar
absturzfrei aufrufen. Wenn ich es jetzt auch noch zum Funktionieren
kriege, ists perfekt.
Thread beobachten
Seitenaufteilung abschalten