En effet, les macros (le VBA) sous excel permettent de faire des actions très variés via des moyens très variés.
Par exemple on peut exécuter du ActiveX, utiliser des librairies système windows, "référencer" des librairies dans excel (Aller dans l'IDE VBA, puis Outils -> Références) ,
Cela permet par exemple de :
- utiliser des objets dictionnaires performants (CreateObject("Scripting.Dictionary")) qui ne sont pas dispo sinon.
- changer la base de registre Windows, (CreateObject("WScript.Shell") ... )
- télécharger/écrire et exécuter des programmes cmd, powershell, exe, ...
- interagir avec l'IDE VBA intégré a Office (FromVBProject As VBIDE.VBProject)
- attendre x s. (Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long) )
- ...
(Et là on comprend mieux comment des virus peuvent facilement transiter par des fichier Office !! )
Vu le nombre de librairies qui peuvent être utilisées, j'ai l'impression que le plus simple (mais pas forcément la meilleur solution car c'est en parti non libre) serait de coupler libreoffice avec wine, et inclure des dll binaires windows.
Sinon, dans les cas simples, LibreOffice arrive déjà à lire les macros excel. Mais quand on développe en VBA, on se retrouve très vite a utiliser certaines librairies windows, et du coup ces fichiers xls(x) ne sont même pas forcément lisible sous Office pour Mac, ou sous Office Windows avec wine sur GNU/Linux.
Bref on peut tout faire et interagir avec n'importe quoi avec une macro Excel, comme le ferait un exe. Et il n'est pas si simple de pouvoir faire tourner des exe sous linux !
[^] # Re: Pourquoi libreoffice ne gère pas les macros excel ?
Posté par quent57 . En réponse au journal Nantes migre vers LibreOffice. Évalué à 10. Dernière modification le 13 août 2015 à 08:43.
En effet, les macros (le VBA) sous excel permettent de faire des actions très variés via des moyens très variés.
Par exemple on peut exécuter du ActiveX, utiliser des librairies système windows, "référencer" des librairies dans excel (Aller dans l'IDE VBA, puis Outils -> Références) ,
Cela permet par exemple de :
- utiliser des objets dictionnaires performants (CreateObject("Scripting.Dictionary")) qui ne sont pas dispo sinon.
- changer la base de registre Windows, (CreateObject("WScript.Shell") ... )
- télécharger/écrire et exécuter des programmes cmd, powershell, exe, ...
- interagir avec l'IDE VBA intégré a Office (FromVBProject As VBIDE.VBProject)
- attendre x s. (Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long) )
- ...
(Et là on comprend mieux comment des virus peuvent facilement transiter par des fichier Office !! )
Vu le nombre de librairies qui peuvent être utilisées, j'ai l'impression que le plus simple (mais pas forcément la meilleur solution car c'est en parti non libre) serait de coupler libreoffice avec wine, et inclure des dll binaires windows.
Sinon, dans les cas simples, LibreOffice arrive déjà à lire les macros excel. Mais quand on développe en VBA, on se retrouve très vite a utiliser certaines librairies windows, et du coup ces fichiers xls(x) ne sont même pas forcément lisible sous Office pour Mac, ou sous Office Windows avec wine sur GNU/Linux.
Bref on peut tout faire et interagir avec n'importe quoi avec une macro Excel, comme le ferait un exe. Et il n'est pas si simple de pouvoir faire tourner des exe sous linux !