Control Library im MSDN

[Jac de Lad]

Da ich öfters mal nach einer Message oder deren Parameter schaue um ein Control anzusprechen habe ich mir einen Link auf die Control Library im MSDN gelegt: http://msdn.microsoft.com/en-us/library/bb773169(VS.85).aspx

Über diesen Link kommt ihr ganz schnell zur Liste der Controls mit Styles, Messages, Notifications und Structs. Das hat mir schon oft eine Menge Sucharbeit erspart, weil es ein wenig versteckt ist.

Ach ja, wenn ihr die Parameter oder weiterführende Informationen zu einem API sucht, dann gebt bei Google einfach "API-Name function" ein und der erste oder zweite Link ist der, der direkt im MSDN auf das API zeigt.

Vielleicht kann die Infos ja jemand gebrauchen.

[Frabbing]

So gehe ich auch immer vor. "ApiName MSDN" in Google eingeben und lesen.

[AHT]

Zitat von Frabbing

So gehe ich auch immer vor. "ApiName MSDN" in Google eingeben und lesen.

...wobei selbst dem, was dort auf dieser Seite steht, nicht immer vorbehaltlos zu trauen ist. Manche, sehr spezielle APIs, sind, so wie sie dort erklärt werden, nicht verwendbar, da grundsätzliche Fehler in der Erklärung drin sind oder die Erklärungen einfach nicht komplett sind.

[Jac de Lad]

Aber ich denke trotzdem, dass dies eine ganz gute Hilfe ist. Bisher bin ich noch nicht auf gravierende Fehler gestoßen und wenn man die Kommentare liest, dann lösen sich auch die kleineren fast immer in Wohlgefallen auf.

Nur seltsam, dass Microsoft das nicht ändert, wenn jemand auf einen Fehler aufmerksam wird...

[AHT]

Zitat von Jac de Lad

Aber ich denke trotzdem, dass dies eine ganz gute Hilfe ist.

Auf jeden Fall.

Zitat von Jac de Lad

Bisher bin ich noch nicht auf gravierende Fehler gestoßen

Ich ja.

[Jac de Lad]

So spezielle Funktionen hab ich noch nicht benutzt, das wirds wohl sein.

Ist aber interessant.

[Frabbing]

Darum benutze ich auch lieber globalen Speicher.

[AHT]

Zitat von Frabbing

Darum benutze ich auch lieber globalen Speicher.

Es geht ja da eher um Speicherscanfunktionen (und zwar um spezielle) - wo steht also was. Benutzen tut es kaum einer, weil es eben kaum einer versteht und man das auch nicht nutzen kann, weil da kompletter Blödsinn verzapft wird .
In TNT habe ich mich da nicht an diese Dokumentation gehalten, sondern es so umgesetzt, wie es richtig umzusetzen ist.
Wie gesagt - wer programmiert sollte nicht denken, dass das was dort steht die komplette Weisheit und Wahrheit ist, sondern muss jederzeit darauf gefasst sein, dass bei selten verwendeten APIs und Strukturen dort Sachen stehen, die jeder Realität spotten.
Desweiteren sind dort Funktionen erklärt, die - wenn man sich etwas von der Beschreibung löst, selbst nachdenkt und das, was da steht, nicht als das Ultimo ansieht - im Prinzip von jedem API-Neuling in der Profan Freeware umgesetzt werden kann, ansonsten aber selbst vielen Profiproggern in der asynchronen Variante (andere geht mit Profan natürlich nicht) graue Haare wachsen lässt.
Im Prinzip ist API nicht kompliziert und unverständlich, sondern wird manchmal nur kompliziert und unverständlich gemacht. Selbst nachdenken ist beim Proggen das, warauf es ankommt - eben nicht nur lesen, sonder auch verstehen, dann wird's sehr einfach.
Die an eine Sache rangehen, als wüßten sie von nichts, sind da generell im Vorteil - und die im Prinzip von nichts wissen, wissen im Endeffekt vielleicht viel, viel mehr, als die, die denken, sie wüßten alles .
Das ist vielleicht nur aus meiner Sicht der Sache zu verstehen - ich denke aber, das ist wirklich so.
Ich bin schon auf Neulinge in der API Programmierung gestoßen, die mich wirklich überrascht haben und auf "alte Hasen", die weniger auf sich geben, als irgendein Neuling und deshalb nie stoppen, dazuzulernen und nachzufragen oder nachzuhaken - so soll's sein. Ich persönlich weiß von nichts, und dabei soll es auch bleiben.

[Frabbing]

Selbst nachdenken ist beim Proggen das, warauf es ankommt - eben nicht nur lesen, sonder auch verstehen, dann wird's sehr einfach.

Dein "selbst nachdenken" ist in solchen Situationen oft Try&Error. Ich hab auch schon API-Beschreibungen erlebt, die fehlerhaft waren und die eine Lösungsfindung deswegen unnötig erschwerten. Das ist ärgerlich, aber auch irgendwo menschlich. Auch Hilfeschreiber machen Fehler.

[AHT]

Zitat von Frabbing

Dein "selbst nachdenken" ist in solchen Situationen oft Try&Error.

Nein, sondern bei Adam und Eva beginnen - und das immer, immer wieder.
Wenn man nicht verstanden hat, was ein Handle ist, kann man zum Beispiel nicht sehen, das hier überhaupt etwas falsch läuft. Um das anwenden zu wollen, muss man aber erst einmal eine Programmiersprache lernen, die mit Handles umgeht. Man muss also laufend wieder "reduzieren", und zwar auf ein Maß, an dem man schon lange, lange, glaubt vorbei zu sein. Tut man das nicht, ist alles nur Error - ohne Try, man merkt das bloß manchmal gar nicht.
Hier gibt es zum Beispiel 4 Arten, das mit der Freeware von Profan umzusetzen, aber nur eine Art, das synchron zu regeln. Merkwürdigerweise findet man scheinbar aber kaum Quelltexte für eine asynchrone Regelung - obwohl die viel besser und einfacher ist. Warum ist das wohl so? Um die asynchrone Varianten hier zu verstehen, muss man in der Regel wohl ganz gewaltig reduzieren - das heißt in diesem Fall nachschlagen, nachlesen und neu lernen etc.... - und nicht darauf bauen, das diese Beschreibung komplett oder gut ist oder hier der einfachste Weg dokumentiert wird und gerade deswegen der eigene kleine Verstand nicht ausreicht, zu verstehen was da steht .
Im Prinzip sollte man viel öfter sagen: "Das was da steht, verstehe ich beim besten Willen nicht!" Denn vielleicht gibt es ja jemanden, desen Wissenstand beim Lesen so niedrig war, dass er nicht reduzieren musste, um das zu finden und umzusetzen, was auch für einen selbst am einfachsten und verständlichsten ist... Das ist, wie gesagt, meine Sicht der Welt und vielleicht deshalb nicht so ganz einfach zu verstehen. Es ist immer besser zu wissen, dass man nichts weiß und nur lernen kann, als zu denken, dass man alles weiß, und gerade davon keine Ahnung hat .

Zitat von Frabbing

Ich hab auch schon API-Beschreibungen erlebt, die fehlerhaft waren und die eine Lösungsfindung deswegen unnötig erschwerten. Das ist ärgerlich, aber auch irgendwo menschlich. Auch Hilfeschreiber machen Fehler.

Genau. Denkt man dann aber, die Beschreibung sei "gut", nur weil sie nicht jeder versteht, ist das nicht der richtige Weg...

[Frabbing]

Mit XPIA ergibt sich noch die Möglichkeit, eigenes Threads in sein Programm zu bauen. Das ist dann wohl Möglichkeit 5, die ich immer bevorzugen würde.
Die beschriebene API(s) hab ich selber bislang noch nie benutzen müssen, erinnere mich aber an einen Thread dazu.