Discussion :

[inforock]

Bonjour,

J'ai un service windows qui a un serveur TCP intégré (composant TidTCPServer plus précisément).

J'ai une application desktop qui se connecte au serveur TCP du service : OK, tout fonctionne. Le serveur reçoit bien les ordres de l'application desktop et interprète bien les ordres.

J'ai créé une commande sur le serveur TCP qui fait que lorsque l'appli envoie cette commande serveur, le service crée une form : OK, tout fonctionne. Enfin, je pense car pas de message d'erreur dans le fichier de log du service

Maintenant, j'aimerais, dans mon application desktop, pouvoir afficher la form créée dans le service windows via le serveur TCP (je ne sais pas si je suis très clair ). En gros, ce que j'aimerais faire c'est une sorte d'affichage déporté. Comme j'ai plusieurs services, chaque service ayant un serveur TCP intégré, avec une appli desktop je veux pouvoir gérer à distance les services via du TCP mais sans avoir à développer dans l'appli desktop une form pour chaque service. C'est pour cela que j'ai besoin d'avoir l'affichage de la form du service dans mon appli desktop via du déporté. En plus, je crois savoir qu'un service windows ne peut pas afficher de form.

Bien sûr, les form de chaque services (à terme j'aurais plusieurs services) sont différentes des unes des autres et contiennent différents contrôles : TEdit / Tcaption et Tbutton pour le moment. Je dois pouvoir donc saisir des données et lancer un traitement par l'appui sur le bouton sur chaque form.

Si j'arrive à faire fonctionner cela, le but est d'avoir l'application sur un terminal RF (avec Windows installé et connecté réseau en Wifi) et ainsi scanner les informations pour remplir les zones des forms de chaque service.

Je n'arrive pas à trouver des infos sur le net (ou bien je suis une bille pour les rechercher ce qui est plus que probable).

Est-ce que quelqu'un a une piste ou une idée ?

Je vous donne quand même le but complet du projet : piloter, via des terminaux RF, un réseau de modélisme ferroviaire en digital. Les terminaux permettront de scanner des codes barres et, via les services sur un serveur, les informations scannées feront des actions sur le réseau. Eh oui, je "joue" au p'tit train à mon age

D'avance merci.

Cdt

Laurent

[Jipété]

Salut,

ça serait pas ça le truc que tu cherches ?



(L'infobulle apparait en sélectionnant le bouton [ ? ] et en cliquant sur le texte de la checkbox "Autoriser blabla...")

Mais je n'en dirai pas plus, je suis sous Linux maintenant, alors les services...

[M.Dlb]

Hello,

Je pense que la proposition de Jipété permet d'afficher des forms uniquement sur l'ordinateur qui exécute le service, mais c'est à vérifier.
Quant à la capacité pour un service d'afficher une form, il faut vérifier aussi mais par nature un service n'a pas besoin de form pour rendre un... service. Il est censé recevoir des commandes/données de l'extérieur et renvoyer d'autres données au composant qui le requête.

Il faudrait peut-être revoir ton approche : pourquoi générer des form côté serveur, ce qui est typiquement fait côté client ? L'approche voudrait que tu développes les forms côté client, qui gère la communication avec le service, récupère les données de celui-ci et les affiche comme il faut.
Sauf si il y a des contraintes que je n'ai pas comprises et qui n'ont pas été exprimées.

[inforock]

Bonjour,

Justement, c'est ce que voulais éviter : avoir une application "lourde" côté client qui contient toutes les définitions des écrans de chaque service. L'application cliente est destinée à être installé sur un terminal RF.

Je pensais que le service pouvait définir une form et que l'affichage de cette form pouvait se faire via une connexion TCP dans une appli distante. J'étais parti sur le principe d'avoir comme une frame dans l'appli cliente et que la frame affichée était en fait la form du service. Un peu comme les accès à distance du style TeamViewer, UltraVnc ou TSE. J'avais vu cette pratique là où je travaille : les terminaux ne font qu'afficher les forms générées par les services qu sont sur le serveur via une connexion TCP. Je pensais pouvoir le reproduire pour mon besoin pour mon hobby.

Je vais peut être effectivement revoir cette gestion : il peut y avoir des enchaînements de form (menus, saisies, ...) mais pour chaque service, ce sont les mêmes forms ... je peux donc envisager d'intégrer tous les écrans dans l'appli qui sera installée sur le terminal (j'espère que ce ne sera pas trop lourd par rapport aux capacités du terminal).

Merci.

Cdt

Laurent

[tourlourou]

Peut-être les services peuvent-ils transmettre des équivalents de fichiers dfm aux clients qui recréeront les fiches correspondantes ?

[inforock]

Bonjour,

Je profite de mes vacances pour donner des nouvelles

Je vais changer de type de traitement. Comme ce sont toujours les mêmes modèles d'écran, je vais avoir un seul écran générique au niveau de l'appli cliente. Le serveur transmettra uniquement les informations concernant le service concerné et l'appli cliente renverra les informations saisies uniquement. Ainsi, les données réseau seront plus "lights".

Merci à tous pour vos suggestions.

Cdt

Laurent

[Paul TOTH]

bonjour, je vois deux solutions à cela

1) que le service propose une interface Web, dans ce cas le client est un simple navigateur

2) partir sur une solution que j'avais étudier il y a fort longtemps, la RemoteVCL, je n'ai jamais poursuivi ce début de projet, mais l'idée était de recompiler une application Delphi avec une VCL de remplacement qui agit comme un serveur applicatif. Le client est une application VCL classique qui reçoit le DFM du serveur et renvoie automatiquement les événements au serveurs qui les traite.

dans la démo fonctionnelle, le clic sur Button1 du client provoque l'execution de Buton1Click sur le serveur, la fonction ShowMessage() côté serveur est renvoyée au client qui affiche le message

par contre, pour rendre cela exploitable ça demande beaucoup de travail, c'est pour cela que c'est resté en l'état de Proof of Concept.

[inforock]

Bonjour Paul,

Merci pour ces informations.

Je vais, pour mon information personnelle, regarder plus en détails ta solution qui concerne le Remote VCL.

Pourtant j'avais été sur ton site pas plus tard que la semaine passée mais je n'avais pas vu cela

Cordialement.

Laurent