KGF_dll - nouvelles versions

@ Papydall,

Félicitation à ta mère aussi, 99 ans est un bel age.

Pourrais tu essayer le code dont on discute
et nous dire ce que cela donne chez toi ?...

@Papydall:
Félicitations pour ta mère, et longue vie à elle !

@Ygeronimi:
Aucune objection pour surveiller un Panel. Ca devrait marcher avec tout objet ayant un handle.

Ne comprenant pas trop le sujet, j’ai quand même testé le code :
Ça donne :
Form 0 --- > M001
Form 1 --- > M002

Serait ma machine qui part en cacahuètes ?...

ygeronimi a écrit:

Serait ma machine qui part en cacahuètes ?...

Ne la jette surtout pas par la fenêtre!
Cherche plutôt entre la chaise et le clavier.

Nouvelle version:
KGF.dll V4.70 du 18/04/2015

Nouveautés:
MoveSizeWindowAddHook: correction d'un bug en détection de l'objet déclenchant

Modules modifiés:
KGF.dll

La doc est inchangée.
Les sources sont à jour.

Ce bug provoquait le déclenchement d'un évènement ON_CHANGE dans l'EDIT associée à l'interception des déplacements/redimensionnements d'une fenêtre, si l'objet déclenchant l'évènement n'était pas dans la liste interne des objets enregistrés. Dans ce cas, si x objets étaient enregistrés, le EDIT contenait une valeur Myyy avec y = x+1, donc une valeur invalide ne désignant rien de réel. Simple erreur de reconnaissance de fin de boucle de recherche.

Conséquence: il est en effet possible d'utiliser MoveSizeWindowAddHook pour déclarer un Panel. Mais ça ne marchera pas, car Windows détecte le déplacement/redimensionnement sur la form enveloppante et non sur le Panel. Et donc, MoveSizeWindowAddHook ne pourra jamais déclencher l'évènement.

Ceci est la correction d'une programmation "brouillonne" de ma part, détectée à l'occasion de l'analyse du problème de Ygeronimi ci-dessus. Mais ce n'est pas lié: chez moi, son problème ne se produit pas, ni sous XP ni sous W8. Et donc, cette correction ne sera pas la solution que cherche Ygeronimi. Désole.

Je vais reprendre avec un programme basic
( épuré au maximum )

J' ai repris sur un code on ne peut plus simple :

Code:

' ESSAI FONCTION MOVESIZEWINDOWS
dim res%
label action
dll_on "KGF.dll"
Edit 1 : on_change 1,action

res% = dll_call1("MoveSizeWindowInitHook",handle(1))
message str$(res%) :' message : 0
res% = dll_call1("MoveSizeWindowAddHook",handle(0))
message str$(res%) :' message : 1
end

action:
   message text$(1)
return

Là l' erreur si elle est de moi...

Bref, j' ai lancé plusieurs fois ce petit, très petit, programme.
La détection n' est pas toujours effective.
J' ai eu un message du label action sur 6 lancements et sur un déplacement de la fenêtre,
pas sur un agrandissement.
Le point positif, c' est que le renvoi était bon...

Je suis sur W7 édition familiale.

Déplacer, agrandir, rapetisser la fenêtre toujours M001.

Je suis sur W7 édition intégrale.

Idem chez moi. Toujours M001, en déplacement et redimensionnement, comme il se doit. Le label action est bien appelé chaque fois qu'on modifie la form 0. Je ne sais que dire...

EDIT

A tout hasard... une question de droits d'accès ? Est-ce que tu as les droits d'administrateur ? Essaie de générer l'EXE et de le lancer en mode administrateur (clic droit - exécuter comme administrateur).

J' ai essayé le mode administrateur sans aucune différence.

Franchement, je sèche... XP, W7, W8 - tout marche, chez moi et chez Papydall. Il doit y avoir une différence entre nos configurations. Mais laquelle ? J'avoue que je suis perplexe...

Cette fonction fait elle appel à fichier particulier de Windows ?
Je peux peut être le retrouver ou voir si il est absent, voir défectueux...

Celà me fait d' autant plus raler, que je suis presque à l' origine de cette
demande de fonction et qu' elle résolve le problème du carré...

sur mon PC, "MoveSizeWindowAddHook" fait planter l'exemple de klaus dès que je touche à la souris, qqsoit la version de KFG(testé avec la version incluse dans ppe, et celle du 18 avril).

Je n'utilise aucun fichier Windows particulier. Et en cas d'erreur, l'évènement n'est tout simplement pas déclenché - la routine "oublie" alors l'évènement. Et surtout, je ne vois pas d'où pourrait venir le 680. La valeur retournée, formatée en Mxxx, est en fait un indice dans une table interne à la DLL. Si tu déclares 3 fenêtres, les seules valeurs possibles sont M001, M002 ou M003. Si tu n'as qu'une seule fenêtre, seul M001 est possible. Voici le code de la routine qui renvoie cette information:

Code:

// fonction HOOK pour une form en général
function GenHookSize_CBT_FUNC(nCode: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
var
  hTemp  : HWND;
  s      : String;
  i      : integer;
  begin
  hTemp := HWND(wParam);
  for i:=1 to nGenHookSize do if GenHookSizeForm[i]=hTemp then break;    // chercher la bonne form dans la liste
  if i<=nGenHookSize then begin
    case nCode of
      HCBT_MOVESIZE:
        begin
          s := 'M' + RightStr('00'+IntToStr(i),3);
          SendMessage(GenHookSizeEdit,WM_SETTEXT,length(s),integer(pchar(s)));
        end;
    end;
  end;
  Result := CallNextHookEx(GenHookSizeWndProc[i], nCode, wParam, lParam);
end;

et voici les variables internes définies dans un module global:

Code:

// variables pour hook général de fenêtres pour gérer MOVESIZE
GenHookSizeForm:    array [1..100] of integer;            // liste des handles des fenêtres hookées
GenHookSizeEdit:    integer;                              // handle du EDIT pour envoi du message
GenHookSizeWndProc:  array [1..100] of integer;            // WNDPROC ancienne du process hooké
nGenHookSize: integer;                                    // dernier indice utilisé

La fonction GenHookSize_CBT_FUNC est appelée chaque fois que la form "hookée" reçoit un message Windows. Seul le message HCBT_MOVESIZE est traité - tous les autres messages sont passés directement à la fonction habituelle (celle qui a été remplacée par GenHookSize_CBT_FUNC). C'est le rôle de CallNextHookEx qui utilise l'adresse de la fonction d'origine mémorisée dans le tableau GenHookSizeWndProc. Et si l'on trouve notre message particulier, un fait ceci:
1. on récupère le handle de la fenêtre qui a déclenché le message, dans hTemp
2. on cherche ce handle dans notre table des handles des fenêtres hookées: GenHookSizeForm
3. l'indice i est alors le résultat recherché
4. si l'indice est valide (trouvé), on crée la chaîne s avec Mxxx
5. on envoie un message Windows à l'objet EDIT associé pour lui imposer le texte, ce qui déclenche son ON_CHANGE

Tu vois, c'est extrêmement simple, n'utilise aucun fichier Windows (ni autre, d'ailleurs). On est simplement passivement en attente que Windows nous envoie ce message, on cherche l'expéditeur dans notre table, et, si trouvé, on envoie un texte au EDIT.

Je ne vois absolument pas comment le 680 peut s'introduire dans ce mécanisme. Si quelqu'un a une idée, je suis preneur !

On s'est croisé, Silverman. C'est bizarre, ce que tu dis. Moi aussi, j'ai un XP Pro SP3 avec la même version de Panoramic et KGF.dll, et ça passe sans problème. Mais je vais creuser la chose. Merci d'avoir essayé !

Depuis ta dernière rectification, et mon dernier petit code, je n' ai plus de M680
mais la fonction est royalement ignorée 5 fois sur 6 ( je me suis arrêté à 6 essais ).

Bonsoir a tous !

je tente d 'apporter ma contribution.
J'ai lancé le programme plusieurs fois d'affilé...

Je viens de tester le programme et j'ai moi aussi un message d'erreur :

"Panoramic.exe a cessé de fonctionner"

Je précise que parfois, cela fonctionne correctement et même plusieurs fois de suite.
Je quitte le programme et le relance alors immédiatement.

Ce message arrive parfois après le renvoi des 2 paramètres et parfois avant.
Cela semble un peu aléatoire...



J’espère que cela aidera a la résolution du problème.

On parle bien de ce programme-là ?

Code:

' ESSAI FONCTION MOVESIZEWINDOWS
dim res%
label action
dll_on "KGF.dll"
Edit 1 : on_change 1,action

res% = dll_call1("MoveSizeWindowInitHook",handle(1))
message str$(res%) :' message : 0
res% = dll_call1("MoveSizeWindowAddHook",handle(0))
message str$(res%) :' message : 1
end

action:
  message text$(1)
return

C'est la version réduite au minimum par Ygeronimi. Et chez moi, cela marche sans problème, pendant des dizaines de fois...

J’ai modifié le code

Code:

' ESSAI FONCTION MOVESIZEWINDOWS
dim res%
label action
dll_on "KGF.dll"
Edit 1 : on_change 1,action
res% = dll_call1("MoveSizeWindowInitHook",handle(0))
message str$(res%) :' message : 0
res% = dll_call1("MoveSizeWindowInitHook",handle(1))
message str$(res%) :' message : -1
res% = dll_call1("MoveSizeWindowAddHook",handle(0))
message str$(res%) :' message : 1
res% = dll_call1("MoveSizeWindowAddHook",handle(1))
message str$(res%) :' message : 2

end

action:
 message text$(1)
return

Si je déplace ou j’agrandi ou je rapetisse le FORM, le caption du FORM passe à M001.
Pourtant aucun caption n’est codé !

Code:

res% = dll_call1("MoveSizeWindowInitHook",handle(0))

C'est cette ligne qui cause ce problème. Dans cette fonction, tu dois donner, non pas la handle d'une form, mais le handle d'un objet EDIT qui recevra les textes Mxxx signalant qu'une modification est intervenu sur la form ajoutée en xxx-ème position, par la fonction MoveSizeWindowAddHook. C'est cette dernière qui doit donner le handle de la form à surveiller.

Imaginons un objet EDIT numéro 17, des forms à surveiller 123 et 492.
Tu fais un seul appel de MoveSizeWindowInitHook avec handle(17). Surtout pas de deuxième appel à cette fonction !
Ensuite, tu fais un appel de MoveSizeWindowAddHook avec handle(123), et un autre avec handle(492). La form 123 est ajoutée en 1ère position dans la table, la form 492 en deuxième position.
Lorsqu'on bouge la form 123, l'EDIT 17 reçoit M001 (première form ajoutée).
Lorsqu'on bouge la form 492, l'EDIT 17 reçoit M002 (deuxièùe form ajoutée).

Tu vois le principe ?

J' ai refait quelques essais de lancement du mini programme :

Code:

' ESSAI FONCTION MOVESIZEWINDOWS
dim res%
label action
dll_on "KGF.dll"
Edit 1 : on_change 1,action

res% = dll_call1("MoveSizeWindowInitHook",handle(1))
res% = dll_call1("MoveSizeWindowAddHook",handle(0))
end

action:
   message text$(1)
return

Malheureusement, la détection ne fonctionne pas à tous les coups.
Lorsqu' elle ne fonctionne pas, je n' ai pas de message l' edit reste vide.
Quand elle fonctionne, elle ne le fait que sur un déplacement de la fenêtre
et pas sur une modification de sa taille.

Je ne vais pas me rendre barge, j' ai assez du monde réel pour cela en ce moment  ,
je préfère faire une impasse sur cette fonction.

Par contre je lance l' idée :
Une fonction type On_change sur un objet Panel.
Cette objet, si il est déclaré en full_space, s' adapte à la taille de la fenêtre
lorsque l' on clique sur le petit carré. 
Récupérer l' événement, pourrait être un palliatif chez ceux qui auront mon problème.

Bon, j'ai pris les grands moyens. A l'aide de WMWare Player, j'ai virtualisé un Windows 7 sous mon W8. J'y ai installé Panoramic_Editor dernière version, KGF.dll dernière version et ton programme de test réduit qui est parfait pour vérifier. Conclusion: chez moi (mais il connaît son maître  ), tout marche parfaitement. Je n'ai que des M001, à chaque déplacement de fenêtre, et à chaque redimensionnement. Aucune anomalie.

Ne ne sais plus quoi faire d'autre. Chez moi, XP Pro SP3, W7 et W8 - tout marche.

Ne te casse pas la tête, ce doit être un souci de ma machine.
Mais, lequel, je ne sais pas.

Si j' en rencontre d' autres, je vais finir par le ré initialiser usine.

C'est en effet bizarre. Je n'ai pas d'explication plausible à t'offrir.

Quant à intercepter le changement de dimensions d'un Panel, ce n'est pas la solution non plus. Pour deux raisons:
1. en déplaçant la fenêtre, les coordonnées du Panel ne changent pas (elles sont relatives à la fenêtre, pas à l'écran)
2. dans tous les cas, c'est la fenêtre qui reçoit le message Windows de changement de position ou de dimension, pas le Panel. J'ai vérifié. Donc, on revient au problème précédent.