PowerBuilder à Donf ! / Envoi de fax via Toshiba e-studio

erasorz · 24-09-2012 10:00:27

Bonjour,

Pour un client qui possède un fax Toshiba e-studio 3540C, nous cherchons à développer une fonctionalité d'envoi de fax automatisée directement à partir de PowerBuilder.
Le principe est d'installer une imprimante virtuelle fax et d'y envoyer les impressions.
Jusque là tout va bien.
Maintentant le hic, c'est qu'une fois l'impression lancée, la boite de dialogue suivante apparait, où l'utilisateur doit saisir le(s) numéro(s) de fax à la main :

Evidemment nous souhaiterions automatiser cela puisque l'appli connait le numéro de fax.
Nous n'avons pas trouvé d'objet OLE. Il n'y a pas non plus de fonction "mail to fax" ou autre...

rincevent · 24-09-2012 10:29:39

Hello,

je vois 2 solutions possibles :

1- Voir dans la doc du fax si il est possible de lui passer d'une manière ou d'une autre le n° à utiliser. cela dépends vraiment du modèle de Fax je pense. Si la doc indique que c'est possible c'est la solution la plus simple., sinon :

2- Utiliser les Appi Windows (genre FindWindow() ) pour détecter la fenêtre et lui envoyer le n° de fax puis Enter (genre Send() )

good luck ;-)

erasorz · 24-09-2012 11:14:30

rincevent a écrit:
1- Voir dans la doc du fax si il est possible de lui passer d'une manière ou d'une autre le n° à utiliser. cela dépends vraiment du modèle de Fax je pense. Si la doc indique que c'est possible c'est la solution la plus simple., sinon :

Je n'ai rien trouvé dans la doc à ce sujet...

rincevent a écrit:
2- Utiliser les Appi Windows (genre FindWindow() ) pour détecter la fenêtre et lui envoyer le n° de fax puis Enter (genre Send() )

Pourquoi pas, mais je ne connais pas les noms des controles dans cette fenêtre (champs, boutons...)

erasorz · 24-09-2012 11:49:03

erasorz a écrit:
rincevent a écrit:
2- Utiliser les Appi Windows (genre FindWindow() ) pour détecter la fenêtre et lui envoyer le n° de fax puis Enter (genre Send() )
Pourquoi pas, mais je ne connais pas les noms des controles dans cette fenêtre (champs, boutons...)

bon, j'ai trouvé un utilitaire qui permet cela : windowSpy

Geo · 24-09-2012 12:16:51

Bonjour,

si tu parts dans cette solution, est-ce que ça ne risque pas de ne plus fonctionner si ton client met à jour son driver d'imprimante virtuelle fax ?
Sinon, du temps de Visual Studio 6, je me souviens avoir bidouillé avec Spy++ pour obtenir le même genre d'info.

erasorz · 24-09-2012 12:24:36

je n'ai pas trop le choix...

oui j'avais aussi trouvé spy++

rincevent · 24-09-2012 12:38:26

erasorz je serai intéressé de savoir comment obtenir les handles des contrôles de la fenêtre si tu vas plus loin dans cette solution.

xlat · 24-09-2012 12:41:32

erasorz a écrit:
je n'ai pas trop le choix...

oui j'avais aussi trouvé spy++

dans le même genre: WinCheat et uuSpy.
Sinon j'ai déjà publié un scirpt perl qui fais du pilotage GUI pour l'IDE pb

erasorz · 24-09-2012 12:53:04

à ce stade, mon problème est qu'il faille lancer un DW.print et que du coup PB attend que la boite de dialogue se ferme avant d'aller plus loin
donc même pas moyen de simuler des clics dans cette boite

erasorz · 24-09-2012 12:55:28

rincevent a écrit:
erasorz je serai intéressé de savoir comment obtenir les handles des contrôles de la fenêtre si tu vas plus loin dans cette solution.

il faut faire une fonction récursive avec FindWindowEx

xlat · 24-09-2012 13:16:37

erasorz a écrit:
rincevent a écrit:
erasorz je serai intéressé de savoir comment obtenir les handles des contrôles de la fenêtre si tu vas plus loin dans cette solution.
il faut faire une fonction récursive avec FindWindowEx

çà dépend tu peux t'en sortir avec le nom de classe window + titre pour trouver la fenêtre principale de la dialogue ensuite tu pourrais utiliser directement les CtrlID non ?

erasorz · 24-09-2012 13:19:31

non car il y a un tabpage qui encapsule les boutons/champs

rincevent · 25-09-2012 07:56:45

je n'y arrive pas actuellement.

j'en suis à trouver la fenêtre de PB avec FindWindow, ensuite je peux avoir la handle de la Frame MDI avec FindWindowEx et ensuite je suis bloqué.

le titre de la fenêtre est trop variable pour pouvoir être utilisé pour trouver la fenêtre et malheureusement le nom de la classe change aussi, c'est "pbsheet" + un n°

si vous avez un moyen d'obtenir le handle de la fenêtre où on édite le code dans PB ça m'intérèsse grandement ^^

P.S. xlat qu'entends tu par utiliser directement les CtrlID ?

xlat · 25-09-2012 09:05:40

le Ctrl ID c'est un identifiant unique pour la dialogue (qui est définit typiquement dans un .rc dans un projet c/c++).

Par exemple, Wincheat permet de retrouver les Ctrl ID d'un control d'une dialogue, par exemple en PB115, le Ctrl ID de la combo contenant [ *classname*, "(Functions)", "(Event)", "(Declare)" ] d'un editeur de code (classname=pbsheetNNN) vaut 0xcf, ensuite il est possible a partir du HWND de la dialogue de retrouver le HWND du control en connaissant sont CtrlID.

J'ai fais ca en perl pour automatiser de la génération de code par pilotage de l'IDE ...

rincevent · 25-09-2012 10:32:05

ok merci pour l'info

xlat · 25-09-2012 13:19:25

juste pour illustrer et pas par prosélytisme hein

Code: perl

#!/usr/bin/perl -w
use Win32::GuiTest qw( :FUNC :VK );
use constant PBVM => 115;
$| = 1;  #Autoflush stdout / stderr
while(1){
  #cherche parmis les IDE ouverts
  foreach my $ide (WaitWindowLike(undef, undef, "PBFRAME".PBVM))
  {
    #sous chaque $ide on cherche les fenetres de classname = wedit avec un ControlID = 0x64
    #et un niveau d'imbrication <= 8
    #note: le undef correspond à 'ignorer le critére texte'
    foreach my $hwnd (FindWindowLike($ide, undef, 'wedit', 0x64, 8 ))
    { #on lit le code
      my $text = WMGetText($hwnd);
      #et on regardes si on arrive à remplacer quelque chose
      if($text =~ s{(?<!/\* )(commente-moi)}{/* $1 */}gi)
      { #si oui, alors on modifie le code dans l'IDE
        WMSetText($hwnd, $text);
        printf "(%08x) patched\n", $hwnd;
      }
    }
  }
  sleep( 1 );
}

ce script surveille les IDE powerbuilder 11.5 ouvert avec du code et recherche les textes "commente-moi" qui ne sont pas précédés par "/* " et les remplace par "/* commente-moi */".

erasorz · 25-09-2012 13:29:48

xlat a écrit:
ce script surveille les IDE powerbuilder 11.5 ouvert avec du code et recherche les textes "commente-moi" qui ne sont pas précédés par "/* " et les remplace par "/* commente-moi */".

magnifique !
par contre, je ne comprends pas la finalité...
vous mettez commente-moi au lieu de // ou /* quand vous codez ?

xlat · 25-09-2012 13:42:23

erasorz a écrit:
xlat a écrit:
ce script surveille les IDE powerbuilder 11.5 ouvert avec du code et recherche les textes "commente-moi" qui ne sont pas précédés par "/* " et les remplace par "/* commente-moi */".
magnifique !
par contre, je ne comprends pas la finalité...
vous mettez commente-moi au lieu de // ou /* quand vous codez ?

non c'est juste un exemple rapide sans trop d'inspiration, ce que je fais dans la vraie vie est beaucoup plus ... long difficile à lire & comprendre

rincevent · 26-09-2012 09:11:33

merci xlat , parfait exemple en plus pas trop long pour pas décourager (parceque lire du Perl... )

xlat · 26-09-2012 12:22:45

rincevent a écrit:
merci xlat , parfait exemple en plus pas trop long pour pas décourager (parceque lire du Perl... )

tu digères pas l’oignon ?

rincevent · 26-09-2012 12:58:24

Disons qu'en connaissant PowerBuilder et sa syntaxe qui est pour moi la plus simple et la plus lisible on devient vite intransigeant sur ce point et je ne pense pas qu'on puisse dire que la syntaxe du Perl soit très lisible.

je me fais souvent cette réflexion d'ailleurs, comment se fait il que tant de languages forcent des syntaxes peu intuitives et contraignantes pour le programmeur (exemple pas spécifiquement Perl : devoir mettre ";" en fin d'instruction ou par exemple les tests d'égalités à écrire "==" en C) alors que PB prouve qu'on peut arriver au même résultat avec une syntaxe très proche du language naturel.

enfin, ça fait LONGtemps que j'ai pigé que la meilleure solution n'est pas toujours (voire même rarement) la plus plébiscitée par les gens... et comme au final c'est la popularité d'un truc qui assure son succès et sa diffusion...

xlat · 26-09-2012 13:55:18

je vais éviter de troller sur le sujet, mais on peu argumenter dans l'autre sens :
- perl permet de comparer des chaines avec des nombres d'où le == pour les nombres et 'eq' pour les chaines (perl n'est pas fortement typé)
- le ; en fin d'instruction cela à l'avantage d'écrire des instructions longues sur plusieurs lignes de façon plus lisible qu'en PB (sans les & finaux) et d'ailleurs le ; n'est pas obligatoire pour la dernière instruction d'un block.
- maintenant lisibilité ne rime pas toujours avec fonctionnalité : j'attends toujours une version native des tables/listes dans powerbuilder classic et une meilleurs gestion des tableaux, là on voit que pb est à la traîne depuis 20 ans.

rincevent · 26-09-2012 14:43:26

C'est pas beau de commencer son gros troll par un "je vais éviter de troller sur le sujet"

pour le "==" je pensais plutot à .Net où on doit écrire un truc du genre IF ( a == b) je trouve que le fait de se trouver dans la parenthèse suivant le IF devrait suffire au compilateur pour savoir qu'on veut tester une égalité et pas faire une assignation. pour perl je ne ccomprends pas bien, tu es en train de me dier que suivant ce qu'on compare il faut utiliser un opérateur différent ? c'est encore pire que ce que je pensais alors...

Pour le ";" ou "&" ben oui tout le monde me réponds toujours ça sauf que qu'est ce qui arrive le plus souvent, des instructions qui tiennent sur une ligne ou sur plusieurs ? perso avec mes 10 ans d'expérience je peux dire que c'est largement plus fréquent des instructions qui tiennent sur une ligne que l'inverse DONC c'est plus logique de demander un caractère spécial (&) pour continuer une instructions sur plusieurs lignes que de demander un caractère spécial (;) en plus du retour à la ligne pour terminer chaque ligne...

lisibilité/fonctinnalité : en effet d'ailleurs je n'ai parlé que de lisibilité moi, maintenant on peut parler de la fonctionnalité si tu veux, j'imagine que Perl a un équivalent des DataWindows, depuis le temps que Perl existe ...

Perso je n'ai jamais été confronté à qque chose d'impossible à faire avec les "bêtes" tableaux de PB par contre j'ai vu la galère que c'est de devoir choisir parmis 50 types possibles de tableaux, listes chainées et autres joyeusetés en Java, à la fin de la journée en PB t'as finit ton programme en Java t'as pas encore décidé quel truc utiliser...

Dernière modification par rincevent (26-09-2012 14:45:37)

xlat · 26-09-2012 16:44:00

<troll>
== et = sont différents en perl, = est une affectation que l'on peut faire à l'intérieur d'une expression ce que ne permettent pas des langages comme pb, par exemple $a = func1($b=func2()+1,$c=func3()) ou encore if($a=($b==$c))
il y a une devise perl qui dit TIMTOWTDI "there is more than one way to do it" : de la façon des plus élégante (ok ca se discute) à la plus bizarre, et moi j'aime avoir le choix et traumatiser mes camarades :-)

oui il faut choisir le type de comparaison car cela permet d'exploiter le dynamic-cast du langage, comme ca on n'est pas obligé de déclarer 2 variables pour véhiculer la même information lorsque l'on veut l'utiliser sous forme de chaîne ou de numérique (par exemple pour construire un message à partir d'entier).
d'un autre côté en PB on doit faire les casts manuellement : if long( ls_val ) = 42 then ... et la plus part du temps çà m’énerve car je suis très faignant en lecture/écriture de quantité de code.

en fait pour la continuation de ligne, je suis d'accord, c'est préférable en PB d'écrire des instructions sur une seule ligne (d’ailleurs je déteste scroller horizontalement), et pour perl ma préférence doit provenir des enchaînements qu'il est possible d'écrire dont je suis assez friand (@ary = map { ... } sort grep{...} @ary)

bien vu, perl n'a pas d'équivalent datawindow nativement, mais ca ne reste qu'un langage de script (en fait on peut utiliser les datawindows avec perl si on veut).

je ne dis pas qu'il y a des algos impossibles avec PB mais que c'est parfois "canon à mouche" comme solution pour des petits algos tout bête comme trier un tableau a deux entrées, voir des objets.
maintenant PB est fortement typé et parmi les avantages de cela : ca permet de repérer des erreurs dés la compilation alors qu'un langage de script dynamique est assez permissif (sauf si on utilise les bonnes pratiques "use strict" et cie).

Après, je dirai que pour chaque tâche il faut choisir ce qui l'accomplit le mieux.

Il y a combien de "moi"/"je" là de dans ?
</troll>

rincevent · 27-09-2012 06:34:50

plus ou moins d'accord avec tout ce que tu viens de rajouter au sujet.

Juste moi perso je déteste ce que tu appelle les enchainements c'est à dire "compiler" en une seule ligne de nombreuses instructions.
pour moi ça ne fait qu'une seule chose, rendre le code difficile à lire et à débugger, je ne dis pas que je n'utilise jamais le résultat d'une fonction comme paramètre pour appeller une autre fonction mais je ne le fait pas sur 5 niveaux d'appel par exemple ^^
l'écrire sur 5 lignes au lieu d'une rends le code plus lisible et je pense ne change rien à la performance.

Quand à TIMTOWTDI c'est bien d'un côté car ça permets d'avoir des solutions alternatives façe à certains problèmes, c'est mal d'un autre côté car la même chose est codée de façon différente par chacun et donc plus de choses à comprendre et à retenir quand on lit le code de qqun d'autre par exemple. Pour moi Java est l'exemple type de trop de TIMTOWTDI , tellement de façons de faire avec tellement d'implications différents qu'on perds un temps fou à ne serait ce que décider quelle méthode employer.

Répétez apres moi :J'aime PBAdonf. J'aime PBAdonf. J'aime PBAdonf.

Annonce

#1 24-09-2012 10:00:27

Envoi de fax via Toshiba e-studio

#2 24-09-2012 10:29:39

Re: Envoi de fax via Toshiba e-studio

#3 24-09-2012 11:14:30

Re: Envoi de fax via Toshiba e-studio

rincevent a écrit:

rincevent a écrit:

#4 24-09-2012 11:49:03

Re: Envoi de fax via Toshiba e-studio

erasorz a écrit:

rincevent a écrit:

#5 24-09-2012 12:16:51

Re: Envoi de fax via Toshiba e-studio

#6 24-09-2012 12:24:36

Re: Envoi de fax via Toshiba e-studio

#7 24-09-2012 12:38:26

Re: Envoi de fax via Toshiba e-studio

#8 24-09-2012 12:41:32

Re: Envoi de fax via Toshiba e-studio

erasorz a écrit:

#9 24-09-2012 12:53:04

Re: Envoi de fax via Toshiba e-studio

#10 24-09-2012 12:55:28

Re: Envoi de fax via Toshiba e-studio

rincevent a écrit:

#11 24-09-2012 13:16:37

Re: Envoi de fax via Toshiba e-studio

erasorz a écrit:

rincevent a écrit:

#12 24-09-2012 13:19:31

Re: Envoi de fax via Toshiba e-studio

#13 25-09-2012 07:56:45

Re: Envoi de fax via Toshiba e-studio

#14 25-09-2012 09:05:40

Re: Envoi de fax via Toshiba e-studio

#15 25-09-2012 10:32:05

Re: Envoi de fax via Toshiba e-studio

#16 25-09-2012 13:19:25

Re: Envoi de fax via Toshiba e-studio

Code: perl

#17 25-09-2012 13:29:48

Re: Envoi de fax via Toshiba e-studio

xlat a écrit:

#18 25-09-2012 13:42:23

Re: Envoi de fax via Toshiba e-studio

erasorz a écrit:

xlat a écrit:

#19 26-09-2012 09:11:33

Re: Envoi de fax via Toshiba e-studio

#20 26-09-2012 12:22:45

Re: Envoi de fax via Toshiba e-studio

rincevent a écrit:

#21 26-09-2012 12:58:24

Re: Envoi de fax via Toshiba e-studio

#22 26-09-2012 13:55:18

Re: Envoi de fax via Toshiba e-studio

#23 26-09-2012 14:43:26

Re: Envoi de fax via Toshiba e-studio

#24 26-09-2012 16:44:00

Re: Envoi de fax via Toshiba e-studio

#25 27-09-2012 06:34:50

Re: Envoi de fax via Toshiba e-studio

Pied de page des forums