4D progress sur PC et fenêtre maximisée

Sur PC, l’utilisateur maximise une fenêtre dans la fenêtre MDI de l’application,
Puis, il fait une action qui utilise le composant 4D progress (ici une suppression d’elements)
il se retrouve à la fermeture de la fenêtre de 4D progress avec sa fenêtre en mode non maximisé (voir carrément minimisé ?)

Est-ce un comportement normal ?

Si oui, y a t’il un tourne autour pour éviter ce désagrement pénible comme le souligne mon client… :roll:

Ne me dites pas de ne pas maximiser la fenêtre SVP

J’ai rencontré ce problème il y a quelques années !
Et voilà j’ai re-écris mon propre composant qui ne fait pas ce soucis.

Il a de plus énormément plus de fonctionnalité, surtout dans l’affichage.
Car j’ai profité de cela pour tester les zones web et d3, vous imaginez !

De plus il est compatible avec celui de 4D de base (avec ajout de "T " devant les commandes) et il y a une doc !

Peut-être devrais-je le vendre ? Voir le proposer gratos en compilé ?

Il est en v15 pour être compatible “large”.

Cela ne me dit pas si c’est normal ou si c’est un bug du composant. :frowning:

bonjour,
Je pense que c’est un bug, je fais faire des tests de mon côté.
Ça doit être lié au type de fenêtre utilisé pour la progress bar.

Merci Roland.
Si déjà vous jetez un oeil, pourriez vous considérer http://forums.4d.com/Post/FR/18558659/0/0/cette feature request> qui est importante pour pouvoir utiliser pleinement le composant.

Dans la même idée, j’ai mis un délai pour refermer la progress.

En cas d’enchaînement, car il y a des situations où l’on est obligé de fermer la progress car on ne sait pas ce qu’il y aura ensuite.

Ca évite de voir clignoter une fenêtre.
Idem en nombre de tick, et c’est efficace !

Ce qui m’interesse surtout c’est de pouvoir afficher directement la fenêtre parametrée/configurée comme je la veux sans à-coup. Actuellement la fenêtre apparait vide, on a à peine le temps de faire le parametrage que l’action est déjà terminée; au final, la fenêtre est apparue vide sans aucune information… :frowning:

: Manuel PIQUET

Ce qui m’interesse surtout c’est de pouvoir afficher directement la
fenêtre parametrée/configurée comme je la veux sans à-coup.
Actuellement la fenêtre apparait vide, on a à peine le temps de faire
le parametrage que l’action est déjà terminée; au final, la fenêtre
est apparue vide sans aucune information… :frowning:
Normalement, la progression est lancée dès que la tâche l’est, mais elle ne s’affiche que si, au-delà d’une ou deux secondes, la tâche correspondante n’est pas terminée. Il me semble que le progress 4D respecte cela - à vérifier dans le source.
Sinon, en fait de progress j’utilise celui ci :
http://forums.4d.com/Post/FR/10671557/1/10672092#10671558
J’ai dû le faire un peu (très peu) évoluer depuis, au besoin je peux t’envoyer le source.

J’ai l’impression que personne ne comprend ce que je dis… :cry:
Pour utiliser le composant progress, on doit afficher en premier la fenetre de progression vide
Ensuite, on peut changer le contenu de cette fenêtre par programmation changer le titre, la police, etc…
Ce que je voudrais c’est pouvoir ouvrir directement la fenêtre APRES__ avoir renseigné correctement ces infos.

: Manuel PIQUET

J’ai l’impression que personne ne comprend ce que je dis… :cry:
Ça arrive. Figure-toi qu’il n’y a pas longtemps on m’a demandé si je me posais une question à moi-même :lol:

D’après ce que tu dis, il n’y a pas comme je le disais plus haut, de délai entre l’instruction Progress new et son affichage effectif ?
Pour le dire autrement, il ne marche pas comme le progress du Finder qui n’apparaît que si l’opération lancée, après 1 ou 2 secondes, n’est pas finie ?

Ce que tu ne comprends pas c’est que ce n’est pas un problème de délai d’affichage, mais il faut pouvoir paramètrer la fenêtre (son contenu) comme on veut AVANT son affichage éventuel.

Actuellement, on est OBLIGÉ d’afficher une fenêtre vide, PUIS de la compléter…

En résumé, je demande simplement de pouvoir INITIALISER correctement la fenêtre AVANT son affichage.

Ha oui, j’ai testé, affichage immédiat :doubt:
La doc le précise, d’ailleurs :
Par défaut, cette fenêtre :
• contient une barre de progression indéfinie
• n’a pas de message

J’ai essayé [url= Progress SET WINDOW VISIBLE]http://doc.4d.com/4Dv17/4D/17/Progress-SET-WINDOW-VISIBLE.301-3786556.fr.html>, mais ça n’a d’effet que si le progress est déjà visible.

C’est normal qu’il ne mémorise pas le dernier emplacement ?

Bin t’as plus qu’à te plonger dans le source ou à espérer être entendu, moi je continue d’utiliser le mien qui n’a pas le quart de poil des fonctionnalités celui de 4D mais marche comme je veux.

Je déplore le manque de réactivité sur les composants 4D (4D progress, État semi-automatique, etc.). Ce n’est pas parce qu’on nous met à disposition leur code sources que 4D doit se dispenser de toute correction de bug et d’ajout de nouvelles fonctionnalités pour ceux-ci.

Cela sera toujours plus bénéfique à tous d’avoir un composant à jour, plutôt que de devoir chacun dans son coin, soit corriger, ou redévelopper son propre composant…

Quitte à instaurer une sorte de co-développement (itératif) partagé; mais, il faut AVANCER et pas stagner, ou laisser de côté, sous prétexte qu’on peut faire mieux chacun dans son coin.

Houla !
Attention, la mise à dispo des sources ne veut pas dire laisser à l’abandon, c’était une demande forte, dont de moi-même, pour avoir une base de départ pour créer ses propres composants multi-instances.

Encore une fois, j’ai écrit le mien et il me donne entière satisfaction, avec beaucoup plus de fonctionnalités.
Surtout il ne minimise pas. Et je l’améliore comme je le souhaite.

Maintenant, en effet c’est pas simple de co-développer en 4D :frowning: sans gitHub et autres…

Manuel :

<< Je déplore le manque de réactivité sur les composants 4D (4D progress…>>

La question a été posée hier soir à 17:00, j’ai répondu ce matin a 8:16 ! ça ne me semble pas être un délais insurmontable :slight_smile:

Surtout que depuis j’ai pris le temps

  • de changer le code pour tester avec un nouveau type de fenètre (palette)
  • de tester si ça fonctionnait (barres de menus, boutons “stop”…)
  • case de fermeture (forcément présente dans les palettes mais qu’il faut malgré tout bloquer…)

Bref, ça donnerait ça…

[]26194700;“Avec boutons”[/]
[]26194719;“Sans boutons”[/]

Et je vais voir si je peux faire en sorte que la position de la fenêtre soit mémorisée.

<>

Roland

Il ne faut pas voir mes propos comme une attaque mais comme une incitation à faire évoluer plus régulièrement les composants 4D. Cela pour le bénéfice de chacun.

Que ce soit pour des bugs remontés ou pour des features request qui me semblent légitimes au bon usage par le plus grand nombre.

Actuellement pour ce qui concerne 4D Progress pour ma part c’est le bug sur PC uniquement qui démaximise la fenêtre courante lors de l’utilisation de 4D progress qui peut être gênant.

Après, ma demande de feature (qui date elle du 21/10/16 ceci explique cela) pour l’initialisation de la fenêtre me parait importante lire mes explications précédentes pour comprendre.

D’autres ferons surement d’autres demandes (time out, garder la position, etc…)

L’important est de garder la réactivité et d’apporter régulièrement des mises à jour.

Merci.

: Roland LANNUZEL

<>
Ha oui mais il y est dit aussi : « Qu’une maille rongée emporta tout l’ouvrage. »
En clair, touche pas ça marche :lol:

bonjour !

deux points:

#1 : Il faudrait un No de bug ou un cas taow et éventuellement une base de test svp (il y en a déjà un peut-être ? j’ai pas suivi depuis le debut :-). Je pense que le problème n’arrive pas que sur PC, le pb doit être le même sur mac.

#2 : <<l’initialisation de la fenêtre>> la fenêtre de progression est un process 4D comme un autre. Il ne se lance donc pas instantanément. Dans votre cas, il se lance plutot “trop vite” puisque dans certains cas vous ne souhaitez pas le voir apparaitre. Et là on ne peut pas le “deviner” et temporiser systématiquement (on nous le reprocherait aussi !). À mon sens, c’est plutôt du côté du code 4D qu’il faut regarder…

Le principe c’est qu’on ne doit pas faire apparaitre une progress bar systématiquement, et plus généralement pour des traitements courts (disons 2 secondes);

Quand on ne sait pas à l’avance combien de temps prendra un traitement, eh bien on vérifie en cours de route…

  • memoriser l’heure de départ
  • ne PAS ouvrir de progress bar
  • lancer un traitement
  • vérifier en cours de traitement le temps écoulé depuis le debut
  • Si le temps est supérieur à 2 secondes (et qu’on est loin d’avoir fini) ouvrir une progress bar
  • Poursuivre le traitement en affichant la progress bar et en la faisant évoluer
  • Finir le traitement
  • Fermer la progress bar si on a eu besoin de l’ouvrir…

Est-ce que ça répond à votre demande ?

Roland

#1 : pour vous faire plaisir j’ai ouvert un incident TAOW [139884]

Le fait de travailler en maximiser (plein écran) sur Mac n’est pas
encore très répandu, mais effectivement c’est possible que cela ne
fonctionne du coup pas non plus sur Mac.

Sur PC, en revanche, c’est BEAUCOUP plus répandus que les utilisateurs
mettent leurs fenêtres en mode maximisé au sein de la fenêtre MDI de
l’application. Or, dans ce cas, le bug est beaucoup plus gênant.

#2 : Avez-vous (re)lu http://forums.4d.com/Post/FR/18558659/0/0/ma
demande de feature> ?
Mon problème c’est l’initialisation du contenu de la fenêtre AVANT que
celle-ci ne soit affichée.
Actuellement, on ne peut que lancer et afficher la fenêtre, ensuite
par programmation compléter le contenu, changer le titre, etc.
Ce que je demande c’est de pouvoir au minimum démarrer le processus
sans voir cette fenêtre vide, initialiser le titre etc., puis toujours
par programmation afficher (ou rendre visible) cette fenêtre
UNIQUEMENT une fois qu’elle contient des informations pertinentes

Actuellement, ce qu’il se passe, c’est qu’on affiche une fenêtre
vierge sans aucunes informations cela n’a aucun intérêt pour
l’utilisateur final; les commandes qui sont là pour initialiser le
contenu de la fenêtre n’ont même pas le temps de s’exécuter qu’on a
déjà refermé la fenêtre et quitter le process…

: Roland LANNUZEL

Est-ce que ça répond à votre demande ?

Désolé de vous répondre par la négative.
Je souhaiterais que vous rajoutiez la possibilité de lancer le process en ayant la fenêtre fermée (ou masquée) et que le développeur une fois qu’il a passé et exécuté les commandes d’initialisation du titre, de la police, etc. passe une dernière commande qui va afficher (ou démasquer) ladite fenêtre.

Ce que cela permet, c’est qu’au moins pour l’utilisateur final il ne verra qu’une fenêtre (même furtivement) mais qui contient au moins quelque chose. Ce n’est pas le cas actuellement l’'utilisateur voit passer une fenêtre vide…

Ma proposition ne change en rien (on rajoute simplement un paramètre étoile par exemple), le code préexistant fonctionnera toujours, simplement ou pourra faire ce que je vous demande c.-à-d. de pouvoir initialiser le contenu de la fenêtre AVANT son premier affichage.

<<Ce n’est pas le cas actuellement l’'utilisateur voit passer une fenêtre vide…>>
Dans ce cas, la “progressbar” n’est absolument pas justifiée. Elle ne fait que perturber l’utilisateur.

<<il ne verra qu’une fenêtre (même furtivement) mais qui contient au moins quelque chose>>
Non, il ne verra rien de plus.

Entre le moment ou la fenetre s’affiche et ou le titre il se passe 3 ou 4 dixièmes de secondes (j’ai regardé avec un screen shot quicktime)

$id:=Progress New
// entre là
Progress SET TITLE ($id;“Hello world”)
Progress SET PROGRESS ($id;0;“subtitle”;True)
// et là il y a largement moins d’une seconde //

Sur un progression qui devrait durer AU MOINS deux secondes (généralement bien plus) c’est un temps négligeable.

CELA DIT, quand on fera les modifications (importantes) concernant le bug, je vous promets de regarder si on peut ajouter un “true” ou un “false” optionnel à la commande “progress new” qui masquera le process dès son lancement…

Roland