je peux en sélectionnant le MDI child par la souris le déplacer dans le MDI
parent mais ce que je ne veux pas c'est que le MDI child dépasse les limites
du MDI Parents !!
En d'autre termes, le MDI Parent est en "Maximized" et ne doit pas avoir de
scroll barr verticale, donc les MDI child ne doivent pas dépasser le MDI
Parent !!
j'espère que c'est claire !!
je ne sais pas s'il y a une propriétée ou si cela se fait par code !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Zoury
Salut ! :O)
Tu dois overrider la WndProc() de tes formulaires enfants et modifier le comportement standard des fenêtres lors du déplacement en agissant sur le message WM_MOVING : http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_moving.asp
Le paramètre LParam nous fournit une structure RECT qui nous fournit la nouvelle position de la fenêtre enfant avant que celle-ci soit redessinée. Il suffit de vérifier si la position de la fenêtre dépasse les bordures de la zone clientèle de la MDI et d'altérer la structure RECT au besoin.
Je t'ai fait un tit exemple : '*** Option Explicit On
Imports System.Runtime.InteropServices
Public Class Form2 Inherits System.Windows.Forms.Form
Private m_rcAPIChildPrev As RECT
Private Const WM_MOVING As Int32 = &H216
<StructLayout(LayoutKind.Sequential)> _ Private Structure RECT Public Left As Int32 Public Top As Int32 Public Right As Int32 Public Bottom As Int32 End Structure
' Code généré par le Concepteur Windows Form
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
Dim rcAPIChild As RECT
' on veut intervenir lors du déplacement de la fenêtre If (m.Msg = WM_MOVING) Then
' on récupère la nouvelle position de la fenêtre via LParam ' les coordonnées sont fournies en relation avec l'écran rcAPIChild = DirectCast(Marshal.PtrToStructure(m.LParam, GetType(RECT)), RECT)
' on vérifie si la fenêtre enfant est entièrement contenu dans la zone cliente de la fenêtre parent ' les valeurs +2 et +4 sont des tolérances ajoutés pour éviter l'apparition de scrollbars If (Not Me.MdiParent.RectangleToScreen(Me.MdiParent.ClientRectangle).Contains(New Rectangle(rcAPIChild.Left - 2, rcAPIChild.Top - 2, rcAPIChild.Right - rcAPIChild.Left + 4, rcAPIChild.Bottom - rcAPIChild.Top + 4))) Then
' si la fenêtre enfant n'est pas totalement comprise dans la MDI, ' on annule le déplacement en remplaçant la structure RECT hors borne ' par la dernière structure RECT valide que l'on a conservée Marshal.StructureToPtr(m_rcAPIChildPrev, m.LParam, True) Else ' conserve la position actuelle qui est à l'intérieur du MDI m_rcAPIChildPrev = rcAPIChild End If
End If
' exécute le déplacement MyBase.WndProc(m)
End Sub
End Class '***
j'espère que c'est claire !!
Moi aussi ..! ;O)
-- Cordialement Yanick MVP pour Visual Basic
Salut ! :O)
Tu dois overrider la WndProc() de tes formulaires enfants et modifier le
comportement standard des fenêtres lors du déplacement en agissant sur le
message WM_MOVING :
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_moving.asp
Le paramètre LParam nous fournit une structure RECT qui nous fournit la
nouvelle position de la fenêtre enfant avant que celle-ci soit redessinée.
Il suffit de vérifier si la position de la fenêtre dépasse les bordures de
la zone clientèle de la MDI et d'altérer la structure RECT au besoin.
Je t'ai fait un tit exemple :
'***
Option Explicit On
Imports System.Runtime.InteropServices
Public Class Form2
Inherits System.Windows.Forms.Form
Private m_rcAPIChildPrev As RECT
Private Const WM_MOVING As Int32 = &H216
<StructLayout(LayoutKind.Sequential)> _
Private Structure RECT
Public Left As Int32
Public Top As Int32
Public Right As Int32
Public Bottom As Int32
End Structure
' Code généré par le Concepteur Windows Form
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
Dim rcAPIChild As RECT
' on veut intervenir lors du déplacement de la fenêtre
If (m.Msg = WM_MOVING) Then
' on récupère la nouvelle position de la fenêtre via LParam
' les coordonnées sont fournies en relation avec l'écran
rcAPIChild = DirectCast(Marshal.PtrToStructure(m.LParam,
GetType(RECT)), RECT)
' on vérifie si la fenêtre enfant est entièrement contenu dans
la zone cliente de la fenêtre parent
' les valeurs +2 et +4 sont des tolérances ajoutés pour
éviter l'apparition de scrollbars
If (Not
Me.MdiParent.RectangleToScreen(Me.MdiParent.ClientRectangle).Contains(New
Rectangle(rcAPIChild.Left - 2, rcAPIChild.Top - 2, rcAPIChild.Right -
rcAPIChild.Left + 4, rcAPIChild.Bottom - rcAPIChild.Top + 4))) Then
' si la fenêtre enfant n'est pas totalement comprise dans la
MDI,
' on annule le déplacement en remplaçant la structure RECT
hors borne
' par la dernière structure RECT valide que l'on a
conservée
Marshal.StructureToPtr(m_rcAPIChildPrev, m.LParam, True)
Else
' conserve la position actuelle qui est à l'intérieur du MDI
m_rcAPIChildPrev = rcAPIChild
End If
Tu dois overrider la WndProc() de tes formulaires enfants et modifier le comportement standard des fenêtres lors du déplacement en agissant sur le message WM_MOVING : http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_moving.asp
Le paramètre LParam nous fournit une structure RECT qui nous fournit la nouvelle position de la fenêtre enfant avant que celle-ci soit redessinée. Il suffit de vérifier si la position de la fenêtre dépasse les bordures de la zone clientèle de la MDI et d'altérer la structure RECT au besoin.
Je t'ai fait un tit exemple : '*** Option Explicit On
Imports System.Runtime.InteropServices
Public Class Form2 Inherits System.Windows.Forms.Form
Private m_rcAPIChildPrev As RECT
Private Const WM_MOVING As Int32 = &H216
<StructLayout(LayoutKind.Sequential)> _ Private Structure RECT Public Left As Int32 Public Top As Int32 Public Right As Int32 Public Bottom As Int32 End Structure
' Code généré par le Concepteur Windows Form
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
Dim rcAPIChild As RECT
' on veut intervenir lors du déplacement de la fenêtre If (m.Msg = WM_MOVING) Then
' on récupère la nouvelle position de la fenêtre via LParam ' les coordonnées sont fournies en relation avec l'écran rcAPIChild = DirectCast(Marshal.PtrToStructure(m.LParam, GetType(RECT)), RECT)
' on vérifie si la fenêtre enfant est entièrement contenu dans la zone cliente de la fenêtre parent ' les valeurs +2 et +4 sont des tolérances ajoutés pour éviter l'apparition de scrollbars If (Not Me.MdiParent.RectangleToScreen(Me.MdiParent.ClientRectangle).Contains(New Rectangle(rcAPIChild.Left - 2, rcAPIChild.Top - 2, rcAPIChild.Right - rcAPIChild.Left + 4, rcAPIChild.Bottom - rcAPIChild.Top + 4))) Then
' si la fenêtre enfant n'est pas totalement comprise dans la MDI, ' on annule le déplacement en remplaçant la structure RECT hors borne ' par la dernière structure RECT valide que l'on a conservée Marshal.StructureToPtr(m_rcAPIChildPrev, m.LParam, True) Else ' conserve la position actuelle qui est à l'intérieur du MDI m_rcAPIChildPrev = rcAPIChild End If
End If
' exécute le déplacement MyBase.WndProc(m)
End Sub
End Class '***
j'espère que c'est claire !!
Moi aussi ..! ;O)
-- Cordialement Yanick MVP pour Visual Basic
Vincent Poyo
Pourquoi avec .NET on doit toujours utiliser des anciennes techniques comme wndproc qui sont censé être obsolètes ou du moins masquées ? Il y a pas une méthode .NET véritable qui permette de faire la même chose ? C'est quand même bizare que Microsoft n'ai pas pensé à ça !!!
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:
Salut ! :O)
Tu dois overrider la WndProc() de tes formulaires enfants et modifier le comportement standard des fenêtres lors du déplacement en agissant sur le message WM_MOVING : http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_moving.asp
Le paramètre LParam nous fournit une structure RECT qui nous fournit la nouvelle position de la fenêtre enfant avant que celle-ci soit redessinée. Il suffit de vérifier si la position de la fenêtre dépasse les bordures de la zone clientèle de la MDI et d'altérer la structure RECT au besoin.
Je t'ai fait un tit exemple : '*** Option Explicit On
Imports System.Runtime.InteropServices
Public Class Form2 Inherits System.Windows.Forms.Form
Private m_rcAPIChildPrev As RECT
Private Const WM_MOVING As Int32 = &H216
<StructLayout(LayoutKind.Sequential)> _ Private Structure RECT Public Left As Int32 Public Top As Int32 Public Right As Int32 Public Bottom As Int32 End Structure
' Code généré par le Concepteur Windows Form
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
Dim rcAPIChild As RECT
' on veut intervenir lors du déplacement de la fenêtre If (m.Msg = WM_MOVING) Then
' on récupère la nouvelle position de la fenêtre via LParam ' les coordonnées sont fournies en relation avec l'écran rcAPIChild = DirectCast(Marshal.PtrToStructure(m.LParam, GetType(RECT)), RECT)
' on vérifie si la fenêtre enfant est entièrement contenu dans la zone cliente de la fenêtre parent ' les valeurs +2 et +4 sont des tolérances ajoutés pour éviter l'apparition de scrollbars If (Not Me.MdiParent.RectangleToScreen(Me.MdiParent.ClientRectangle).Contains(New Rectangle(rcAPIChild.Left - 2, rcAPIChild.Top - 2, rcAPIChild.Right - rcAPIChild.Left + 4, rcAPIChild.Bottom - rcAPIChild.Top + 4))) Then
' si la fenêtre enfant n'est pas totalement comprise dans la MDI, ' on annule le déplacement en remplaçant la structure RECT hors borne ' par la dernière structure RECT valide que l'on a conservée Marshal.StructureToPtr(m_rcAPIChildPrev, m.LParam, True) Else ' conserve la position actuelle qui est à l'intérieur du MDI m_rcAPIChildPrev = rcAPIChild End If
End If
' exécute le déplacement MyBase.WndProc(m)
End Sub
End Class '***
j'espère que c'est claire !!
Moi aussi ..! ;O)
-- Cordialement Yanick MVP pour Visual Basic
Pourquoi avec .NET on doit toujours utiliser des anciennes techniques comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Il y a pas une méthode .NET véritable qui permette de faire la même chose ?
C'est quand même bizare que Microsoft n'ai pas pensé à ça !!!
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news: eemdVz1aFHA.2444@TK2MSFTNGP15.phx.gbl...
Salut ! :O)
Tu dois overrider la WndProc() de tes formulaires enfants et modifier le
comportement standard des fenêtres lors du déplacement en agissant sur le
message WM_MOVING :
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_moving.asp
Le paramètre LParam nous fournit une structure RECT qui nous fournit la
nouvelle position de la fenêtre enfant avant que celle-ci soit redessinée.
Il suffit de vérifier si la position de la fenêtre dépasse les bordures de
la zone clientèle de la MDI et d'altérer la structure RECT au besoin.
Je t'ai fait un tit exemple :
'***
Option Explicit On
Imports System.Runtime.InteropServices
Public Class Form2
Inherits System.Windows.Forms.Form
Private m_rcAPIChildPrev As RECT
Private Const WM_MOVING As Int32 = &H216
<StructLayout(LayoutKind.Sequential)> _
Private Structure RECT
Public Left As Int32
Public Top As Int32
Public Right As Int32
Public Bottom As Int32
End Structure
' Code généré par le Concepteur Windows Form
Protected Overrides Sub WndProc(ByRef m As
System.Windows.Forms.Message)
Dim rcAPIChild As RECT
' on veut intervenir lors du déplacement de la fenêtre
If (m.Msg = WM_MOVING) Then
' on récupère la nouvelle position de la fenêtre via LParam
' les coordonnées sont fournies en relation avec l'écran
rcAPIChild = DirectCast(Marshal.PtrToStructure(m.LParam,
GetType(RECT)), RECT)
' on vérifie si la fenêtre enfant est entièrement contenu dans
la zone cliente de la fenêtre parent
' les valeurs +2 et +4 sont des tolérances ajoutés pour
éviter l'apparition de scrollbars
If (Not
Me.MdiParent.RectangleToScreen(Me.MdiParent.ClientRectangle).Contains(New
Rectangle(rcAPIChild.Left - 2, rcAPIChild.Top - 2, rcAPIChild.Right -
rcAPIChild.Left + 4, rcAPIChild.Bottom - rcAPIChild.Top + 4))) Then
' si la fenêtre enfant n'est pas totalement comprise dans
la
MDI,
' on annule le déplacement en remplaçant la structure
RECT
hors borne
' par la dernière structure RECT valide que l'on a
conservée
Marshal.StructureToPtr(m_rcAPIChildPrev, m.LParam, True)
Else
' conserve la position actuelle qui est à l'intérieur du
MDI
m_rcAPIChildPrev = rcAPIChild
End If
Pourquoi avec .NET on doit toujours utiliser des anciennes techniques comme wndproc qui sont censé être obsolètes ou du moins masquées ? Il y a pas une méthode .NET véritable qui permette de faire la même chose ? C'est quand même bizare que Microsoft n'ai pas pensé à ça !!!
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:
Salut ! :O)
Tu dois overrider la WndProc() de tes formulaires enfants et modifier le comportement standard des fenêtres lors du déplacement en agissant sur le message WM_MOVING : http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_moving.asp
Le paramètre LParam nous fournit une structure RECT qui nous fournit la nouvelle position de la fenêtre enfant avant que celle-ci soit redessinée. Il suffit de vérifier si la position de la fenêtre dépasse les bordures de la zone clientèle de la MDI et d'altérer la structure RECT au besoin.
Je t'ai fait un tit exemple : '*** Option Explicit On
Imports System.Runtime.InteropServices
Public Class Form2 Inherits System.Windows.Forms.Form
Private m_rcAPIChildPrev As RECT
Private Const WM_MOVING As Int32 = &H216
<StructLayout(LayoutKind.Sequential)> _ Private Structure RECT Public Left As Int32 Public Top As Int32 Public Right As Int32 Public Bottom As Int32 End Structure
' Code généré par le Concepteur Windows Form
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
Dim rcAPIChild As RECT
' on veut intervenir lors du déplacement de la fenêtre If (m.Msg = WM_MOVING) Then
' on récupère la nouvelle position de la fenêtre via LParam ' les coordonnées sont fournies en relation avec l'écran rcAPIChild = DirectCast(Marshal.PtrToStructure(m.LParam, GetType(RECT)), RECT)
' on vérifie si la fenêtre enfant est entièrement contenu dans la zone cliente de la fenêtre parent ' les valeurs +2 et +4 sont des tolérances ajoutés pour éviter l'apparition de scrollbars If (Not Me.MdiParent.RectangleToScreen(Me.MdiParent.ClientRectangle).Contains(New Rectangle(rcAPIChild.Left - 2, rcAPIChild.Top - 2, rcAPIChild.Right - rcAPIChild.Left + 4, rcAPIChild.Bottom - rcAPIChild.Top + 4))) Then
' si la fenêtre enfant n'est pas totalement comprise dans la MDI, ' on annule le déplacement en remplaçant la structure RECT hors borne ' par la dernière structure RECT valide que l'on a conservée Marshal.StructureToPtr(m_rcAPIChildPrev, m.LParam, True) Else ' conserve la position actuelle qui est à l'intérieur du MDI m_rcAPIChildPrev = rcAPIChild End If
End If
' exécute le déplacement MyBase.WndProc(m)
End Sub
End Class '***
j'espère que c'est claire !!
Moi aussi ..! ;O)
-- Cordialement Yanick MVP pour Visual Basic
Zoury
> Pourquoi avec .NET on doit toujours utiliser des anciennes techniques
comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Obsolètes ? nope. tant que Windows fonctionnera avec des queues de messages, la WndProc() et tous ce qu'on peut faire avec existera.
Si la WndProc() était masquée en VB6, c'est parce que VB est à la base un language visant les non initiés. Les APIs nous permettaient toutefois de subclasser cette méthode aisément. .NET nous offre la même possibilité mais de façon beaucoup plus intuitive et plaisante.
Il ne faut pas oublier que VB.NET est un langage de programmation.. il ne change pas la façon dont Windows fonctionne, au contraire, il doit fournir les outils nécessaires pour travailler avec Windows. :O)
Il y a pas une méthode .NET véritable qui permette de faire la même chose
?
C'est quand même bizare que Microsoft n'ai pas pensé à ça !!!
Faire la même chose que quoi ? Modifier la WndProc() ou empêcher un formulaire de sortir d'une limite déterminée ?
Si tu parles de la WndProc() , l'overrides *est* la technique véritable. C'est entièrement orientée objet et intégrée au langage, aucune API n'est nécessaire pour faire cela. Si tu parles de limité la fenêtre dans ses déplacements, alors là non, il n'ont rien fait d'intégré. Il faut cependant convenir que ce n'est pas un besoin commun à tous et qu'au moins il y a possibilité de le faire... :O)
-- Cordialement Yanick MVP pour Visual Basic
> Pourquoi avec .NET on doit toujours utiliser des anciennes techniques
comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Obsolètes ? nope. tant que Windows fonctionnera avec des queues de messages,
la WndProc() et tous ce qu'on peut faire avec existera.
Si la WndProc() était masquée en VB6, c'est parce que VB est à la base un
language visant les non initiés. Les APIs nous permettaient toutefois de
subclasser cette méthode aisément. .NET nous offre la même possibilité mais
de façon beaucoup plus intuitive et plaisante.
Il ne faut pas oublier que VB.NET est un langage de programmation.. il ne
change pas la façon dont Windows fonctionne, au contraire, il doit fournir
les outils nécessaires pour travailler avec Windows. :O)
Il y a pas une méthode .NET véritable qui permette de faire la même chose
?
C'est quand même bizare que Microsoft n'ai pas pensé à ça !!!
Faire la même chose que quoi ? Modifier la WndProc() ou empêcher un
formulaire de sortir d'une limite déterminée ?
Si tu parles de la WndProc() , l'overrides *est* la technique véritable.
C'est entièrement orientée objet et intégrée au langage, aucune API n'est
nécessaire pour faire cela.
Si tu parles de limité la fenêtre dans ses déplacements, alors là non, il
n'ont rien fait d'intégré. Il faut cependant convenir que ce n'est pas un
besoin commun à tous et qu'au moins il y a possibilité de le faire... :O)
> Pourquoi avec .NET on doit toujours utiliser des anciennes techniques
comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Obsolètes ? nope. tant que Windows fonctionnera avec des queues de messages, la WndProc() et tous ce qu'on peut faire avec existera.
Si la WndProc() était masquée en VB6, c'est parce que VB est à la base un language visant les non initiés. Les APIs nous permettaient toutefois de subclasser cette méthode aisément. .NET nous offre la même possibilité mais de façon beaucoup plus intuitive et plaisante.
Il ne faut pas oublier que VB.NET est un langage de programmation.. il ne change pas la façon dont Windows fonctionne, au contraire, il doit fournir les outils nécessaires pour travailler avec Windows. :O)
Il y a pas une méthode .NET véritable qui permette de faire la même chose
?
C'est quand même bizare que Microsoft n'ai pas pensé à ça !!!
Faire la même chose que quoi ? Modifier la WndProc() ou empêcher un formulaire de sortir d'une limite déterminée ?
Si tu parles de la WndProc() , l'overrides *est* la technique véritable. C'est entièrement orientée objet et intégrée au langage, aucune API n'est nécessaire pour faire cela. Si tu parles de limité la fenêtre dans ses déplacements, alors là non, il n'ont rien fait d'intégré. Il faut cependant convenir que ce n'est pas un besoin commun à tous et qu'au moins il y a possibilité de le faire... :O)
-- Cordialement Yanick MVP pour Visual Basic
Jacques93
Bonsoir Zoury, Zoury a écrit :
Pourquoi avec .NET on doit toujours utiliser des anciennes techniques
comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Obsolètes ? nope. tant que Windows fonctionnera avec des queues de messages, la WndProc() et tous ce qu'on peut faire avec existera.
Si la WndProc() était masquée en VB6, c'est parce que VB est à la base un language visant les non initiés. Les APIs nous permettaient toutefois de subclasser cette méthode aisément. .NET nous offre la même possibilité mais de façon beaucoup plus intuitive et plaisante.
Il ne faut pas oublier que VB.NET est un langage de programmation.. il ne change pas la façon dont Windows fonctionne, au contraire, il doit fournir les outils nécessaires pour travailler avec Windows. :O)
[...]
Pour compléter tes propos, si tu le permets (de toute façon t'as pas le choix :-D ), à l'origine .Net devait (et doit toujours ?) faire abstraction le plus possible de la plate-forme sur laquelle il tourne afin d'une part d'être portable, et que tous les langages .Net utilisent le même Run-Time (CLR). A l'instar de Java ???
OK, je sors.
-- Cordialement,
Jacques.
Bonsoir Zoury,
Zoury a écrit :
Pourquoi avec .NET on doit toujours utiliser des anciennes techniques
comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Obsolètes ? nope. tant que Windows fonctionnera avec des queues de messages,
la WndProc() et tous ce qu'on peut faire avec existera.
Si la WndProc() était masquée en VB6, c'est parce que VB est à la base un
language visant les non initiés. Les APIs nous permettaient toutefois de
subclasser cette méthode aisément. .NET nous offre la même possibilité mais
de façon beaucoup plus intuitive et plaisante.
Il ne faut pas oublier que VB.NET est un langage de programmation.. il ne
change pas la façon dont Windows fonctionne, au contraire, il doit fournir
les outils nécessaires pour travailler avec Windows. :O)
[...]
Pour compléter tes propos, si tu le permets (de toute façon t'as pas le
choix :-D ), à l'origine .Net devait (et doit toujours ?) faire
abstraction le plus possible de la plate-forme sur laquelle il tourne
afin d'une part d'être portable, et que tous les langages .Net utilisent
le même Run-Time (CLR). A l'instar de Java ???
Pourquoi avec .NET on doit toujours utiliser des anciennes techniques
comme
wndproc qui sont censé être obsolètes ou du moins masquées ?
Obsolètes ? nope. tant que Windows fonctionnera avec des queues de messages, la WndProc() et tous ce qu'on peut faire avec existera.
Si la WndProc() était masquée en VB6, c'est parce que VB est à la base un language visant les non initiés. Les APIs nous permettaient toutefois de subclasser cette méthode aisément. .NET nous offre la même possibilité mais de façon beaucoup plus intuitive et plaisante.
Il ne faut pas oublier que VB.NET est un langage de programmation.. il ne change pas la façon dont Windows fonctionne, au contraire, il doit fournir les outils nécessaires pour travailler avec Windows. :O)
[...]
Pour compléter tes propos, si tu le permets (de toute façon t'as pas le choix :-D ), à l'origine .Net devait (et doit toujours ?) faire abstraction le plus possible de la plate-forme sur laquelle il tourne afin d'une part d'être portable, et que tous les langages .Net utilisent le même Run-Time (CLR). A l'instar de Java ???
