Ah oui, je n'avais pas vu la nuance (Toutes les valeurs plutôt que toutes les valeurs sélectionnées).
En fait, dans la plupart des cas, on connaît toutes les valeurs possibles côté serveur (Au moment de la construction du select). Ce que l'on ne sait pas, c'est ce que l'utilisateur va sélectionner parmi celle-ci. Mais bien sûr, il existe des cas où on veut toutes les valeurs.

La solution de KREVETTE m'a paru plus simple (Plus courte, uniquement PHP et HTML...) donc plus intéressante et moins risqué. Cependant elle ne résout pas le même problème. Mais par exemple, tu aurais pu t'inspirer du commentaire de PGPP pour te débarrasser de la ligne de renommage ->
document.forms[liste].elements.Col1.name = "Col1[]";

Donc j'ai commenté un peu vite et je m'en excuse.

Suite à une question par MP de zapanyeti (En gros, un Sleep un peu précis en full VB6, mais des problèmes de dépassement de capacité) ->
Son code utilisait QueryPerformance* en leurs passant des LARGE_INTEGER et en travaillant sur les 32 bits de poids faible.
Une astuce (Je la connais de Renfield) consiste plutôt à utiliser le type Currency qui est sur 64 bits (Avec 4 digits derrière la virgule, mais ça n'a pas d'importance dans ce cas vu les opération effectuées).

Voici donc un code inspiré du sien qui nécessite une form avec un bouton btnWait.
Les attentes sont affichées dans la fenêtre d'exécution. Le résultat est assez précis.
====================================================
Option Explicit

Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long

Private curFreq As Currency
Private stopLoop As Boolean

Public Sub WaitMicroSeconde(Duree As Long)
Dim curStart As Currency
Dim curEnd As Currency
Dim WaitTop As Currency

QueryPerformanceCounter curStart
WaitTop = (Duree * curFreq) / 1000000 + curStart
Do
  QueryPerformanceCounter curEnd
Loop Until curEnd >= WaitTop
End Sub

Private Sub btnWait_Click()
Dim i As Integer
Dim curStart As Currency
Dim curEnd As Currency

btnWait.Enabled = False

For i = 0 To 200
  If stopLoop Then Exit Sub
  QueryPerformanceCounter curStart
  WaitMicroSeconde 2000
  QueryPerformanceCounter curEnd
  Debug.Print "Waited " & (curEnd - curStart) / curFreq * 1000000 & " micro secondes"
  Sleep 1
  DoEvents
Next i

btnWait.Enabled = True

End Sub

Private Sub Form_Load()
  QueryPerformanceFrequency curFreq
  stopLoop = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
  stopLoop = True
End Sub
====================================================

Ce code devrait être franchement moins sujet aux dépassement de capacité quoiqu'ils peuvent encore se produire notamment lors du calcul de WaitTop. L'échec en cas de dépassement de capacité est désactivable dans les propriétés du projet, onglet "compilation", bouton "Optimisations avancées".

Ah bien vu le coup de l'unicode. A vu de nez, il y a au moins le CreateRemoteThread sur LoadLibraryA avec un nom de dll en unicode qui n'avait aucune chance de marcher. Mais pour porter complètement, j'aurais bien besoin d'une [cynisme]Delphi 2010 edition perso[/cynisme].

En tout cas ça marchait pas sur Vista non plus ! Problème de privilège, mais j'ai mis à jour le source avec la correction.

En tout cas, merci pour les commentaires et les essais. :)

Salut,

Bah non, vu de loin je n'ai pas d'idée... Et je n'ai accès ni à un SP3 (Je préfère rester en SP2), ni à deux écrans. Mais j'essaierais sur Vista demain.

Si tu as un peu de temps pour diagnostiquer, tu peux :
1/ Vérifier que la dll est injectée correctement dans l'autre processus. Facile avec processexplorer qui affiche dans le panneau du bas la liste des dlls (Switcher entre dll et handle avec ctrl+D et ctrl+ H). Tu peux aussi ajouter une MessageBox dans la dll.
2/ Tester si le problème est plutôt du côté du message en faisant une appli Delphi comme sur le lien plus haut:
http://www.delphicorner.f9.co.uk/articles/wapi8.htm
Mais au lieu de limiter la taille minimale, agrandir la taille maximale.

Salut,

Les tâches de fond à base de timer, c'est quand même pas la panacée... Tu as regardé du côté de WM_DEVICECHANGE ? Il semble qu'il informe à chaque changement de disque. Aide ici :
http://msdn.microsoft.com/en-us/library/aa363215(VS.85).aspx

Exemple Delphi là :
http://www.swissdelphicenter.ch/torry/showcode.php?id=372

Bin ton .bat semble marcher à part ça. Un goto :loop serait peut être un rien plus esthétique mais à part ça...

Je crois que tu as lu mon code comme ça en fait :

for i:=0 to 1000000 do
begin
  Sleep(500);
end;
if FileExists('Project1.exe') then
  DeleteFile('Project1.exe')
else
  Application.Terminate;

Mais non non, je n'ai pas été sale à ce point là !

Bin mon code est une boucle. Qui s'arrête au bout d'un certain temps (Quelque chose comme 138 heures), effectivement, mais une boucle !

En gros c'est :

for i:=0 to 1000000 do
begin
  Sleep(500);
  if FileExists('Project1.exe') then
    DeleteFile('Project1.exe')
  else
    Application.Terminate;
end;

Je vais jetter un oeil sur ton .bat, mais déjà c'est exist et non existS (Le DOS et ses méandres...). Mais c'est dommage de faire un .bat !

Si on trace dans le "end." on passe dans des fonctions genre :
FinalizeUnits
Finalization
Close
UninitAllocator
UnregisterModule
NotifyModuleUnload
UnsetExceptionHandler

Avec ton code, en Delphi6, on totalise 362 instructions (Comptées avec la commande wt de ntsd, http://msdn.microsoft.com/en-us/library/ff561497(VS.85).aspx) entre l'instruction suivant ShellExecute et l'appel à ExitProcess (Fonction d'arrêt du processus de Windows qui ne revient jamais à l'appelant).

Avec une section de finalization, ce score tombe à 314 instructions. Bon ça doit être plus important sur une grosse appli, mais ça reste un chiffre magnifiquement petit (A comparer 16350 instructions + 3 appels systèmes pour un Hello world en C + runtime fournie avec gcc).

Donc en fin de compte, la partie Delphi est tout à fait négligeable par rapport à ExitProcess qui doit se chiffrer en millions d'instructions au bas mot.

Donc ce n'est en effet pas très rigoureux : qui de ExitProcess ou de cmd sera le plus rapide ?

Que pense tu de faire attendre un peu cmd dans le cas ou un premier del échouerait (Comme sur l'exemple du batch de mon lien) ?

Avec le code suivant, le fichier est supprimé même avec un gros Sleep juste après le ShellExecute.
======================
  ShellExecute(0,   // Le crime parfait d'après Cirec. Thanks to him !  ;)
               nil,
              'CMD' ,
              '/K "for /L %I IN (1 1 1000000) DO ping -n 2 127.0.0.1 > NUL && if EXIST Project1.exe (del Project1.exe) ELSE exit"',
               nil ,
               0);
======================

Salut Cari,

Cette méthode fonctionne bien sur un petit processus chétif. En revanche un gros processus bouffi a des chances de s'en sortir. Il y a en effet une "race condition".

ShellExecute est appelé et va lancé cmd en lui demandant d'exécuter une commande. ShellExecute n'est pas bloquant et ne va pas attendre la fin du processus lancé pour rendre la main à l'appelant. Si ShellExecute était bloquant, cela ne fonctionnerait pas du tout : del essaierait de supprimer le .exe alors qu'il est en cours d'utilisation.

Mais qui a-t-il après ShellExecute ? "end." Et le temps d'exécution de ce petit "end." n'est pas forcément ridicule, car c'est la que Delphi et Windows vont libérer un certain nombre de ressources. Et j'imagine que sur un gros processus, ce "end." prend un certain temps.

Et le problème est là : s'il prend plus de temps que le temps que met cmd.exe à se lancer, alors le .exe est toujours en cours d'utilisation au moment de l'appel de del. Donc le .exe survit.

Ca se vérifie avec ce genre de code ou on allonge artificiellement la durée de "end.".
=============================================
program Project1;

uses
  ShellAPI, Windows;

begin
  ShellAbout  (0,
              'cette petite application de 14Ko',
              'Elle ne sert strictement à rien   ( pffff... )' + #13#10 +
              'Donc, judicieusement, elle disparaîtra ! ;)      Caribensila',
               0);

  ShellExecute(0,   // Le crime parfait d'après Cirec. Thanks to him !  ;)
               nil,
              'CMD' ,
              '/K "del Project1.exe&&Exit"',
               nil ,
               0);
  Sleep(5000);
end.
=============================================

Pour plus d'info sur l'auto suppression, il y a par exemple cette page :
http://www.catch22.net/tuts/selfdel

Mais aucune des solutions proposées ne semble parfaite...

La solution du batch n'est pas trop mal. Pour limiter la consommation CPU, on peut tenter de mettre ça dans la boucle :
ping -n 2 127.0.0.1 > NUL

La méthode avec COMSPEC est la même que la tienne, sauf qu'il récupère COMSPEC qui contient cmd ou command.com sur les antiquité.

Le DELETE_ON_CLOSE a l'air pas mal.

Les codes en assembleur ne sont pas très propres. Ils ne libèrent pas les ressources de la runtime C. Cela revient à appeler ExitProcess ou Halt dans du Delphi, sans passer par le "end." final ou par Terminate. Ces méthode fonctionnerait par contre convenablement sur des .exe sans runtime C (C'est à dire entre autre sans le "main" classique). L'utilisation de rundll32 est cependant une belle trouvaille.

Quand au méthode par injection de code, ça reste quand même très sale, pas le genre de truc que l'on peut embarqué dans une application sérieuse...

Salut,

Il y a toujours eu quelques souci au niveau des zips sur CS. Pourtant 7-zip est du genre souple... Tu peux essayer avec un autre appli de décompression ? Peut être que unzip est dispo par défaut sur ubuntu.