Est-ce que ça vaut la peine de mémoriser Windows API “langue”

Il est toujours utile de comprendre comment quelque chose fonctionne avant d’utiliser des outils qui en cachent une partie. Il n’y a pas de mal à utiliser des assistants et des modèles de classe à long terme, mais vous trouverez des problèmes de débogage beaucoup plus faciles si vous comprenez ce que ces assistants et ces modèles ont fait pour vous et ce que font ces choses. Cela est vrai que ce soit si Win32, .NET ou toute autre API.

Lors de la programmation de .NET, il est particulièrement utile de comprendre le système d’exploitation sur lequel il s’exécute et comment certaines fonctionnalités .NET (telles que les événements) sont mappées sur le système sous-jacent (messages Windows, par exemple). situations bizarres (telles que la ré-appartenance dans un contrôle .NET ListView lorsque vous demandez le nombre d’éléments dans un message de peinture).

Cela dit, il n’est pas impératif que vous sachiez ces choses, juste utile. Vous ne devriez certainement pas avoir besoin de vous souvenir des signatures de méthodes spécifiques – la documentation vous aidera toujours. En général, rappelez-vous comment les choses fonctionnent, pas comment vous les appelez.

À mon humble avis, il n’est pas très difficile de se souvenir des parameters de CreateWindow par cœur. En outre, il est très utile de se familiariser avec l’API native du système sur lequel vous travaillez.

Pour moi. La seule façon de mémoriser une API est de l’utiliser beaucoup. Il y a tout simplement trop à savoir dans la plupart des API et elles changent si souvent pour les mémoriser toutes.

Autrefois, lorsque Internet n’était pas omniprésent, toutes les informations étaient extraites de magazines et de livres. Maintenant, il suffit de copier-coller des exemples de code et de les étendre. J’ai encore utilisé Cut and Paste pour le code squelette des projets précédents.

Mon conseil est de comprendre les API et de savoir où obtenir rapidement des informations.

Je ne pense pas que la mémorisation en vaut la peine. C’est ce que les fichiers d’aide et Internet sont là pour ça.

Si vous voulez apprendre la programmation Win32 “nue” sans .NET, MFC ou ATL (et il est bon de comprendre les blocs de construction sur lesquels ces frameworks sont construits) alors je vous recommande de prendre un morceau à la fois (en commençant par les bases de WinMain , WndProc etc.) et construisez votre propre cadre de classe pour réduire le code passe-partout que vous écrivez avec chaque nouveau projet.

Collez le tout dans le contrôle des sources, et lorsque vous en apprendrez plus sur l’API et apporterez des améliorations à votre infrastructure, tous vos projets pourront en bénéficier.

Personne ne devrait ou ne devrait mémoriser la syntaxe Windows API de nos jours, nous avons IntelliSense dans Visual Studio. Ce que vous devez faire, c’est comprendre le modèle derrière ces API, le fonctionnement du système Windows.

Concentrez-vous sur ces sujets:

• Création et gestion de fenêtres, files d’attente de messages
• Gestion graphique et des fonts (GDI)
• Contrôles standard (editbox, boutons …)
• Événements et entrées utilisateur (souris, clavier)
• Processus et threads
• Gestion des fichiers et autres types d’E / S

La manière la plus courante est de lire un livre classique (Charles Petzold, Jeffrey Ritcher).

Soit dit en passant, cela s’applique à tout framework construit sur l’API Windows: MFC, ATL et même .net avec Windows Forms.

Que vous utilisiez un assistant ou non, vous devriez avoir une compréhension générale du code généré afin de comprendre exactement le fonctionnement de votre programme. Tout est documenté dans la référence en ligne de MSDN. Par conséquent, si vous ne comprenez pas le code de l’assistant, pourquoi ne pas le rechercher?

Personnellement, je m’en tiendrai à utiliser des modèles comme sharepoint départ, car il peut y avoir beaucoup de code passe-partout lorsque l’on travaille avec l’API Windows. Mais c’est juste moi …