Bonjour,

Peut-on passer des paramètre à l'installation d'un programme windev ?

L'idée est de transmettre le répertoire destination (pour commencer) et donc pour éviter toute mauvaise amnipulation.

Attention : non ! je ne veux pas utiliser le répertoire par défaut car il s'agit d'une install lancée par le programme lui-même en vue de réaliser des 'clonages'.
si ! c'est autorisé ! on ne fait pas de la génétique !

Parce que toucher à wdsetup7 ne semble pas vraiment aisé (on y viendra s'il le faut vraiment )
A moins évidement qu'on trouve kk1 avec de l'xpérience sur le sujet.

Des clônages ??? ca va etre quoi le but de ce programme ?

Plusieurs version du logiciel sur un TSE.
Un par société, chaque poste se connecte pas une session TSE. Et une maison mère (le maître) qui controle la situation... toujours avec le même soft (mais configuré comme 'maître').
Chaque société a son soft complet (exe+sa base).
Les flux d'informations entre ces pôles sont assurés par une base d'échange dans un rep partagé (... du même serveur = accès quasi temps-réel !).
Le soft est le même pour une install mono poste et LAN, seule la config change (pas de notion de maître).

Le pb réside dans la création depuis le maître d'une société (un clonage par lancement de l'install en direction d'un autre répertoire) ou dans la mise à jour du maître. La même version doit être ventillée à toutes ses sociétés (toujours par clonage via l'install).

Pour la partie données et configuration (Ini) c'est ok.
Reste donc la partie install/modif/maj des structure.
Comme cela est très bien réalisé par l'installation, je tiens donc à l'utiliser.

ah ok je vois a peu pres ce que tu veux faire, ca parrait interressant mais pas evident effectivement, ca voudrait dire que t'aurais sur le serveur un exe qui tourne en permanance et qui scrupterait le repertoire d'echange pour voir le travail a faire et de ce fait le realiser.

et dans chacune des compagnies le meme procede a peu pres.

en gros quoi :)

houla ! non.
on va faire beaucoup plus simple !

Les mises à jour sont réalisée par nos soins (ou personnes habilitée).

Nos utilisateur on des supers pouvoirs (obtenus par mutation génétique) :
Ils peuvent scruter les sessions en cours via une fenêtre au sein même du soft (maitre et sociétés).
Ils foutent les retardataires dehors (simple : il tirent le cable rj45 derriere le serveur)

Ils créent des session bloquante/persistante dans toutes les sociétés (via un groupware utilisateur version nous). Plus aucun utilisateur ne pourra se connecter avant liberation de leurs sessions!

Ils quittent (leurs session son persistantes, les blocages sont donc effectifs même sans être dans le soft)

Puis on met à jour le maitre... et le relance (en reprenant la session persistante). Ce lancement du maitre détecte la mise à jour et affiche un panneau de mise à jour qui va cloner l'install (toujours à disposition, ou copiée sur le serveur) dans les société.

ps : pour l'instant il manque les session persistantes mais c un détail.

Bonjour,

Et pourquoi tu ne fais pas une application multi-magasin ou multi société ?
Notre application est multi-magasin (un magasin 'maître' et plusieurs magasin indépendant mais devant rendre des 'comptes' au maître) et multi-société (afin de pouvoir héberger les bases sur nos serveurs).
Tout cela avec une base commune et unique. Dans le premier cas, l'utilisateur se connecte avec son user puis choisit le magasin sur lequel il veut travailler (par défaut celui dont il dépend et par rapport à ceux pour lesquels il a été autorisé).
Dans le deuxième cas, la table client donne un code société qui est enregistré dans tous les enregistrements créés par l'utilisateur.
Dans le premier cas, le magasin maître peut voir toutes les informations (cela permet aussi de faire une facturation unique ou multiple).
Et bien sûr, un super-utilisateur (administrateur de notre société) peut voir l'ensemble des enregistrements.

Voilà j'espére avoir fait avancer le sujet.
@+
Vianney

ah ok j'avais mal compris le concept qui a premiere vue parrait complexe.

pour bloquer les sessions, il y a mieux que de tirer le cable ceci dit, dans la gestion des utilisateurs, l'administrateur pourra bloquer ou non la session.

On peut meme gerer dans la gestion de l'utilisateur le login avec possibilite de renouveler le mot de passe tout les mois avec bloquage du compte si mot de passe errone trois fois. Enfin bon la n'est pas le probleme, je suppose que tu y a pense.

a+++

Merci Vianney
Evidement cette architecture logicielle aurait convenue... (on l'a bien imaginée). Mais il serait bien long d'expliquer ce choix. Le pb ne tiens pas dans la gestion des utilisateur ni des société mais dans les processus d'install/maj en cascade sur le serveur.

on veut forcer une install depuis une session maitre.
Pour cela je pense passer par un wxf modifié en dynamique + wdsetup7.

lol
'Tirer' le cable est une expression ! j'imagine bien un de nos techs faire cela !

OK la solution est trouvée...

Elle ne situait pas du coté du wdsetup.
En effet les install.exe décompressent le install.wdz qui contient le programme d'instal (wdsetup ou wdsetup7).
Ce dernier utilise les définitions contenues dans le INST.WXF avec notament les clés [WDF]RepDef et [WDF]RepficDef qui sont les clé de destination des install (et données).

donc un petit dezip de ce fichier, deux iniecrit avec les valeurs voulues et un rezip et le tour est joué. il suffit ensuite de lancer le tout avec un lanceappli qui prend la main et hop.

Pour ne pas être ennuyé, on peut utiliser wdsetup7 et protéger les zones, recompiler et le proposer à la place du wdsetup7.

Reste plus qu'à modifier les ini des clones mais c'est pas le plus complexe.