Extented me pose problèmes :-(Résolu

Question

Bonsoir à tous;

j'espère être dans la bonne section pour exposer mon souçis.

Voilà, je code depuis peux (hier lol) en Pascal ( delphi 7).

J'ai réussi à connecter mon "application" au service DDE d'un logiciel de trading; je récupère sans problèmes les données dans des labels, de ce coté là tout fonctionne!

Seulement, à partir de moment où je veux effectuer des calculs avec ces données, le code me met une erreur du type type incompatible, string et extended, ou encore int et extended

J'ai bien entendu fait des recherches sur ce site et un peux partout, mais pas moyen de trouvé comment transformer ces données en "nombres" pour pouvoir travailler avec!

Les données DDE varient toutes les secondes +- et comporte 4 chiffres décimaux.

J'ai essayé le StrToFloat et toutes ces petites fonctions, mais rien n'y fait.

Auriez vous une idée pour transformer ces données dans un format exploitable svp?

Caribensila · Accepted Answer

Bonsoir,

Essaie :

var X : extended;
begin
DecimalSeparator := '.';
X := StrToFloat(Label1.Caption);

Damien7784 · Answer

Magnifique, c'est parfait  ... et rapide!
J'ai remarqué une chose, peut-être ais je fais un erreur :

je voulais transformer mes données "string" en données numériques dans la procedure "OnChange" du DdeItem, c'est là que ça ne fonctionnais pas!

Ici, j'ai fait à votre manière, mais dans un procedure click sur boutton et ça marche.

Je ne sais pas si c'est une erreur, mais bon, je sais comment faire maintenant, merci à vous

Caribensila · Answer

A ton service et bonne chance en Bourse.   :)

Damien7784 · Answer

Merci, je fait ça en "amateur", loin d'être un pro avec l'argent qui va avec lol.

Bon, donc, jsuis pas futfut, encore beaucoup de chose à apprendre.

J'ai pas réfléchis au fait qu'avec la procédure "buttin1.click", mon résultat na s'affichait que quand je cliquais (forcement), du coups quand mes valeurs changent, la fonction ne faisait rien temps que je ne cliquais pas.

Alors, j'ai posé votre code dans la procédure TForm1.FormMouseMove, ça va mieux, plus de clicks à faire du moment que je bouge sur la fenêtre.


Auriez vous une suggestion pour que ça ce fasse automatiquement?

dubois77 · Answer

bonjour
avec un timer peut être !
cordialement
Dubois77

Bacterius · Answer

Non, un thread !
Les timers sont à proscrire : leur utilité est virtuellement nulle, ils consomment des ressources et ne sont mêmes pas garantis d'être exécutés si le système est un tant soit peu occupé.

Cordialement, Bacterius !

jlen100 · Answer

bonjour
dans le OnChange tu peux attendre un retour chariot (#13) pour declencher la consversion
if pos(#13,Label1.Caption) then
X := StrToFloatDef(Label1.Caption,0);

jlen

Francky23012301 · Answer

Non, un thread !
Les timers sont à proscrire .


Bacterius tu viens de dire une énorme conneries.

Un thread n'est pas un timer, mais s'il peut être utilisé en tant que tel.


ils consomment des ressources
Ben pourquoi un thread ca n'en consomme pas ?

 et ne sont mêmes pas garantis d'être exécutés si le système est un tant soit peu occupé Ah bon tu as vu souvent des évènements OnTimer non executés ? Tu as des exemples concrets à nous citer ?

Qu'un timer soit imprécis - oui , qu'un timer ne permet pas de réaliser plusieurs taches à la fois - oui, mais faut pas dire de bétises : Un timer est utilisable et préférable dans 99% des cas à un thread et si un thread est mal utilisé c'est la catastrophe. De plus les cas ou un timer n'est pas exécutés sont très très très très rares et quand cela a lieu c'est bien souvent lié à un mauvais codage.

Oh là là là toutes les conneries que tu viens de dire

Bacterius · Answer

Réponse à Francky, qui a l'air bien sûr de lui 

Un thread n'est pas un timer, mais s'il peut être utilisé en tant que tel.
Je parlais du composant TTimer en lui-même, qui n'est qu'un substitut au thread pour les paresseux 

Ben pourquoi un thread ca n'en consomme pas ? 
Beaucoup moins qu'un TTimer pour le même usage. Le thread ne vient pas pourrir ton application en la ralentissant, puisqu'il s'exécute dans un contexte différent. Après, c'est sûr, si le développeur est crevé et veut une solution simple, il pose un timer et voilà ... mais bon c'est crade.

Ah bon tu as vu souvent des évènements OnTimer non executés ? Tu as des exemples concrets à nous citer ? 
Oui, j'en ai un. Au moment ou j'écris ce post, j'ai fait l'expérience de surcharger mon processeur (charge à 50% environ, sur les deux coeurs). Ensuite j'ai fait une bête application qui affiche l'heure dans un TLabel à chaque seconde, en ajoutant une ligne à un TListBox avec marqué "OnTimer reçu !", avec un TTimer réglé à intervalle 1000 ms. Résultat : OnTimer était appelé environ toutes les 8 secondes, et ça fluctuait. Quand j'ai arrêté la surcharge, les quelques événements manquant à l'appel sont arrivés à fond et j'ai reçu 30 événements en même temps.

De plus les cas ou un timer n'est pas exécutés sont très très très très rares et quand cela a lieu c'est bien souvent lié à un mauvais codage. 
Pas toujours, c'est surtout quand le processeur est surchargé et n'a pas le temps de dire à ton timer que c'est l'heure : le TTimer n'est pas relié à ton processus directement, c'est Windows qui le stimule quand l'heure est venue.

Qu'un timer soit imprécis - oui , qu'un timer ne permet pas de réaliser plusieurs taches à la fois - oui, mais faut pas dire de bétises : Un timer est utilisable et préférable dans 99% des cas à un thread 
C'est sûr, c'est plus simple si on a juste une tâche simple à effectuer ... je te le concède !

et si un thread est mal utilisé c'est la catastrophe.
Ahba faut savoir l'utiliser ! C'est sûr qu'un thread qui part en couille peut complètement planter ton système et obliger à un reboot. Mais faut le faire quand même.

Oh là là là toutes les conneries que tu viens de dire
Bon ok j'en ai dis quelques unes ! Mais sur certains points je maintiens ma position 

Cordialement, Bacterius !

Damien7784 · Answer

Merci pour vos aides, je vais les essayer de suite et vous tiendrais au courant 

J'avais pensé à créer une fonction aussi qui reverrait la valeur souhaitée dans une Box .... 

A tout à l'heure

Francky23012301 · Answer

Je parlais du composant TTimer en lui-même, qui n'est qu'un substitut au thread pour les paresseux un thread et un timer ont un mode de fonctionnement qui n'ont rien avoir et parlons mêmes pas du reste. Je t'invite à lire le tuto de GrandVizir

Je cite :

Mais si un thread effectue des opérations périodiquement, il ne peut en aucun cas être assimilé à un TTimer, en raison de ses caractéristiques, de son fonctionnement et surtout de la régularité sans faille des threads.

J'ai fait l'expérience de surcharger mon processeur (charge à 50% environ, sur les deux coeurs)

Heu charger ton CPU à 50% faut le faire quand même : ca t'arrive souvent ? 

Au boulot j'ai un vieux coucou et mon pc personnel date un peu, et je suis très très loin d'être en charge à 50% 

Et comment tu fais quand tu as besoin de beaucoup de timers (Par exemple 5) ? Tu utiles 5 threads ? 

Bacterius je dis pas que tu as totalement tord, mais tu es tellement extrême dans ton affirmation qu'elle en devient fausse

Bacterius · Answer

Heu charger ton CPU à 50% faut le faire quand même : ca t'arrive souvent ?
Figures-toi que oui : je n'ai pas un multicoeurs pour rien  Il m'arrive de laisser mes deux coeurs à 100% pendant toute une nuit pour des simulations (avec ventilation additionnelle evidemment !)

Et comment tu fais quand tu as besoin de beaucoup de timers (Par exemple 5) ? Tu utiles 5 threads ?
Non, surtout pas ! Tu gères les cinq timers dans le même thread, eh oui !

Bacterius je dis pas que tu as totalement tord, mais tu es tellement extrême dans ton affirmation qu'elle en devient fausse
Non mais je comprends, je commence à gratter aussi ^^ Allez j'admets qu'un thread à la place d'un timer est probablement overkill, mais bon c'est indispensable d'apprendre à les utiliser quand même ! Je faisais un bon geste 

Merci de m'avoir repris 

Cordialement, Bacterius !

Cirec · Answer

Salut,

les gars vous comparez deux chose totalement différentes ... donc incomparables !!!!

un Timer n'a rien à voir avec un Thread et inversement.

un Timer permet de répéter une action périodiquement .. toutes les X millisecondes.
Le Timer est pleinement dépendant du Thread principal. L'application peut donc se voir ralentie voir même figée. 

Le Thread, quand à lui, n'a aucune notion de temps par contre il tient compte de la priorité qui lui a été donné et il exécute "en tâche de fond" le code qui lui a été assigné. Le Thread donne une impression d'indépendance puisqu'il s'exécute à "l'extérieur" du Thread principal et de par ce fait ne perturbe pas l'exécution de l'application.  

Mais tout ça n'est qu'impression ... on peut aussi mettre à mal le fonctionnement d'un Thread ... il suffit d'en programmer 1 où 2 à une priorité élevé avec un code consistant a exécuter et ton Thread que tu chéris tant se verra autoriser son exécution que si le système a assez de temps à lui accorder.

De toutes façons un processeur peut exécuter un certain nombre de cycles par seconde et ce temps ne peut pas être augmenté, il est partagé entre tous les Threads en fonctions de leurs priorités.


[hr]@+Cirec
[hr]

Francky23012301 · Answer

les gars vous comparez deux chose totalement différentes ... donc incomparables !!!!  C'est bien ce que je me tue à dire à Bacterius.

Il dit que des aneries le jeune homme .

ps: Qui a piqué la sucette à Cari ? Même pas drole les gars

Caribensila · Answer

J'passais... Alors j'me suis dit que je pouvais peut-être ajouter mon p'tit grain de sel.

On peut utiliser un Thread comme Timer. Mais pas l'inverse.

Pour preuve, voici un petit exemple : 
  Imaginez (j'prends un exemple au hasard) que vous ayez besoin de faire clignoter un p'tit bitoniau pendant qu'une autre tâche se déroule...   MDR


unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
TBlinkThread = class(TThread)
  private
  	fLabel : TLabel;
    procedure Clignoter;
  protected
  	Constructor Create(ALabel: TLabel);
    procedure Execute; override;
    procedure Stop;
  end;


  TForm1 = class(TForm)
    lblClignotant: TLabel;
    btnGo: TButton;
    btnStop: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure btnGoClick(Sender: TObject);
    procedure btnStopClick(Sender: TObject);
  end;

var
  Form1: TForm1;

implementation
{$R *.dfm}

var MonThread : TBlinkThread;



Constructor TBlinkThread.Create(ALabel: TLabel);
begin
  fLabel := ALabel;
  inherited Create(True);
end;

procedure TBlinkThread.Clignoter;
begin
  fLabel.Visible := not fLabel.Visible;
end;

procedure TBlinkThread.Stop;
begin
  Suspend;
  fLabel.Hide;
end;

procedure TBlinkThread.Execute;
begin
  repeat
  	Sleep(500); // => 1 affichage/seconde
  	Synchronize(Clignoter);
  until Terminated;
end;



procedure TForm1.FormCreate(Sender: TObject);
begin
  MonThread := TBlinkThread.Create(lblClignotant);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  MonThread.Free;
end;

procedure TForm1.btnGoClick(Sender: TObject);
begin
  MonThread.Resume;
end;

procedure TForm1.btnStopClick(Sender: TObject);
begin
  MonThread.Stop;
end;

END.



Mais Damien7784 ne programme que depuis 2 jours.
On ne va quand même pas le lancer dans mes Threads si tôt !

Damien7784 · Answer

lol, oui pour le moment, j'en suis encore à mes tout début, les trheads viendrons plus tard 

Tellement débutant que je n'ai toujours pas réussi a avoir les données en direct sans procédure, mais ça va venir

Caribensila · Answer

@Damien
Je serais plutôt de l'avis de jlen100 d'utiliser un événement OnChange.
Ca me semble être le plus logique.
Ensuite, il faut faire des tests et des vérifications car un tel événement ne te garantit pas que la donnée soit exploitable par ton application (comme une chaîne vide, par exemple, ou un truc du genre "cot. susp.")...

Damien7784 · Answer

Oui Caribensila;

En fait, j'ai un évènement "On Change" pour le DDE Item, comme mes données sont en direct.

Dans cette procédure, j'ai fait en sorte que ma donnée soit dans un lable, de ce coté là pas de soucis,ça fonctionne en direct, ma valeur change belle et bien en même temps que mon logiciel serveur (MetaTrader 4)

Seulement, lorsque dans cette même procédure, je change ma valeur en Float, La compilation génère un message d'erreur :


Voici la procédure:
procedure TForm1.DdeClientItemChange(Sender: TObject);
var
X : Extended;
begin
 label1.Caption:= DdeClientItem.Text;
 Button1.caption:=   DdeClientItem.Text;
 X := StrToFloat(DdeClientItem.Text);
 label2.Caption:=FloatTostr(X);

end;

Pourtant, lorsque j'effectue cette action (les deux dernière avant le end) sur une procedure click ou autre, là pas de soucis, je peux travailler avec mes données ..... mais elle ne changent pas en direct 

Merci quand même pour vos idées, je ne lâche pas l'affaire

Damien7784 · Answer

J'oubliais, dans le code il y a une erreur, j'ai oublié le :
DecimalSeparator := '.';

Mais le soucis est toujours présent, même en changeant le "." en virgule ou autre

jlen100 · Answer

quand on utilise l'événement OnChange il faut s'assurer que toutes les données ont été transmise en effet il réagit dés le premier caractère transmis  il faut soit :
-vérifier la longueur si elle est fixe
-vérifier la transmission d'un caractère spécial(généralement un CR)
- soit déclencher un timer dans le OnChange

enfin cela dépend de la trame transmise 

pour éviter le message d'erreur utiliser StrToFloatDef qui renvoie une valeur par défaut s'il ne peut pas convertir la chaine(on utilise une valeur qui ne sera jamais reçue)
on peut aussi mettre un:
try
   StrToFloat(DdeClientItem.Text);
except;
//traitement de l'erreur
end;

Extented me pose problèmes :-(

27 réponses

Votre réponse