IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Threads & Processus C++ Discussion :

Interaction entre thread principal et thread secondaire


Sujet :

Threads & Processus C++

  1. #21
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 074
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 074
    Points : 12 120
    Points
    12 120
    Par défaut
    Marche pas non plus pour moi.

  2. #22
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Bah, je ne sais pas. De toute façon le getSystemView() renvoi un type qui s'appelle IlAny et donc il peut remplir la fonction d'un HWND avec un reinteret_cast.

    Je teste et je vous tiens au courant.

  3. #23
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Je n'arrive pas à compiler j'ai fait :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    BEGIN_MESSAGE_MAP(SynoptiqueRepresentation)
    ON_MESSAGE(WM_REDRAW,RedrawTh)
    END_MESSAGE_MAP()
    Ils me renvoi l'erreur suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    d:\mehd\ihm\synoptique\src\synoptiquerepresentation.cpp(75) : warning C4003: not enough actual parameters for macro 'BEGIN_MESSAGE_MAP'
    d:\mehd\ihm\synoptique\src\synoptiquerepresentation.cpp(75) : error C2039: 'messageMap' : is not a member of '`global namespace''
    J'ai l'impression qu'il faut que ma classe hérite d'une classe MFC pour que ça marche.

    Une idée?

  4. #24
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    réessayer Maintenant avec les liens que j'ai envoyé !! (ilog server et ilog views)

  5. #25
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Je reformule ma question,
    Est-ce possible d'utiliser ON_MESSAGE pour intercepter les messages ou une MACRO équivalente, sans utiliser les MFC ou une fonction qui derive de CWnd ?
    En d'autre termes utiliser ON_MESSAGE avec d'autre thechno, comme ILOG ou Qt par exemple ?

    Merci

  6. #26
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    Pas à ma connaissance: Ces macros sont spécifiques à MFC, les autres technologies utilisent des mécanismes différents (signaux et slots pour QT, une fonction callback unique pour Win32, etc.)
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  7. #27
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Mais il existe surement un moyen pour envoyer des notifications (ou message) et pouvoir les attribuer à des fonctions User sans passer pas les MFC. Des programmes, qui ne sont pas graphiques, qui utilisent les MultiThreading sans utiliser des MFC.

  8. #28
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    Comme je l'ai dit, chacun ses mécanismes. En utilisant directement Win32, le thread destinataire doit avoir une boucle de messages, et une fenêtre (qui peut être invisible) si l'envoi se fait par SendMessage() plutôt que PostMessage().

    C'est la procédure de fenêtre de cette fenêtre qui est invoquée quand le message est reçu par le thread.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  9. #29
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 074
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 074
    Points : 12 120
    Points
    12 120
    Par défaut
    Il existe de nombreux autres mécanismes de synchronisations et de communications entre threads en Win32.
    Il n' y a pas que les envois de messages.
    Mais quand on a affaire à un environnement d'exécution type MFC, IlogViews ou Qt, il vaut mieux respecter leurs paradigmes si l'on veut conserver leur fonctionnalité.

    En résumé, voir la doc IlogViews.

  10. #30
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    L'application sur laquelle je travaille des fonction WIN32 pour lance les threads (_beginthread, waitevent, _setevent ...ect). C'est pour cette raison que je souhaite continuer sur cette ligne. En plus la doc d'ILOG Views n'est pas clair.

    Maintenant je pense utiliser SendMessage pour envoyer un message à mon thread principal. Comment je peux faire pour associé ce message à une fonction précise ?

    Merci.

  11. #31
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Ou vous me conseillez plutôt PostThreadMessage ?

  12. #32
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    PostThreadMessage() possède l'avantage d'être lisible directement depuis la boucle de messages du thread, contrairement à SendMessage() qui cible une fenêtre (PostMessage(), c'est un cas entre les deux).
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  13. #33
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    on peut aussi voir cet avantage comme un inconvénient, car si l'application est occupé le moment ou elle reçois le message, soit il va interrompre son fonctionnement soit elle va détruire le message. Et ce n'est pas mon but.
    et pour
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    L'application sur laquelle je travaille des fonction WIN32 pour lance les threads (_beginthread, waitevent, _setevent ...ect). C'est pour cette raison que je souhaite continuer sur cette ligne. En plus la doc d'ILOG Views n'est pas clair.
     
    Maintenant je pense utiliser SendMessage pour envoyer un message à mon thread principal. Comment je peux faire pour associé ce message à une fonction précise ?
    Vous n'avez pas d'idée?

    Merci

  14. #34
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par mehdi_me85 Voir le message
    on peut aussi voir cet avantage comme un inconvénient, car si l'application est occupé le moment ou elle reçois le message, soit il va interrompre son fonctionnement soit elle va détruire le message. Et ce n'est pas mon but.
    et pour
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    L'application sur laquelle je travaille des fonction WIN32 pour lance les threads (_beginthread, waitevent, _setevent ...ect). C'est pour cette raison que je souhaite continuer sur cette ligne. En plus la doc d'ILOG Views n'est pas clair.
     
    Maintenant je pense utiliser SendMessage pour envoyer un message à mon thread principal. Comment je peux faire pour associé ce message à une fonction précise ?
    Vous n'avez pas d'idée?

    Merci
    Je suis sûr qu'il doit y avoir moyen d'avoir une table de message avec Ilog. Que dit la doc ?

  15. #35
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Voila la doc qui parle des évenement :
    Package Class Index Package Member Index Class Member List
    IlvEventLoop
    Event loop class.
    Header File
    <ilviews/base/evloop.h>
    Library
    display

    List of all members.
    Member Functions

    Public Members
    IlvEventLoop(IlBoolean setIt = IlTrue)
    Constructor.

    virtual void addInput(int fd,
    IlvLoopCallback cb,
    IlAny arg = 0,
    IlvLoopCallback errorCb = 0)
    Adds an external source of input.

    virtual void addOutput(int fd,
    IlvLoopCallback cb,
    IlAny arg = 0,
    IlvLoopCallback errorCb = 0)
    Adds an external source of input.

    virtual void removeInput(int fd)
    Removes an external source of input.

    virtual void removeOutput(int fd)
    Removes an external source of input.

    virtual IlvIdleProcId addIdleProc(IlvIdleProc idleProc,
    IlAny userArg)
    Add an idle procedure.

    virtual IlBoolean removeIdleProc(IlvIdleProcId idleProcId)
    Removes an idle procedure from the event loop.

    virtual IlvInputMask pendingInput()
    Indicates pending input sources.

    virtual IlvInputMask processInput(IlvInputMask inputMask)
    Process input from the selected source.

    virtual IlBoolean dispatchEvent(IlAny systemEvent)
    Dispatches an event.

    virtual IlAny nextEvent(IlAny systemEvent)
    Gets next event from the windowing system.

    IlUInt lazyRedrawLevel() const
    void setLazyRedraw(IlUInt lazy)
    Get/Set the lazy redraw mechanism.

    virtual IlvRedrawProcLink* addRedrawProc(IlvIdleProc redrawProc,
    IlAny userArg)
    Adds a redraw procedure.

    virtual IlBoolean removeRedrawProc(IlvRedrawProcLink* procId)
    Removes a redraw procedure from the queue.

    void flushRedraw(IlUInt level = 0)
    Executes any pending redraw requests.


    Static Public Members
    IlvEventLoop* getEventLoop()
    Gets the current event loop.

    void setEventLoop(IlvEventLoop* eventLoop)
    Sets the current event loop.

    Detailed Description
    Event loop class.

    This class handles the processing of inputs and events. ILOG Views creates a global instance of this class that the application can access using the getEventLoop static method. The application can define its own event-processing mechanism by subclassing IlvEventLoop and overriding the nextEvent and/or dispatchEvent member functions. See the description of setEventLoop for important warnings about the use of subclasses.

    See also:
    IlvDisplay::readAndDispatchEvents(), IlvDisplay::waitAndDispatchEvents(), IlvMainLoop(), IlvTimer.

    Member Function Documentation

    IlvEventLoop(IlBoolean setIt = IlTrue)
    Constructor.

    Initializes an instance of event loop.

    Parameters:
    setIt If it is set to IlTrue, the new instance is set as the current event loop by a call to the static member function setEventLoop.

    virtual
    void addInput(int fd,
    IlvLoopCallback cb,
    IlAny arg = 0,
    IlvLoopCallback errorCb = 0)

    Adds an external source of input.

    This member function is available only on Unix platforms. It is used to add Unix file descriptors as new input sources for the application. The fd argument must be of a file descriptor type supported by the select function used internally by the event loop.
    The user input callback cb is triggered if the select function determines that fd has data to be read. The user error callback errorCb is triggered when an error occurs in the select function.
    The user callbacks cb and errorCb are called with fd and arg as parameters.
    The function call:
    IlvRegisterInput(fd, cb, arg, errorCb);
    is identical to:
    IlvEventLoop::getEventLoop()->addInput(fd, cb, arg, errorCb)

    Parameters:
    fd File descriptor of a type supported by select.
    cb The user callback to call when input is available on fd.
    arg The user argument to pass to cb or errorCb.
    errorCb The user callback to call when an error is detected on the file descriptor fd.

    See also:
    IlvRegisterInput.

    virtual
    void addOutput(int fd,
    IlvLoopCallback cb,
    IlAny arg = 0,
    IlvLoopCallback errorCb = 0)

    Adds an external source of input.

    This member function is available only on Unix platforms. Very similar to the member function addInput, this function is used to add to the event loop Unix file descriptors to watch. The fd argument must be of a file descriptor type supported by the select function used internally by the event loop.
    The user callback cb is triggered if the select function determines that fd is ready for writing. The user error callback errorCb is triggered when an error occurs in the select function.
    The user callbacks cb and errorCb are called with fd and arg as parameters.
    The function call:
    IlvRegisterOutput(fd, cb, arg, errorCb);
    is identical to:
    IlvEventLoop::getEventLoop()->addOutput(fd, cb, arg, errorCb)

    Parameters:
    fd File descriptor of a type supported by select.
    cb The user callback to call when fd is ready for writing.
    arg The user argument to pass to cb or errorCb.
    errorCb The user callback to call when an error is detected on the file descriptor fd.

    See also:
    IlvRegisterOutput.

    virtual
    void removeInput(int fd)
    Removes an external source of input.

    This member function is available only on Unix platforms. It is used to remove a file descriptor registered by addInput to be monitored by the event loop as a source of input.

    Parameters:
    fd The file descriptor to remove as source of input.

    See also:
    IlvUnRegisterInput.

    virtual
    void removeOutput(int fd)
    Removes an external source of input.

    This member function is available only on Unix platforms. It is used to remove a file descriptor registered by addOutput to be monitored by the event loop.

    Parameters:
    fd The file descriptor to remove from the event loop.

    See also:
    IlvUnRegisterOuput.

    virtual
    IlvIdleProcId addIdleProc(IlvIdleProc idleProc,
    IlAny userArg)

    Add an idle procedure.

    An idle procedure is a function provided by the user that is automatically called by the event loop when there is nothing else to do (no events, no timers or external inputs to process).
    Idle procedures must be written in such a way that they do not alter the interactive responsiveness of the application. They should return quickly enough not to block the event loop, in case some input has arrived.
    Idle procedures are handled as Last-In First-Out stack. Only the element at the top of the stack is used by the event loop. New idle procedures are put at the top of the stack. When an idle procedure must be called, the event loop does the following:

    1. It removes the top-most idle procedure from the stack.
    2. It calls the idle procedure.
    3. It puts it back at the top of the stack if the idle procedure returns IlFalse.

    This mechanism shows that an idle procedure can be considered as removed when it returns IlTrue. It also shows that if an idle procedure A adds an idle procedure B and returns IlTrue, A will get priority over B because A is automatically added to the stack right after B.
    The addIldleProc member function adds an idle procedure to the event loop and returns an ID that can be used by the application to explicitly remove the idle procedure by calling the removeIdleProc member function.
    An idle procedure that has a lengthy process to perform should split the work into several small pieces. Typically, the user argument userArg could point to some data used to store the status of a long computation. The status can then be retrieved the next time the idle procedure is called.

    Returns:
    The ID number used to identify the idle procedure entry.

    Parameters:
    idleProc The idle procedure.
    userArg The argument to use when calling the idle procedure.

    virtual
    IlBoolean removeIdleProc(IlvIdleProcId idleProcId)
    Removes an idle procedure from the event loop.

    Returns:
    IlFalse if the idle procedure could not be found. Otherwise, IlTrue is returned.

    Parameters:
    idleProcId The ID number identifying the idle procedure for the event loop. This value was returned by addIdeProc.

    virtual
    IlvInputMask pendingInput()
    Indicates pending input sources.

    Queries the event loop about pending input sources, that is, events, timers, and external inputs. On Unix platforms, external input sources are added by the addInput or addOutput member functions. On Microsoft Windows platforms, ILOG Views considers user messages (that is, messages with a value greater than WM_USER) as external input sources.

    Returns:
    One of the following values:

    * IlvInputNone: no input pending
    * IlvInputAll: all types of input are pending

    or an OR combination of:

    * IlvInputEvent: events are pending
    * IlvInputTimer: timers are pending
    * IlvInputExternal: external inputs are pending

    Note that IlvInputAll is equal to: (IlvInputEvent | IlvInputTimer | IlvInputExternal)

    virtual
    IlvInputMask processInput(IlvInputMask inputMask)
    Process input from the selected source.

    Processes one piece of input from the input sources specified by inputMask. Only one event, or one timer, or one external source of input is processed. Events are processed by calling IlvDispatchEvent. If there is no input on any of the specified sources, the function blocks until input is available. Specifying IlvInputNone as parameter makes little sense and may block the application permanently.
    There are limitations on this method:

    * On Unix platforms, when using the libmviews library (as opposed to libxviews), the processInput member function does not return the type of input processed (since this information is not provided by Xt).
    * On Windows platforms, not all combinations of IlvInputMask are supported. The supported values are the following:
    o IlvInputEvent | IlvInputTimer
    o IlvInputTimer
    o IlvInputExternal
    o IlvInputAll

    Returns:
    The one (and only one) type of input the function has processed.

    Parameters:
    inputMask An OR combination of IlvInputEvent, IlvInputTimer, and IlvInputExternal specifying the sources of input to process.

    virtual
    IlBoolean dispatchEvent(IlAny systemEvent)
    Dispatches an event.

    Dispatches an event to its destination view. When redefining this member function, you should not call the function IlvDispatchEvent, to avoid endless recursion.

    Parameters:
    systemEvent Pointer to a system-dependant event type; it is equivalent to XEvent* on Unix/X11 platforms and to MSG* on Windows platforms.

    virtual
    IlAny nextEvent(IlAny systemEvent)
    Gets next event from the windowing system.

    Gets the next system-dependant event that must be treated. The function also handles timers and external event sources (when applicable) internally managed. If no event is available, the function waits until a new event is sent by the system. When redefining this method, the function IlvNextEvent must not be called, to avoid endless recursion. In the Motif version, this method is equivalent to XtAppNextEvent.

    Returns:
    On Unix/X11 platforms, the returned value is a pointer to the IlvDisplay instance associated with the X Display that generated this event. On Windows platforms, the returned value is 0 if the event is the WM_QUIT message and non-0 value otherwise.

    Parameters:
    systemEvent Pointer to a system-dependant event type; it is equivalent to XEvent* on Unix/X11 platforms and to MSG* on Windows platforms. The parameter is used to return the next event.

    IlUInt lazyRedrawLevel() const
    See below.

    void setLazyRedraw(IlUInt lazy)
    Get/Set the lazy redraw mechanism.

    When invalidating regions (calling invalidateRegion()), containers and managers schedule by default a redraw procedure that will defer redraws until no more object management needs to be done. This greatly improves the overall performance and responsiveness of the user interface. However, for compatibility reasons, or to implement special deferred draw mechanisms, you may wish to turn off this mechanism and perform redraw tasks only explicitly.

    Call setLazyRedraw(0) to turn off the scheduling of redraw tasks when invalidating regions. Call setLazyRedraw(1) to turn the default lazy redraw mechanism back on. In this case, calls to initReDraw/reDrawViews will preempt the lazy redraw mechanism to maintain compatibility with former deferred redraw mechanisms. This means that calls to invalidateRegion inside a pair of initReDraw/reDrawViews will not schedule a redraw task, and that the most external reDrawViews will force a redrawing of the invalidated regions. However, if you never call initReDraw or reDrawViews in this mode, you will benefit from the lazy redraw mechanism, which schedules drawing tasks more efficiently. Call setLazyRedraw(2) to benefit from the full optimizations and code simplifications that the lazy redraw mechanism allows. At this level, calls to initReDraw/reDrawViews will not have any effect, allowing all existing programs to benefit from the full lazy redraw mechanism. However, some incompatibilities may appear in this mode when interleaving direct drawing (like when drawing in Xor mode) and deferred drawing, which is why this mode is not the default. Later versions of Views may however set the default value of the lazy redraw level to 2.

    The environment variable ILV_LAZY_REDRAW can be used to control the lazy redraw mode externally.

    Parameters:
    lazy Integer value indicating the type of lazy redraw mechanism to use.

    virtual
    IlvRedrawProcLink* addRedrawProc(IlvIdleProc redrawProc,
    IlAny userArg)

    Adds a redraw procedure.

    Redraw procedures are like idle procedures, but they are executed with a higher priority level, every time some input has been handled by the main loop. They are mainly used to handle asynchronous redraws generated by IlvContainer::invalidateRegion() and IlvManager::invalidateRegion().

    virtual
    IlBoolean removeRedrawProc(IlvRedrawProcLink* procId)
    Removes a redraw procedure from the queue.

    Parameters:
    procId A pointer to the redraw procedure that must be removed.

    Returns:
    IlTrue if the removal was successful, or IlFalse otherwise.

    void flushRedraw(IlUInt level = 0)
    Executes any pending redraw requests.

    This method sequentially removes all redraw requests from the queue and executes their attached callback.

    static
    IlvEventLoop* getEventLoop()
    Gets the current event loop.

    Returns:
    The instance of IlvEventLoop currently being used.

    static
    void setEventLoop(IlvEventLoop* eventLoop)
    Sets the current event loop.

    Sets eventLoop as the current event loop. The previous event loop is not deleted. This static member function allows the application to use its own subclass of IlvEventLoop. The most common use of this function is to set the customized event loop once and for all at application start-up. You can also temporarily set a local event loop for a specific task and reset the previous one once the task is completed. Any other use is highly discouraged. In particular, the current event loop should be the same before and after the dispatching of an event.

    Parameters:
    eventLoop The event loop to set.
    J'ai fait en sorte que ça soit lisible. Au niveau des évenement c'est la seule classe que je connais.
    Si vous avez besoin d'explications ou vous avez des questions concernant la donc n'hésitez pas à me poser des question.
    Réessayer avec ces lien :
    ILOG SERVER
    ILOG VIEWS

  16. #36
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    2 solutions :
    1/Passer l'objet Ilog dans le thread secondaire et utiliser IlvAbstractView::erase(). Problème, je ne sais pas comment rendre la chose thread-safe ?
    2/ Subclasser ton composant en utilisant IlvAbstractView::setWindowProc.
    Je te laisse consulter la doc ilog

  17. #37
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2009
    Messages : 110
    Points : 85
    Points
    85
    Par défaut
    Voilà la solution,
    En fait, quand on utilise ILOG Views, il faut qu'à la fin du main ajouter la fonction : IlvMainLoop. comme expliqué ici.

    Cette fonction a pour rôle d'intercepter tous les évènement (message, notification, ...ect) et les dispatcher. Donc il suffit de la modifier dans le main() par une fonction personnalisé comme suit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    void IlvMainLoopUser()
    {
    MSG message
    if(message.message==WM_USER)
      {
      ::PeekMessage(&message, NULL, WM_USER, WM_USER, PM_NOREMOVE);
      FONCTION_USER(arg1,arg2,...);
      }
    else
       IlvEventLoop::getEventLoop()->dispatchEvent(&message);
    }
    et envoyer un message où on veut avec, entre autre, PostthreadMessage :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    ::PostThreadMessage(threadid, WM_USER, Lparam,Wparam);
    Voilà tout, j'espère que ça va aider d'autres gens.
    Merci pour votre aide.

  18. #38
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. Réponses: 2
    Dernier message: 17/05/2013, 18h15
  2. Réponses: 11
    Dernier message: 24/10/2010, 20h28
  3. [QThread] Comment attendre une information d'un thread dans le thread principal ?
    Par f.denis dans le forum Multithreading
    Réponses: 5
    Dernier message: 15/04/2010, 11h57
  4. Réponses: 7
    Dernier message: 03/07/2009, 13h45
  5. message entre dialog box et thread
    Par scorbo dans le forum MFC
    Réponses: 7
    Dernier message: 19/06/2004, 11h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo