cycle

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/04/2005 at 16:17, xxxxxxxx wrote:

Have you checked to see what messages are sent with a change of the cycle box value? This will give you an idea of what to look for.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/04/2005 at 13:29, xxxxxxxx wrote:

Robert is right; look at what's sent to Message() when the cycle field is changed. (Assuming it's in a dialog box, not in the attributes manager.)

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/04/2005 at 01:54, xxxxxxxx wrote:

It is in the attributes manager.
I detect the change now by reading the value in the next execute pass (tag plug).
But i woul like to trap it on the moment its selected.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/04/2005 at 04:28, xxxxxxxx wrote:

when you change any description entry, I am sure the Message MSG_DESCRIPTION_VALIDATE is definetly called (when you are in the AM). So check for it in your Message function and do whatever you want.

HTH
Katachi

P.S.: A "thanks" isn´t too hard...

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/04/2005 at 10:45, xxxxxxxx wrote:

Oh, of course, yes..., thanks..i'm sorry.
And: indeed, the VALIDATE message is the one, great, thanks again.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 06/07/2008 at 09:37, xxxxxxxx wrote:

That's great, but how am I able to see which one is changed? Do I have to control it manually or is there something else?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 06/07/2008 at 12:57, xxxxxxxx wrote:

Hi,

Not sure if i remember well but i think it was something like this....

> \> Bool YOURCLASS::Message(GeListNode \*node, LONG type, void \*data) \> { \> DescriptionCommand \*dc = (DescriptionCommand\* ) data; \> \> switch (type) \> { \> \> case (MSG_DESCRIPTION_VALIDATE) : \> { \> if (dc->id[0].id == YOUR_ID) \> { \> // do what you need to do \> break; \> } \> } \>

Succes!
Jan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/07/2008 at 09:21, xxxxxxxx wrote:

By that I always get the id 0. I think it's only for buttons. Isn't it DescriptionValidate instead of DescriptionCommand in this case?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/07/2008 at 00:54, xxxxxxxx wrote:

Hm,

I'm using it exactly like this, you must have a problem elswhere?

Jan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/07/2008 at 15:59, xxxxxxxx wrote:

Maybe, but I have no idea where. I gave every single element a unique long value in the *.h-file. As I said, the buttons work fine this way, but not the other things. This is my code:

> `

  
\>  Bool x::Message(GeListNode *node, LONG type, void *t_data)  
\>  {  
\>       switch (type)  
\>       {  
\>       case MSG_DESCRIPTION_COMMAND:  
\>            {  
\>                 DescriptionCommand *dc = (DescriptionCommand* ) t_data;  
\>                   
\>                 if (dc->id[0].id==REFRESH)  
\>                 {  
\>                      ...  
\>                 }  
\>                 if (dc->id[0].id==NEUE_ZUFALLSWERTE)  
\>                 {  
\>                      ...  
\>                   
\>                 }  
\>            }  
\>       case MSG_DESCRIPTION_VALIDATE:  
\>            {  
\>                 DescriptionCommand *dc = (DescriptionCommand* ) t_data;  
\>                 GePrint(LongToString(dc->id[0].id));  
\>    
\>            }  
\>       }  
\>       return true;  
\>  }  
\>

`

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/07/2008 at 16:08, xxxxxxxx wrote:

Duh. MSG_DESCRIPTION_COMMAND has a DescriptionCommand in the t_data but MSG_DESCRIPTION_VALIDATE has a DescriptionValidate in t_data. Unfortunately, DescriptionValidate does NOT contain the Description ID of the command that triggered the message so you have to be general about it here (i.e.: check every description that falls under validation).

Don't ask me, ask Maxon.